forum.freeciv.org

Everything to this point has been developed on the experimental version of fc 2.6.0 but has been qualified on fc 2.6.5 using my civ1 ruleset. I see no reason for any problems to occur with any 2.6 ruleset, or indeed, any 3.x ruleset as currently formulated.

WOW!

Hail the brave knight fighting through this grim dungeon full of treacherous traps and unspeakable monsters!

I once tried to fix fsd but my poor programming skills suspended the work for an indefinite time. I hope you'll provide some progress for HRM#880895 and HRM#819533 that I've abandoned.

I think find.nonexistent() in v.3.1 shall get an optional parameter of (int) pointer, that will become the object's "id". There will be some messup with the id of the deleted real object but it's soluable by the scriptor.

The problem of saving metadata by id while the ruleset might change is a good finding. I doubt it is technically a bug, we can change the rule names as well, but surely debugging scenarios with special rulesets is a mess without saving by name. Thanks! (Though, alas, due to scripting engine poverty there are yet few scripted scenarios for Freeciv any way I opened some osdn tickets in attempt to fix that.)

Very generous, but I have the advantage of not having to write anything in c.

I read your script (in the patch) with some interest and I had a real sense of deja vu since many of the features had been considered, but in the end, only a few survived as I progressively discovered the treacherous traps and unspeakable monsters. I think the final result came from not being too ambitious. I reckoned that if scribes were needing tables to be saved then they would be up to writing the _fc_restore function even if that meant creating companion 'instruction' tables. After posting the functions I returned to a project that I had interrupted and discovered a possible oversight: that of signal connections. Mostly these are done by script.lua or default.lua but not always. I think this is doable in fsd but for now I intend to leave it for _fc_restore. (Perhaps someone can inspire me.)

I think find.nonexistent() in v.3.1 shall get an optional parameter of (int) pointer, that will become the object's "id". There will be some messup with the id of the deleted real object but it's soluable by the scriptor.

The problem with find.nonexistent() with an id is that there are three distinct sets which I presume could contain duplicates across the sets. One could mess with shifts in ranges to make them non overlapping but that would be a hack. Still, it may be better than the hack I used. If it`s not too late one could consider adding another arg. indicating the userdata type so that duplicate id`s would create distinct versions of Nonexistent.

The problem of saving metadata by id while the ruleset might change is a good finding. I doubt it is technically a bug, we can change the rule names as well, but surely debugging scenarios with special rulesets is a mess without saving by name.

The point I was trying to make is that preserving rule_name is an acceptable (and necessary) requirement for save file compatibility. The additional requirement of preserving the order of sections is capricious and I regard it as a bug because it leads to restore failures.

Ticket about replacing listenv() with fce() : osdn #43388

I have updates for both fce and fsd which are ready but I want to do some last minute checks. I will publish them next week. fce actually has a bug.

As a sharp reminder (again) that no one has a monopoly on wisdom, I noticed an issue identified by Ignatus in his patch script, this being the effect of locale on the representation of floating point numbers. I don`t know whether this is or is not an issue for the vars script but to be safe I have changed fsd back to the way I originally wrote it (using %q). Unfortunately, this makes for poor legibility - good for Lua but not for humans. Choose your poison: I have left alternatives as comments. I also note that the Official Lua Manual advises the use of %q because this preserves complete precision but this is unlikely to ever be an issue with fc.

I have now seen the patches (by Ignatus) for Direction objects and the new design (for fc3.1) should be sufficient for the (new) replacement version of fsd to automatically save and restore Direction objects. A change was needed because Direction uses .name rather than :rule_name(). For consistency, the latter should be added (returning the same as .name). Before 3.1 is actually released this issue should be reviewed.


I reconsidered the issue of saving callbacks, in part because it was easy to do. The salient point is that while Lua scribes may be aware of other 'packages' in the script they may not be able to control the set of callbacks. So, as a compromise, I have added code to fsd that will save the state but not recreate it. It is left to the scribe to decide what to do. To enable this decision the vars script will provide _fc_restore with a third argument. Considering the current (lack of) interest in Lua I`m not expecting this to be needed any time soon, but I wanted to finish off this loose end.

As an illustration of how to use this table one might use as a reference:
NOTE: this is NOT a panacea. Customisation will almost certainly be needed. In normal situations, the code will not be needed (but equally, will also be harmless).

Strings can now have unprintable characters: for these the string will be represented by a function call of the form string.char(...) with the argument list being the (decimal) codes for each character in the string.

Code has been added to the vars script to prevent interaction with the "unit_loss" callback.

Finally, there were some additional minor changes of no particular interest. All cosmetic.

fce has also been updated:

An untested frill resulting in fce crashing when it encounters data of subtype City has been fixed.

The printout of the metatable for data of type string became boring so is now suppressed. Old behaviour can be restored using a new argument. Instead, one should do fce(string) to see the list of methods (or RTFM).

nef wrote:

The problem of saving metadata by id while the ruleset might change is a good finding. I doubt it is technically a bug, we can change the rule names as well, but surely debugging scenarios with special rulesets is a mess without saving by name.

The point I was trying to make is that preserving rule_name is an acceptable (and necessary) requirement for save file compatibility. The additional requirement of preserving the order of sections is capricious and I regard it as a bug because it leads to restore failures.

The very reason rule_name exist (separately from name) is that it preserves savegame compatibility even if we want to change the name.

What I had not realized before just now is that we can switch to using saving by rule_name (where ever available) even on branches with an active d3f. As long as the generated script uses the frozen API, it does not matter which parts of that API it uses (i.e. the actual calls one version generates can be different from what another version generates, and they still can both each other's savegames) That might be something to look at during 3.0.2 cycle.