Map files should have a version number

[Shevonar]

For the website there is a feature request (bug #357914) that players should be able to upload new versions of a map. I think this version number should also be displayed ingame (on each map selection screen) so players can find out if they have to download a new version. In the editor is should be possible to define the map version.

[Teppo Mäenpää (kxq)]

How should the version numbers be handled? If many people work on a single map, then there could easily be many revisions with same number.. I am not sure if that is a problem. However, if we do something like this, why not do it right?

[Shevonar (shevonar)]

I am not sure what you mean by "do it right". What is the right way in your opinion?

It might be helpful to have an inner version number which is increased whenever the map is saved and is used to determine which version of the map is newer (like some kind of revision). In addition there is an outer version number which is displayed to the player and manually set for releases of the map (like the build numbers for widelands).

[cghislai (charlyghislain)]

I'm not sure if handling version number in the editor would be helpful. Maybe the web interface could handle this, so that the version number is automatically increased when one uploads a new version. It would update a field in the map file and the game would be able to display it.

[Nasenbaer (nasenbaer)]

I am biased concerning this issue - generally I agree with the idea of versioning - however this is only interesting for maps downloaded - the internal maps in Widelands will be updated and taken care of during the development process.

and here comes the problem:

As we know, new Widelands versions are released once every 6 to 18 month - long term linux distributions are released in a similar or even longer period. This often leads to players using older versions.

But new maps are not always compatible to older versions - in some cases old maps ae not even 100% compatible with new versions (e.g. one problem we face in the map contest now are the maps from build17 - there it was possible to define port spaces, but the definition of where port spaces are valid was changed after build17 so some port spaces created with build17 are not shown in current development version resp. build18.

What happens for build17 users if a prior version of map XYZ worked quite fine with build17 and a new version gets uploaded created with build18?

Well the reason I am writing all these points simply is: if we take care about versions internally in Widelands, we are basically forced to take care about the widelands version the map was created with an maybe even more. This might be a very nice feature if we plan to create an online map browser tool for Widelands, which is able to load the Map section and finally download a map - in that case Widelands would take care about map updates "A new version of this map is available online, would you like to update?" as well as compatibility "This map was created by a newer Widelands version than the one you use. Incompatibility is likely."

But as long as this is only handled by manual downloads, I prefer to not take care about all this stuff.

By the way: in one way Widelands does already take care about compatibility and map versioning: If the selected map in a multiplayer game differs between host and clients, the map of the clients gets automatically synced (which can basically mean up- or downdated)

So a clear "Don't implement this feature, as long as we do not implement the whole infrastructure!"

[Teppo Mäenpää (kxq)]

Shevonar: I do not think that there is one "right" way to do it. What do you want?

Would it make sense if Widelands would start writing, e.g., its own version number and creation time to map metadata for future use even if there were no interfaces yet? Such metadata would hardly be a privacy/security/whatever problem, and could be of some use if this question was revisited in the future. Just adding two entries to elemental, for example, would not be too much work to do.

[SirVer (sirver)]

I say, go with the simplest thing that works. That would be to handle this inside of the upload/download mechanism. How about adding the version to the description of the map when it is saved after uploading? It would show up in the game then but no additional logic would be required. Problem is that you do not know the version when you only have a file - but meh.

The maps app on the website then would be the only one needing to deal with versions.

[SirVer (sirver)]

@teppo:

You wrote:
>> However, if we do something like this, why not do it right?

Shevonar wrote:
> I am not sure what you mean by "do it right". What is the right way in your opinion?

You wrote:
> I do not think that there is one "right" way to do it. What do you want?

I thought too you had an implementation in mind. But it seems this was a misunderstanding.

[Teppo Mäenpää (kxq)]

>I thought too you had an implementation in mind

Well, I have some ideas. In GNU world, the system should, in my opinion, be planned so that branching gets handled. Small integers or so usually do not pass this test.

One way would be to use, for example, unix time, optionally suffixed by white noise. These would be simple, likely unique and sort about right. They would, however, be ugly to human eye.

Another of my favorites would be, for example, such where the prefix is incremented whenever a map is uploaded to the website, else it would remain constant (unless somebody edits the file directly). Whenever editor saves the file, it marks the file modified, possibly keeping a minor revision number. Maps shipped with widelands should be handled somehow, too. I am not sure how, maybe a second dot showing the release and omitted whenever the map is not in that category..? As you see, this is less simple, but would probably be more convenient for the user.

In the latter, version 2.15 of foo is a 15th edit of the second map "foo" uploaded to widelands website. While not perfect, this would address most things I am reading between lines in the original question. The problem with both these is that they do not attempt to address compatibilities at all. I think that that should be minded separately. Storing the revision of the executable last used to work on the map could be a part of map compatibility check.

I have not taken a look at widelands website code; actually, I do not even know where it is, and therefore am not brave enough to volunteer doing all the above. First we would need a consensus that something like map versions are needed. Once we have such consensus, it pays to think more details.

[Teppo Mäenpää (kxq)]

Of course in the example, 2.15 should have been 2.15.3405691582 or so ( dot random number ) to tell all the 15th edits from each other.

[Hans Joachim Desserud (hjd)]

>I have not taken a look at widelands website code; actually, I do not even know where it is
Here you go https://launchpad.net/widelands-website :)

[SirVer (sirver)]

I think Teppos proposition adresses all problems we see, but I also think it is quite the overkill. I personally would implement #6 and see if this solves the issues we see and if not go with teppos approach

[Teppo Mäenpää (kxq)]

Hi,

I know it is a bit an overkill, but memory-wise and cpu-wise I am only proposing adding three integers and a string to map metadata.

I think that we actually should modify widelands to load & save those data to maps now, before the approaching feature freeze: Done that way, and maps are most likely compatible between coming stable release and future development builds with version number display properties. The alternative is to have a longish ( 1 to 1 1/2 years) period, when maps made with development builds and uploaded to widelands site might not be compatible with then-latest release.

In short: Unless you reject this feature request completely, I propose modifying widelands to load and save all the map version information listed above. The worst that can happen is that some of those version fields would eventually not be used, causing few waste lines of map load/save code and ten-ish bytes of wasted data memory.

[SirVer (sirver)]

No, I am not against doing it that way. If you feel that this is the right approach and you are interested in implementing this, go ahead.

[Teppo Mäenpää (kxq)]

I do not have much time just now, but anyway, I made a short start. I tried to keep it simple, hoping that no new bugs would be introduced.

The attached code loads and saves version data to map files, and steps the minor revision. Nothing is displayed to the player yet, though

I would like this to go to the trunk this week.

Having revision data in map files made with latest trunk might be handy later on.

If you disagree and do not wish to merge now, I understand.

[SirVer (sirver)]

Could you propose the branch for merging so that we can have a look at the diff?

I feel that we should not rush this into b18 - if you plan to address this feature more throughoutly after b18 especially. My reasoning is that we will later realize that the format of the revisions we choose is not good enough/different than what we really want to have (I expect this to come up during the implementation), but if we have this in b18 already we have to deal with compatibility. So unless you feel super strongly about putting this into b18, I'd rather not.

Not sure if I am too cautious with this though. What do others think about this?

[Teppo Mäenpää (kxq)]

You are right -- there is a possibility that minds change while working with implementation details.

I added a forward compatibility flag to the version file, to make the possible problems harm less. Of course, I cannot think of any right now, but that is a really bad argument.

Not doing this means that maps made by majority of people -- everybody running latest release -- will not contain the revision information. I see that a handicap, but I agree that the argument you just said could outweigh this.

I still would like to see this appearing to b18, but like I said, you may still decide that it is better not to do that.

[Teppo Mäenpää (kxq)]

I see the work flow to be the following:

1) Make the widelands executive aware of version numbers (like so that those are not lost while editing)

2) Modify the makefile to add version data to each bundled map as a part of the build process

3) Modify the web site map version aware: There can be more than one version of each map, possibly so that also older versions could be loaded.

4) Modify widelands so that it displays revision data to user at least in a load map screen.

I assume that steps 2 and 3 might take time: No previous experience with cmake or widelands website, to start with.

[Teppo Mäenpää (kxq)]

Continuing list in comment 17:

5) Make multiplayer start window version-aware: If people are using different versions, sync.

[Teppo Mäenpää (kxq)]

What is still needed to make this bug report complete?

[Launchpad Janitor (janitor)]

[Expired for widelands because there has been no activity for 60 days.]

[SirVer (sirver)]

In my mind, this bug report is complete. We just do not do anything with the map versions jet. That should probably be a new bug report though.

[SirVer (sirver)]

Released in build-18 rc1.