Game data error: inputqueue: workersqueue: not found

[Benedikt Straub]

I get this error with a savegame I created while testing the 3rd frisian scenario:

GameLoader::load() took 28642ms
Game not loaded: Game data error: buildingdata: building 6052: productionsite (Kasern): inputqueue: workersqueue: not found

This appears immediately after the loading is complete, then the game crashes.

[GunChleoc (gunchleoc)]

Some log output from a testing branch I created.

NOCOM productionsite frisians_barracks has 2 ware queue(s)
NOCOM Add InputQueue for ware sword_short index 16
NOCOM Add InputQueue for ware fur_garment index 11
NOCOM productionsite frisians_barracks has 1 worker queue(s)
NOCOM Add InputQueue for worker frisians_carrier index 95
NOCOM loading worker with serial 6588 name frisians_blacksmith
NOCOM loading worker with serial 20098 terminate called after throwing an instance of 'Widelands::GameDataError'
  what(): not found

The worker serials loaded into the barracks are utter nonsense. It's the first worker queue being loaded with this savegame.

Now the question is whether we just have a corrupt savegame or if there is an actual bug.

[Benedikt Straub (nordfriese)]

I played the scenario in question several times from the beginning and the result after saving is always the same, so it´s not just one corrupt savegame.

The barracks that is failing here is added (together with many other buildings) via scripting like this:
      local b = p1:place_building("frisians_" .. bld, fields[field], false, true)
      if b.valid_inputs then b:set_inputs(b.valid_inputs) end
      if b.valid_workers then b:set_workers(b.valid_workers) end
Perhaps this makes a difference somehow?
Or perhaps the economy is somehow so complex that the savehandling gets confused? (If you want to look at the game, the scenario is in my fri03 branch; play until the connect_farms objective is done, then save)

[GunChleoc (gunchleoc)]

I think that connecting 382 farms for testing is not that much fun... to I reduced the number to 2, connected them and did nothing else, and then waited and got a coroutine error:

Error in Lua Coroutine
[/home/bratzbert/sources/widelands/bug-1795871-workersqueue-not-found/src/scripting/lua_errors.cc:22] [string "scripting/mission_thread.lua"]:36: attempt to call a nil value (method 'is_flag_reachable')
Send message to all players and pause game

[GunChleoc (gunchleoc)]

Actually, it's sufficient to start the scenario and then save immediately to get a corrupt savegame.

The Lua line that triggers the bug is

    if b.valid_inputs then b:set_inputs(b.valid_inputs) end

NOCOM writing worker queue frisians_carrier
NOCOM writing file_index 746
NOCOM writing file_index 1544
NOCOM writing file_index 740
NOCOM writing file_index 741
NOCOM writing file_index 742
NOCOM writing file_index 743
NOCOM writing file_index 744
NOCOM writing file_index 745
NOCOM *************************************

NOCOM Add InputQueue for worker frisians_carrier index 95
NOCOM loading worker with serial 746 name frisians_reindeer_breeder
NOCOM loading worker with serial 1544 -> unknown object

[GunChleoc (gunchleoc)]

I have traced the bug to WorkersQueue::write_child, where mos.is_object_saved(*w) is false for some workers. I have no idea yet why though.

[GunChleoc (gunchleoc)]

I still haven't found the bug.

I have pushed a hack that will fix saveloading so that Nordfriese can continue his work, but I'd like Notabilis to have a look to double-check that the problem is indeed the load order only and not another bug that I've been unable to find.

If there is no other bug, we could try
1. moving the loading code into load_finish(). (preferred solution)
2. Alternatively, save important values like worker experience manually. (meh)

[GunChleoc (gunchleoc)]

P.S. there is a new test case in the attached branch

[Notabilis (notabilis27)]

I looked into it and it is indeed another bug unrelated to saving or loading. When training a soldier in the barracks the game crashes as well since the referenced carriers have been removed.
As far as I see it, the bug is either in lua_map.cc in the function do_set_workers() or in the WorkersQueue. The function is called in the script to add the trainer to the barracks.

The problem is that the input-workers (carriers to be trained) are added as workers to the building (PlayerImmovable) by the WorkersQueue. This is something different than adding a worker-worker (trainer) to the building (Productionsite).
The set_workers() function is called from the script to add the trainer (and all other worker-workers of the building), but within the function all other workers (any kind) currently in the building are removed (all present workers that are not listed in the given parameters, see line 376f). Since the carriers have not been listed as to-be-added, they are removed from the building but not from the WorkersQueue, leading to problems when trying to save the queue or to use one of the contained carriers for training.

Possible fixes within do_set_workers():
- Don't add the present workers that can't work in the building to the list of workers to be removed (line 372)
- Or ignore all modify-assignments for workers that are not valid worker-workers (line 384)

An alternative approach would be to modify the WorkersQueue to not assign the stored input-workers to the immovable they are "waiting" in, but personally I would prefer to keep it that way (just feels right to handle them that way, no real reason).

[GunChleoc (gunchleoc)]

Fixed in build20-rc1