Loading savegame with build 5784 does not work anymore

Bug #691909 reported by Andreas Breitschopp
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
High
Unassigned

Bug Description

When loading the attached savegame with the current build 5784 I always get this error:
"productionsite (Arena): site has carrier, for which there is no free working position."

I also found already the core of this problem:
the last BZR change of the file "/tribes/barbarians/battlearena/conf".

I reverted this last change and the savegame loaded correctly again.

Of course, I know that within dev builds the savegame compatibility is not always assured, but maybe it is still possible to make it compatible for the config change above.

Revision history for this message
Andreas Breitschopp (ab-tools) wrote :
Revision history for this message
Nicolai Hähnle (nha) wrote :

I've recently added some features that make savegame compatibility easier. In this case, try adding the following to the battlearena conf:

[compatibility working positions]
carrier=flash trainer

Revision history for this message
Andreas Breitschopp (ab-tools) wrote :

Hello Nicolai,

thanks for your fast reply.

But with this addition to the conf I get a different error message:
"Karten-Objekt: unbekannter Objektkopf 1"

Revision history for this message
Hans Joachim Desserud (hjd) wrote :

When initially loading the game, I get the same error message about the battlearena.
Tried to add Nicolai's suggestion to battlearena conf which results in "map objects: unknown object header 1" (which is the English translation of the error in comment #3). I tried to insert the line at different places in the conf-file, but still the same error.

Changed in widelands:
status: New → Confirmed
Revision history for this message
Andreas Breitschopp (ab-tools) wrote :

Yes, this issue seems to be still unresolved:
the only thing that worked for me was to manually revoke the last BZR change of the file "/tribes/barbarians/battlearena/conf".

But that's not a solution of the problem itself, of course.

Nasenbaer (nasenbaer)
Changed in widelands:
milestone: none → build16-rc1
importance: Undecided → High
Revision history for this message
Nasenbaer (nasenbaer) wrote :

the problem is the different saving program of carrier and "normal" workers. Anyone an idea how to fix this?

Revision history for this message
Nasenbaer (nasenbaer) wrote :

I tried to write a hack (see lp:~nasenbaer/widelands/fix-try-691909), but the problem is, that the boolean value m_was_carrier gets somehow reset before the worker is loaded from the savegame - perhaps because of the replay writing/reloading?

Currently I have no clue how to get that last part fixed...

Nicolai you wrote the replay code and the conversion fix. Do you have a clue? :)

Revision history for this message
Nasenbaer (nasenbaer) wrote :

changed the branch to lp:~widelands-dev/widelands/fix-try-691909 so all in widelands-dev group can commit to the branch.

Revision history for this message
Nicolai Hähnle (nha) wrote :

Should be fixed in r5872. The fix is still quite ugly, but hopefully a bit cleaner than keeping Carriers around that aren't actually carriers.

Changed in widelands:
status: Confirmed → Fix Committed
Revision history for this message
SirVer (sirver) wrote :

Released in build16-rc1

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.