Reply To cazfi
It might make sense to save city_counters_order instead of order of global counters list
I think it would get unnecessary complicated to figure out counter indices in the city counters list if we had only order of global counters list, so let's save city_counters_order.
Reply To cazfi I send first patch.
Maybe you should start by saving the city counters order; "savefile.city_counters_size" and "savefile.city_counters_vector". See handling of action order ("savefile.action_size" & "savefile.action_vector") for example.
Reply To cazfi
Maybe you should start by saving the city counters order; "savefile.city_counters_size" and "savefile.city_counters_vector". See handling of action order ("savefile.action_size" & "savefile.action_vector") for example.
I send patch, which save city counter indexes in correct order
You should save counter names to the order vector, not ids. If the counters get reordered, ids that anyway get assigned in order from 0 to MAX would not refer to the same counter as before.
Reply To cazfi
You should save counter names to the order vector, not ids. If the counters get reordered, ids that anyway get assigned in order from 0 to MAX would not refer to the same counter as before.
I think we save entire ruleset, so the each-counter-related information too. Counter should not change order during gamplay, if freeciv save ruleset.
Reply To lachu
I think we save entire ruleset
No, we don't. That's the entire point of these "xxx-order" vectors.
We also can't save the ruleset, as format of those is specific to a freeciv version, and savegame loading must be backward compatible over several versions.
Sorry for you must wait too long... I save counter (city) names instead of global position.
Reply To cazfi
No, we don't. That's the entire point of these "xxx-order" vectors.
Read my post above.
Looks good so far. Just one code line is a bit long, so last parameter in the function call should be placed to a new line.
It also works; got this in the savegame:
city_counters_order_size=1
city_counters_order_vector="Owned"
Next step would be to save the counter value for each city. We need that even for the minimal patch to push to the repository - in it's current form it creates inconsistent savegames in that the "city_counters_order_size" claim there to be 1 counter saved for each city, but actually no counters are saved.
Reply To cazfi
Next step would be to save the counter value for each city. We need that even for the minimal patch to push to the repository - in it's current form it creates inconsistent savegames in that the "city_counters_order_size" claim there to be 1 counter saved for each city, but actually no counters are saved.
It's probably cleanest to save them in a new "counters" section, as vectors where first element is the city id (in case of city counters), and rest are counter values:
c0000=100,1,...
c0001=101,1,...
c0002=102,2,...
I'm open to different savegame format, if someone has a better idea.
Reply To cazfi
Looks good so far. Just one code line is a bit long, so last parameter in the function call should be placed to a new line. It also works; got this in the savegame: city_counters_order_size=1
city_counters_order_vector="Owned" Next step would be to save the counter value for each city. We need that even for the minimal patch to push to the repository - in it's current form it creates inconsistent savegames in that the "city_counters_order_size" claim there to be 1 counter saved for each city, but actually no counters are saved.
Split function invocation patch added:
Reply To cazfi
Reply To cazfi
Next step would be to save the counter value for each city. We need that even for the minimal patch to push to the repository - in it's current form it creates inconsistent savegames in that the "city_counters_order_size" claim there to be 1 counter saved for each city, but actually no counters are saved.
It's probably cleanest to save them in a new "counters" section, as vectors where first element is the city id (in case of city counters), and rest are counter values: c0000=100,1,...
c0001=101,1,...
c0002=102,2,...
I'm open to different savegame format, if someone has a better idea.
I see (in sg_save_player_cities), there are information about city saves as plr(player_number).cty(city_number_related_to_player) is saved. What about making similar? It could be more readable form.
Reply To cazfi
Reply To cazfi
Next step would be to save the counter value for each city. We need that even for the minimal patch to push to the repository - in it's current form it creates inconsistent savegames in that the "city_counters_order_size" claim there to be 1 counter saved for each city, but actually no counters are saved.
It's probably cleanest to save them in a new "counters" section, as vectors where first element is the city id (in case of city counters), and rest are counter values: c0000=100,1,...
c0001=101,1,...
c0002=102,2,...
I'm open to different savegame format, if someone has a better idea.
Done in way you suggest.
From CodingStyle:
- Use the postfix operator instead of the prefix operator when either will
work. That is, write "a++" instead of "++a".
Otherwise looks good.
Splitting this ticket to saving part (which is almost done), and a separate ticket to do the loading part -> #43426
There's no need for both of them to get pushed in to the repository at the same time, so splitting allows us to get this saving part in as soon as it's ready.
--
I think we should also implement the "Should also save boolean indicator that the freeciv revision doing the saving has hardcoded_counters." -part from the original description. Should probably go to "game" -section, i.e., "game.hardcoded_counters", always saved as TRUE.
Reply To cazfi
Splitting this ticket to saving part (which is almost done), and a separate ticket to do the loading part -> #43426 There's no need for both of them to get pushed in to the repository at the same time, so splitting allows us to get this saving part in as soon as it's ready. -- I think we should also implement the "Should also save boolean indicator that the freeciv revision doing the saving has hardcoded_counters." -part from the original description. Should probably go to "game" -section, i.e., "game.hardcoded_counters", always saved as TRUE.
Done
Save and load counter information. This require saving the order (counters_order), and the city counter values. It might make sense to save city_counters_order instead of order of global counters list - this is to be decided. Should also save boolean indicator that the freeciv revision doing the saving has hardcoded_counters. There's no need to read it yet, but it's there in the savegame for the benefit of the future freeciv revisions loading it.