Loading savegame with build 5784 does not work anymore

Bug #691909 reported by Andreas Breitschopp on 2010-12-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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.

Andreas Breitschopp (ab-tools) wrote :
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

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"

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
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) on 2010-12-30
Changed in widelands:
milestone: none → build16-rc1
importance: Undecided → High
Nasenbaer (nasenbaer) wrote :

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

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? :)

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.

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
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  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments