Upgraded workers not requested properly in productionsites

[GunChleoc]

Reported on the forum:

Recently I noticed that a workers place in a new built mine will only be occupied by exactly a miner with the requested level. This means that a mine where for example a level 2 miner is missing is not occupied although there are some level 3 miners available in the warehouse. In the past a free level 3 miner did occupy any "employment" possible. A level 2 miner did occupy any open level 1 or level 2 working place. Again my questin is this intentional. If yes I'd like to suggest to go back to the old behaviour, because currently you collect level 3 miners in your warehouse. (in my game I had 18 level 3 miners in the warehouses and 5 mines not occupied).

https://wl.widelands.org/forum/topic/1928/?page=1#post-16538

See also https://bugs.launchpad.net/widelands/+bug/1235928

[Teppo Mäenpää (kxq)]

Requesting exactly correct "type" of miner is sometimes justified.

What if the mine would first request a miner (level=x), and set a timeout. If the request is still not fulfilled, in the sense that the economy has not allocated a miner for that slot when the timeout expires, then the request would be canceled and the mine would request a (level>=x) worker instead.

If a player is upgrading more than one mine at a time, the old way has its share of problems as well.

Downside is that there would be yet another magic number (=timeout value) around.

[GunChleoc (gunchleoc)]

I think if a mine needs a low-level miner and there is only a high-level miner available, that high-level miner should simply fulfil the request. Workers have a function can_act_as, which can be used for that.

[Teppo Mäenpää (kxq)]

That causes headaches if upgrading more than one mine simultaneously: all experienced miners go to the mine that finishes first, then other mines gets stuck as there are no more unemployed chief/master miners around.

[GunChleoc (gunchleoc)]

This is how it always has been - if we don't, slots for mod-level miners can remain empty although we have a top level miner available. If we just ask for a higher level miner after a delay, if a mid-level miner is available by then, we will pick the high-level one, although we don't need it.

How about we add some form of urgency flag to the request after a certain time span? Request the exact miner first, and if we don't get one after a certain delay, request any miner that will fill the spot.

How long should that timespan be? If we wait too long, this will slow us down too much, but if we don't wait long enough, we will snatch away the miner from the other mine. A constructionsite step is 30 seconds. A Deeper mine has a buildcost of 6, so we get 30*6 = 180 seconds = 3 minutes build time, if all materials are at the site.

[Teppo Mäenpää (kxq)]

I guess that even a one-second time for the "picky request" would do: Problems would arise only if the economy doesn't have picks for new miners.

When the economy doesn't have picks, we would need the 180 seconds plus the time needed for first wares to go to construction site -> something like 300+ seconds to cover most cases.

[Teppo Mäenpää (kxq)]

.. of course, a miner cannot arrive within one second. However, the Request knows whether the slot is still empty or a miner is arriving. If the request is fulfilled in the sense that miner is arriving, it does not need to be canceled.

Handling all the combinations of economy splits etc. beautifully might uglify the code a bit.

[GunChleoc (gunchleoc)]

The attached branch fixes the immediate problem - seems like whether this works or not depends on the order of the working positions in the init.lua. Not good, so we should definitely look into this code for Build 20.

[TiborB (tiborb95)]

I looked at the issue from C++ perspective and it seems that this is a code that is used for matching idle workers and requests:

http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/economy/idleworkersupply.cc#L99

I put there some printf and it seems that it manages to properly identify the "substitutions".... But economy code is a jungle to me :(

[TiborB (tiborb95)]

BTW, there is only handful of such promotable workers:

./barbarians/blacksmith/init.lua: becomes = "barbarians_blacksmith_master",
./barbarians/brewer/init.lua: becomes = "barbarians_brewer_master",
./barbarians/miner_chief/init.lua: becomes = "barbarians_miner_master",
./barbarians/miner/init.lua: becomes = "barbarians_miner_chief",
./empire/miner/init.lua: becomes = "empire_miner_master",

[TiborB (tiborb95)]

I think this bug migh be invalid, I reduce the importance at least

[GunChleoc (gunchleoc)]

Yes, current functionality is as it was in Build 18 - let's keep this bug around though, because there are some ideas for improvement.

[3plus4i (tobi-heinz)]

I'm confused about the current status of this problem ...

I just tested it with built 19 and a new miner was recruited instead of sending an available chief miner or master miner. I double-checked beforehand that I didn't have a rookie miner.

[GunChleoc (gunchleoc)]

The attempt to fix the bug in the attached branch was unsuccessful, so this is still unsolved.

[TiborB (tiborb95)]

@3plus4i
And that new miner was sufficient for the position?
Maybe the logic is:
- look up for lowest sufficient free worker
- create new one if brand new is sufficient
- look up for higher workers

[GunChleoc (gunchleoc)]

Fixed in build20-rc1