Backwards compatibility for savegames within stable branch
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
- irrevenant
- Moderator Emeritus
- Posts: 3692
- Joined: August 15th, 2005, 7:57 am
- Location: I'm all around you.
Backwards compatibility for savegames within stable branch
The release info for 1.2.2 states:
"Savegames were cleaned up to be a little smaller. Because of this only beginning of scenario saves will work as expected"
IMO, it's not appropriate for saves to break within sub-versions of the Stable branch.
If the save format needs to be changed within the stable branch, can't Wesnoth at least retain a load function for the legacy format as well?
"Savegames were cleaned up to be a little smaller. Because of this only beginning of scenario saves will work as expected"
IMO, it's not appropriate for saves to break within sub-versions of the Stable branch.
If the save format needs to be changed within the stable branch, can't Wesnoth at least retain a load function for the legacy format as well?
Want to post a Wesnoth idea? Great! Read these:
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
Re: Backwards compatibility for savegames within stable bran
Agreed.irrevenant wrote:IMO, it's not appropriate for saves to break within sub-versions of the Stable branch.
Re: Backwards compatibility for savegames within stable bran
+1irrevenant wrote:IMO, it's not appropriate for saves to break within sub-versions of the Stable branch.
Wesnoth sacrificed balancing to savegame comparability. Why we sacrificed comp. to size of savegames?
That replays don't work anymore is simply a bug and not intended. It's considered ok that only start of scenario saves work but that replays don't is a bug which will hopefully get fixed. We just didn't have enough testers to spot it early enough.
As for why such an invasive change got done - the main complains about 1.2 were speed. Lobby, gameplay and for autosaves. Fixing a problem always carries the risk to create another one along.
As for why such an invasive change got done - the main complains about 1.2 were speed. Lobby, gameplay and for autosaves. Fixing a problem always carries the risk to create another one along.
WesCamp-i18n - Translations for User Campaigns:
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
http://www.wesnoth.org/wiki/WesCamp
Translators for all languages required: contact me. No geek skills required!
- irrevenant
- Moderator Emeritus
- Posts: 3692
- Joined: August 15th, 2005, 7:57 am
- Location: I'm all around you.
It's good to know that the breakage wasn't intentional, but the breakage was noted in the release announcement.
That means that somewhere along the line, someone knew that this update broke savegames and released it anyway before that bug was isolated and dealt with.
I would consider breaking backwards-compatibility to be a 'release-critical' bug.
That means that somewhere along the line, someone knew that this update broke savegames and released it anyway before that bug was isolated and dealt with.
I would consider breaking backwards-compatibility to be a 'release-critical' bug.
Want to post a Wesnoth idea? Great! Read these:
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
Frequently Posted Ideas Thread
Giving your idea the best chance of acceptance
-
- Retired Developer
- Posts: 1086
- Joined: September 16th, 2005, 5:44 am
- Location: Hamburg, Germany
Ok, as the one being responsible for this i would like to say a few words.
First, i agree with all of you that there should be a full backwards compatibility. And i will do the best i can to provide that.
Second, there is this magic triangle of all project work: Time, cost, quality, choose whatever two you want and sacrifice the third. Ok, we don't have cost here as i am not getting paid but if you can't invest much time into developing (like me) you have to carefully manouever between two pitfalls: Either you take the time you need and have major problems to integrate your work because the code has changed a lot in the meantime. Or you try to accomplish a semi-stable state for the next release, knowing that bugs sneak in and there is still work to do. There is a third option (delay the release until everybody is done) but i don't regard it to be a practical one. It would just take too much time altogether with so many devs involved.
I choosed the second option (semi-stable state), that's why you still experience problems here.
Third, my major concern to change the savegame functionality was not performance. It was the fact that a couple of replays didn't work out (mostly WML-intensive ones like for example Defense-of-the-XXX). Fixing those bugs is tightly coupled to the savegame format. Touching one means dealing with the other as well and so i decided to fix the whole complex. I didn't see any other way than to live with those bugs that are mostly fixed now. Of course having lean savegames is a nice side effect.
Again, my intention is to reach full backwards compatibility but my resources are very limited. So please be patient and let's hope for the best .
First, i agree with all of you that there should be a full backwards compatibility. And i will do the best i can to provide that.
Second, there is this magic triangle of all project work: Time, cost, quality, choose whatever two you want and sacrifice the third. Ok, we don't have cost here as i am not getting paid but if you can't invest much time into developing (like me) you have to carefully manouever between two pitfalls: Either you take the time you need and have major problems to integrate your work because the code has changed a lot in the meantime. Or you try to accomplish a semi-stable state for the next release, knowing that bugs sneak in and there is still work to do. There is a third option (delay the release until everybody is done) but i don't regard it to be a practical one. It would just take too much time altogether with so many devs involved.
I choosed the second option (semi-stable state), that's why you still experience problems here.
Third, my major concern to change the savegame functionality was not performance. It was the fact that a couple of replays didn't work out (mostly WML-intensive ones like for example Defense-of-the-XXX). Fixing those bugs is tightly coupled to the savegame format. Touching one means dealing with the other as well and so i decided to fix the whole complex. I didn't see any other way than to live with those bugs that are mostly fixed now. Of course having lean savegames is a nice side effect.
Again, my intention is to reach full backwards compatibility but my resources are very limited. So please be patient and let's hope for the best .
Smart persons learn out of their mistakes, wise persons learn out of others mistakes!
That's a given. I simply reinstalled 1.2.1 until you fix the bugs. Take the time you need, and keep up the awesome work. Thanks a lot =)Yogi Bear wrote:Again, my intention is to reach full backwards compatibility but my resources are very limited. So please be patient and let's hope for the best .
EDIT: While you're at it... There's still this bug: game crashes to desktop when you try to load a game during opponent's turn, in campaigns. Specifically, it seems to happen more when you do it while a unit has been killed and is in the process of disappearing/finishing its death animation.
Hard work may pay off in the long run, but laziness always pays off right away.
-
- Posts: 319
- Joined: February 22nd, 2006, 1:10 pm