Open kevATin opened 4 years ago
I get the version for a map, it is just a tag, but it would be useful. The syntax would be /set version map 3
, and then you wold be able to use /list version map
to see the map version if there were more than 1 version (otherwise the map keyword would be unnecessary). Under this case, with other versions, /list version
would list all versions.
How would you use the other version strings? Are you saying that you don't want the map to show up in the map list if it isn't compatible? Or just that you want to be able to print out a report?
Also, I am not convinced about the max version. You wouldn't know until it came out, and then you might as well change the map if you are going to add a new version which also includes a max altitude server version.
Wow, I had no idea I had passed 500 commits.
The other version tags could be useful to define when a map uses a feature that was only recently added to alti+/xal (min), or when backwards compatibility breaking changes were necessary at some point map makers could define a last working version (max). I do think that they should show up and load and all, just that the admins get a clear warning.
Maybe you're right though, the rate at which altitude, xal's patch, and alti+server evolve doesn't really justify an elaborate versioning system with mechanisms for backwards compatibility for maps, etc. Maybe just the map version is good enough~
Ohh your version numbers are your commits!, I see~
Do you have answers for my previous questions?
How are maps handled; for example when a server has map A and client realizes it has map A too, how do they check whether it's the right one? Not at all, size, checksum? Could I run into trouble if I often update maps? What are the map size limits for resolution and for file size?
How are maps handled; for example when a server has map A and client realizes it has map A too, how do they check whether it's the right one? Not at all, size, checksum?
I think it is a checksum, I am not sure. It is checked and most of the time it works.
Could I run into trouble if I often update maps?
Yes, you shouldn't. But you might. Usually it more has to do with the server not realizing it is a new version. If you shut the server down and restart, then it usually works just fine.
What are the map size limits for resolution and for file size?
when the map gets over 3000x3000 you will start to see some oddities, especially if you have intense graphics. Then, maybe less. For background images, do not make them so big, break them up and tile them in. You can look at ball_race_silverstone
for an example.
I don't know that there is an altx file size limit, but I would try my best to stay under 2MB for a map.
This contains questions and suggestions;
How are maps handled; for example when a server has map A and client realizes it has map A too, how do they check whether it's the right one? Not at all, size, checksum? Could I run into trouble if I often update maps? What are the map size limits for resolution and for file size?
Could you add a /version or /set version command for plus.txt? It could allow map makers to set minimum (and maximum) versions of compatible alti+servers. With this it would be possible to add backwards compatibility, should something need to be changed and break older maps; or at the very least tell admins that the map they're trying to use isn't compatible with the alti+server they're running.
/version map 3 Could be used to define map versions. With checksums you can only check whether two maps are the same, you can't check which one is newer. With the version command it would be possible to set map versions without having to spam the map name itself with numbers.
/version checkall Could be used in the server console or by admins to have the server check and output version info about all maps.
For backwards compatibility's sake "old" maps without a version definition inside plus.txt should be assumed to be of the last version before the versioning was introduced.