Global vars weirdness on load in Freeciv 2.6.4 with GTK2 client

[Molo_Parko]

In Freeciv 2.6.4, commands in the code section of a scenario .sav file run on load, before global vars are set to values shown in the scenario file. I ran across this issue because sav files were loading with nil values despite the vars being set in the scenario file [script]vars=$$ section.

To test this, set test=50 in vars section of scenario .sav file, and test=75 in code section of scenario file (example scenario file is attached to this post.)


^ Commands in code section run after clicking "OK"... but global vars are not set yet (see image below.)



^ Code section command has set test=75 BEFORE clicking "Start".

Code: Select all

/lua log.error("%s","test=" .. tostring(test))

^ But pasting the command shown into client chat pane shows test=50, despite that code section commands have already run and set test to 75!



^ Then click start and turn 0 shows test=50 from vars! The 75 is just gone, replaced by value in vars once "Start" is clicked. (Or possibly before clicking "Start", since gtk2 client shows value at 50 despite it having just been set to 75 in code section.)

Code: Select all

[script]
vars=$test=50
$
code=$
test=75
log.error("%s","test=" .. tostring(test))

function tester(turn, year)
	log.error("%s","tester: test="..tostring(test))
end
signal.connect('turn_started', 'tester')

tester(-1,-1)
$

Test's value is initially nil prior to code section command to set it to 75. Then after clicking start test is 50.

[cazfi]

"vars" has the current (saved to the savegame) value, whereas code section can adjust the value when ever some lua script runs. So the behavior you're describing seems correct to me. After loading the savegame variable has the saved value.

[Molo_Parko]

When I load the scenario, after clicking "Ok" in the gtk2 client, and before clicking "Start", commands from the scenario's script section have already run and do not have the correct values as saved in the scenario's [script]vars=$$ section.

It appears that the script commands (which are not inside any function) are being run before the global variables' values have been restored.

Code: Select all

vars=$test=50
$
code=$log.error("%s","test=" .. tostring(test))
$

The result of the log.error command above is "test=nil" not "test=50"! The command ran before the var's saved value was restored.

I expected that all the vars would be restored prior to execution of any Lua script commands, but that is not true.

Only after clicking "Start" in the gtk2 client are the global variable values correct for script commands, but the script commands had already run with the nil values.


^ I hadn't even clicked "Start" yet but the commands had already executed as is shown by the presence of the red log.error text in the image above.

[cazfi]

In Freeciv 2.6.4

Even if you want to stick with freeciv-2.6, latest bugfix release is 2.6.11.

Ok, there's something weird in the behavior you see. While I'm not sure it's a wise design choice, it seems to be intentional that global code runs before saved variables are restored. I guess the idea is that one can have global initializations to run in the beginning of the game without thinking the complexity of the same code running correctly/differently on save game load. In case of save game load, the saved variables just override the initialization values. However, this override should happen immediately after running the global code, not only once use /starts the game.

In any case I think that the idea is to have "vars" empty in the original scenario file, and only be placed by the game saving code to the later savegames.

[Molo_Parko]

Even if you want to stick with freeciv-2.6, latest bugfix release is 2.6.11.

I try not to update anything at all unless it is so broken that I can't work around any problems or security issues. I'll have to get a newer machine soon anyway, and will probably jump to Freeciv 3.x at that time -- although I still don't think that I've tried all the features of v2! The release rate is too quick!

In any case I think that the idea is to have "vars" empty in the original scenario file, and only be placed by the game saving code to the later savegames.

I'll try that, I was working on restoring table data from string variables after save/reload, when I noticed that sometimes the backup string variable values were available on reload, and sometimes not until 1 turn later, which interfered with the table restore process until "End Turn" was clicked. Then I started trying to figure out exactly what was happening and ended up removing all the scripts, leaving a few loose commands in the scripts section (not within any function) and the strange behavior of the saved values only being restored after the commands had already run.

[Molo_Parko]

I eventually got around the problem of script command execution prior to global vars being restored (which was happening on unit_moved and/or city_destroyed and city_transferred signal during a reload of a saved game.)

I added river to a specific tile in the scenario map. At the beginning of the scenario's script code section, placed commands to check for the presence of river on the specific tile. The commands should be "loose" rather than within any function. If river is present on the tile then it is turn 0 just prior to game start, remove river from the tile. Subsequent reloads will no longer find river on the specific tile and thus the script can differentiate turn 0 from any reload. If it is a reload, then call a "setup" function* to re-define needed functions and global vars ( to the extent possible before real data values are restored at "End Turn".)

* = actually set a flag to run the setup function (_G.ReloadDetected), then define the setup function in the script, then call it with a loose command just following the setup function (as in if _G.ReloadDetected then call the function just above the command.)

Then it is possible to work-around the issue of unit_moved or other signals issued prior to the global vars data being restored.