Topic: Problem with worker requests
kaputtnik Topic Opener |
Posted at: 2020-06-20, 16:51
I just tried to play the 'Poor Hamlet' (Armes Dorf) startingcondition... had to start about 4 times from scratch because i made too many failures Anyway, now i found something which i think is strange (i would call this a bug, at least with this wincondition): It looks like worker requests are not reset. Played Empire... Hammer-problem: Pick-Problem, or stonemasons problem: This looks to me like worker requests are not reset, although there is no need for a worker. The attached savegame shows the 'hammer'-problem:
I would expect, because a builder is already at the warehouse, the hammer would be used for a geologist. This can be solved with Economy worker limits, but i think a better solution would be to check available workers (in a warehouse) before creating them. Top Quote |
Nordfriese |
Posted at: 2020-06-20, 21:12
Edit: When multiple worker types are planned, older plans have precedence over newer plans. Plans are completely independent from the Requests that cause the Economy to trigger their creation. Edited: 2020-06-20, 21:14
Top Quote |
kaputtnik Topic Opener |
Posted at: 2020-06-21, 10:30
Thanks for the reply.
I think i did some wrong wording, from a developers perspective.
This describes what happen internally. Should a player have to know how this works? If a warehouse plan was made in the past, the plan, or some of its content, is maybe outdated in the meantime. Shouldn't there be an additional check to verify that the warehouse plan is up to date yet? I guess such a check would also save some iron in normal games. 'My' problem with the already started game is now: I have not enough iron left to create some tools to build a basic food economy to provide the miner with food and beer. The solution is to start from scratch again, preventing each action which will force a warehouse plan. Top Quote |
Nordfriese |
Posted at: 2020-06-21, 12:44
For me it's hard to imagine playing without understanding the internal workflows triggered by every decision In some cases, old warehouse plans will be cancelled if they are no longer needed. This is optimised out in several cases though for performance reasons; and in "normal" games it doesn't matter if you spend one iron too much on a worker you don't need; this code simply wasn't written with this extreme case in mind. Code: Economy::create_requested_worker
The problem is that the code pathways involved here don't communicate. We have a Request that just asks for a worker. We have an Economy that frequently tries to fullfill requests and creates warehouse plans as needed. And Warehouses fulfil their plans when possible. "up to / out of date" has no definable meaning here. Personally, I believe that fixing https://github.com/widelands/widelands/issues/3250 will involve some non-trivial refactoring of this function. When someone does that, they might try to address this issue as well. Top Quote |
GunChleoc |
Posted at: 2020-06-28, 08:50
The warehouse could check whether the target player immovable still exists before fulfilling a request. This will not fix the unconnected construction site problem, but it will fix the 2 stonemasons problem. For the second problem, we could save the descr() type and check for a match? Busy indexing nil values Top Quote |
kaputtnik Topic Opener |
Posted at: 2020-06-28, 10:48
Then you have to pay much attention to what players say I started again from scratch built one house after another, every time waiting until the builder arrives at the warehouse again. I don't know how, but the toolsmith produces a hammer again, without needing one. Maybe i reset the economy setting too late, i don't know. The problem here is that the code does things which a player can't control. Can't the player get more control of toolproduction if the toolsmithy window gets a third tab, where one can prefer the production of a specific tool? Similar to the prefer wares buttons of construction sites. Top Quote |
Nordfriese |
Posted at: 2020-06-28, 20:36
True And on the other hand, players have to pay much attention to what coders say, because things easy enough to imagine are nearly impossible to code, such as this:
Top Quote |
kaputtnik Topic Opener |
Posted at: 2020-06-29, 08:07
Also true. The relationship between developers and players are a bit complicated, because each can't live without the other ... BTT: If it is such complicated to get a solution, i am in favor to remove the starting condition 'Poor Hamlet'. It is just no fun if one has to know how the internal code works. Top Quote |
JanO |
Posted at: 2020-06-29, 09:23
Would it be reasonable to code a manual mode for (tool-)smiths? Like two additional buttons (next to work/stop) where one can shift between "stop", "automatic", "manual" where stop is obvious, automatic means the current behaviour and manual makes this specific building invisible for requests from warehouses. Then we would need an additional window or tab (building-specific or economy-wide) where those manual requests can be set. This could look like the one for the economy targets to keep it simple on UI-level. Top Quote |
hessenfarmer |
Posted at: 2020-06-29, 09:48
Basically this start mode is a puzzle. And it was requested by some players who liked the fun of solving it. It does no harm to leave it there. Top Quote |