Update of bug #15743 (project freeciv):
Status: Fixed => Ready For Test
Open/Closed: Closed => Open
Follow-up Comment #8:
> value saved as S_LAST of freeciv version that did the save
> will be restored as S_LAST of freeciv version doing the load.
Ooh, that's deeply cunning. It makes everything much simpler.
Unfortunately, the one place where S_LAST is saved/loaded -- unit pillage
activity -- doesn't actually use special.order!
savegame2.c:sg_load_player_unit() reads "activity_target" from the savefile
and directly casts the number into a tile_special_type, rather than
indirecting through special.order as it should.
Easily fixed, and probably has not caused a bug yet because we've not
re-ordered the specials for a long time.
Also, I think savegame.c requires the same two fixes (the one already applied
and the one above).
While trying to fix the above, I found more dependencies on the current
specials when loading savegames:
* When loading savefiles, halfbyte_iterate_specials counts enough halfbytes to
fit the current S_LAST, whereas it should count up to the number of specials
in the savefile "specials_vector". If the number of specials were ever to
reduce significantly, this could lead to warnings and incomplete loading of
* In savegame.c, the number of specials in "specials_vector" is not recorded,
so various accesses to specials_order could cause a buffer overrun.
Attached patch fixes all this. Tested that it doesn't break saving/loading of
specials/activities in S2_2/S2_3 savegames, and that it improves things in
test servers with more / reordered S_*.
(file #15563, file #15564)
Additional Item Attachment:
File name: trunk-robust-special-loading.diff Size:11 KB
File name: S2_4-S2_3-robust-special-loading.diff Size:12 KB
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list