Versioning system for maps, props ..

EnceladusEnceladus Join Date: 2004-01-18 Member: 25442Members
When a new NS1 version was released, and a new version of an official map was shipped with it, the old one was overwritten and you could only play the new version unless retrieving an old version from a previous release, renamimg it etc. If something was updated to a model of a wad file, they where simply replaced.

With custom maps you always had to rename a new version release so it didn't conflict when a server wasn't running the same version. If you updated the wad file, a model or whatever, you had to rename it or in case of the textures, compile it into the bsp.

I think it would be way more convenient, if NS2 would have some sort of standardized versioning system.
So when you release a new version of a map, e.g. ns2_tram you would name it ns2_tram_v1.level Ingame it would be shown as ns2_tram, ignoring the version parameter _v1. If an update to the map is released, it would be named ns2_tram_v2.level and so on, but loading the map ns2_tram would always load the highest version number available, unless you want to play a specific version. Then you would load ns2_tram_v364.

Same could go for props. They start with a version number of _v1, and if they update the version increases. If someone relys on a specific version in a map, he could directly reference that version in the map and woudn't conflict if a model changed.

That way you could choose to play an earlier version of a map, custom maps would have a way more convenient way of shipping an update and eliminate version conflicts.

Comments

  • Dalin SeivewrightDalin Seivewright 0x0000221E Join Date: 2007-10-20 Member: 62685Members, Constellation
    I think the "version parameter" in maps should be done away with completely. I've never liked how there were sometimes 5-6 different maps with only subtle differences (or one or two very large ones). It is annoying to keep track of everything because not every server is going to have the most recent one (and there wasn't a way to check with certainty what the current version was if the level designer didn't provide contact information).

    I say that level names should be left alone. There should be an internal parameter for the version number but the actual name of the map shouldn't change between versions unless the designer really wants to rename it. Leave it up to the server administrator to backup old maps if they want to make a revert. Adding in a system to do this that will copy out all custom files to a backup directory will help with this.
  • EnceladusEnceladus Join Date: 2004-01-18 Member: 25442Members
    Well an internal parameter would be nice, and guess it propably could be build in the editor by simply increasing a version number when saving a map, or via map parameter.

    However, sticking to a one map file system would introduce some other problems.
    When you join a server, that server has the same version as you everything is fine. If the server has a newer version, you download it, your local version gets updated and everything is fine.
    But what happens when you happen to have a newer version than the server?

    Or approaching it differently, if some server admin genius modifies a map (since the new format will let everyone edit a map once you get your hands on the file) to put some stupid clan banner into it, or modify it slightly. He has a newer version, your local one gets updated, and next time you join another server you get a mismatch.

    I know this could happen on a file based versioning aswell, but it at least solves the problem of yourself having a newer version than the server.
  • Renegade.Renegade. Join Date: 2003-01-15 Member: 12313Members, Constellation
    A more complex, but efficient system is to store each map in a single file with all of its versions as diffs contained within it (not unlike an SVN Berkley DB).
    This way you will always have every previous version of a map and if a server needs to send you an update, it only sends you the diff sections that you need (incrementals, or "delta"s which are common in gaming to save bandwidth). If you later decide you don't want the update, you can simply revert back to the previous version you had.

    I believe Blizzard does something similar which is why their replay system can always play old replays. I also believe Charlies stated he wanted to do something like this.
Sign In or Register to comment.