Topic: why are older saves not compatible with new versions?

the tl;dr answer for this is probably because Widelands is not a commercial product. But I also think your assessment is misleading and the judgment of your brother overly simplistic. Please read on.

The first sentence of your post is misleading. Yes, currently it is true, but it has not been for a long time. In fact, b18 and before we always strived to make games backwards compatible for at least three releases - and in fact, b18 can open games saved with b15, b16 and b17. For b19 I suggested that we break backwards compatibility to clean out the code base - which we did, we lost several thousand lines of code that modeled old state that would never be used again - except for loading old savegames. After b19 we will try to keep games backwards compatible as much as possible again.

at those coordinates there is a well that started working 11907 milliseconds ago, at those other coordinates there is a log directed to those other coordinates... there should be absolutely no reason a saved game stops being compatible with a newer version.

This is an oversimplification. Let me give you an example of something that broke a while ago: Militarysites used to derive from Productionsites which dervice from building which derive from map object. It makes no logical sense why a Militarysite should be a productionsite (it violates the is_a modelling scheme as well as the Liskov substitution principle and it made adding new features to either class very hard). So I wanted it changed, I think Gun did the change. For the player, this change is invisible - it does not affect the logic of the game. For the game saver though it is huge: the in-memory representation of a miltarysite looks very different now, so the old saving code is not working at all anymore.

It would have been possible to add code now that loads a building first as an old miltiarysite in memory representation and then copy the data over into the new structure one by one. But this would require that the old militarysite code would need to stay around indefinitely - still restricting the evolution of productionsites. Between b18 and b19 we opt to not do that, modernizing the code base without introducing legacy code in the process.

A second example is the introduction of Lua as our scripting language. Before, we had our own shitty trigger/event system. Lua allows us to do a lot of complex stuff (see all win conditions, the atlanteans mission with the rising water), but of course it's representation has nothing to do with trigger and events. Porting this would have been virtually impossible - I guess, some 30k lines of code or so, so we did not do it.

My stance on this is this: old code is not fun to work with and breaks more often. Programmers are customers too - even more than players, really, because they are more important to the evolution of the project. So bringing the code base into a state that it is easier to work with is worth annoying players for one version bump.

especiallly coupled with the incomprehensible policy of trying to force people to update to new versions without keeping older ones

I cannot comment on this "policy". I guess it is a default setting of our windows installer and thinking about it, it is probably the right decision for most players. Very few will be interested in having more than version of Widelands installed, so this should not happen on accident.

is there some reason for the version incompatibility?

yes, of course. :). I hope I could make it a little more understandable why we chose to do things for one version bump this way. I am sorry that you find it annoying.

Top

Quote

I don't know if it was possible to load a savegame form settlers1 into settlers2 or later. I believe it wasn't.

As GunChleoc says, all versions after build18 are currently development versions (alpha versions) and thus it is under development and things can change. So your question is some kind of unfair because it is related to development versions and not to final releases.

But your question is importand in so far, as we have to tell the widelands players that savegames from build18 are not compatible with build 19... once build19 will be released...

Fight simulator for Widelands:
https://wide-fighter.netlify.app/

Top

Quote

I hope you don't feel like we're ganging up on you here - I do understand why you would find it annoying. I do as well when I'm trying to fix a bug and the attached savegame can't be loaded any more

Busy indexing nil values

Top

Quote

ok, thanks for explaining, but i still would like one more clarification.

so sirver said that there used to be backwards compatibility, but it was broken to "straighten" the code. which is ok. but then, i would expect that the versions would remain backwards compatible up to a certain point, then the code was rewritten, and then future versions would still be bckwards compatible down to that point. even if the new code is written and implemented a bit at a time, i would expect that at some point the backwards compatibility would be restored. so by the fact that 7907 can't open 7852 I should surmise that there are still those kind of code changes being introduced? if so, how long before we could reasonably expect that backwards compatibility will be restored from that point into the future?

One thing that probably backfires against the development is that the unofficial trunks have become something of an "unofficial official build". all the maps posted in the last year or 2 are incompatible with build18, and there are new features that people take for granted, to the point that the first thing a new guy on the forum is told is that he should try the latest versions. even the tournament was played mostly on the trunks, and it was one year ago. if those trunks were really unofficial it would be less bothering, but it feels like they are really the official build.

Top

Quote

kaputtnik wrote:

Yes it bothers me also a lot...

Just like the changes to the lua files which broke my own data directory several times. GunChleoc, are these changes completed now?

Except for the help system that I am currently still working on, yes. Unless I encounter something unexpected.

Oh, and I'm still trying to get the new font renderer to work. That will have an impact on all formatting an scenario/campaign/help scripts. So, I think we get that one into Build19 in some form, so we won't break everything again during the next release cycle.

Busy indexing nil values

Top

Quote