miner/master miner mixed up after enhancing to deep Mine

Bug #536149 reported by fschueller on 2009-01-03
84
This bug affects 16 people
Affects Status Importance Assigned to Milestone
widelands
Medium
Nasenbaer
Debian
Fix Released
Unknown

Bug Description

(Maybe related to 2356420)

Yesterday I've tested the latets svn (svn3642) testing the nice new "configure economy" feature. During this, i triggert the following problem:

If one constructs a deep mine from a mine (which is occupied by a master miner) the master miner ist released, and if the deep mine is finished he returns back to the mine (together with a "normal" Miner).

But sometimes the master miner returns alone, using the normal miners slot in the deep mine and waits for an second master miner to appear. (Maybe some race condition, because i am unable to reproduce this)

** Following was outsourced as a bug #714036 **

As a wish: It would be nice, if one could release a (master) mine from a mine (either the second one in a deep one or the one in a normal one) without destroing the mine.

saluk (saluk-users) wrote :

You're right, I think it is related to #2356420. (Perhaps the same issue). But you also propose a good solution - rather then mess with race conditions, at least let the player fix it on his own.

Timowi (timo-wingender) on 2010-03-12
Changed in widelands:
status: New → Confirmed
importance: Undecided → Medium
tags: added: worker
Victor Pelt (victor-pelt) wrote :

https://code.launchpad.net/~victor-pelt/widelands/worker

i added an eject button to production buildings. this will make workers leave the building. (in theory) it should help with the workers mixed up problem because you can now just eject and let them refill again.

needs testing if this really is a sollution. if anyone has a savegame showing the problem it would be apprecated.

Kristin (ha-kripo) wrote :

This is a savegame with a warmill on field 74 17. In the warmill are two master-miners (instead of a master-miner and a normal miner). If your button works also for the warmill you may test it here.

Victor Pelt (victor-pelt) wrote :

i set the target for this bug as build16 since it really requires a rework of the economy code (and at least the new feature of evicting workers from buildings)

Changed in widelands:
milestone: none → build16-rc1
Nasenbaer (nasenbaer) on 2011-02-05
Changed in widelands:
assignee: nobody → Nasenbaer (nasenbaer)
Nasenbaer (nasenbaer) wrote :

Fix for the described bug was committed in rev 5819 - miners are no mixed up, as the productionsite always places the worker on highest possible position.
However it is still possible, that two master miners run to one of two enhanced mines, as no pick/worker was available for the lower positions. therefor, a "evict worker" feature would be quite nice.

I will open a new bug report for that feature.

Changed in widelands:
status: Confirmed → Fix Committed
assignee: Nasenbaer (nasenbaer) → nobody
Nasenbaer (nasenbaer) on 2011-02-06
description: updated
SirVer (sirver) wrote :

Released in build16-rc1

Changed in widelands:
status: Fix Committed → Fix Released
Simon D. (simon-d) wrote :

i just played the third map of the barbarian campagin, using the build16-rc1 windows-version, and this bug still exists.

i waited until i had a chief miner in one coal mine and upgraded this mine. the chief miner left and when the deep mine was ready, he came back and entered the lower slot. the upper slot stayed "vacant".

please look at this again.

SirVer (sirver) wrote :

could you please provide a savegame?

Changed in widelands:
status: Fix Released → Incomplete
Simon D. (simon-d) wrote :

here are the savegames.

i loaded the last save before the mine-upgrade and did it again. i saved bevor the mine-upgrade, during, and afterwards.

Tino (tino79) wrote :

I can confirm this bug.
In the attached savegame is just build a goldmine. After my miner had become a chief miner, i upgraded the gold mine to a deep mine.
The chief miner entered the mine and filled the second slot for the miner. The chief miner slot stays empty.

No other mines built, only a warehouse. Perhaps the chief miner entered because he was nearer in the warehouse than the miners in my hq?

Changed in widelands:
status: Incomplete → Confirmed
Hans Joachim Desserud (hjd) wrote :

Retargetting for build17 as it is still present.

Changed in widelands:
milestone: build16-rc1 → build17-rc1
Astuur (wolfsteinmetz) wrote :

This is for bzr5904:
I upgraded an imperial iironore mine to a deep ironore mine.
There was a masterminer working in the oremine before I started the upgrade.
The economy did not have any spare masterminers, nor any spare miners,
but it did have 4 spare pickaxes at the warehouses.
I did not upgrade any other mines while this was going on, to avoid any confusion.
When the deep iron ore mine was built, my masterminer entered there and took
the lower slot, and I got the "worker missing" message.
The empty slot was marked as "vacant" not "coming""
I then built a coalmine, occupied by a newly created miner.
I destroyed this mine, but the miner did not move into my deep iron ore mine with
the vacant slot.
Only when I created a new masterminer at another mine and destroyed it,
the deep ironore mine was satisfied.
\widelands\tribes\empire\deep_oremine\conf has:

[working positions]
master-miner=1
miner=1

but it seems that for some reason a deep mine expects 2 masterminers.

Nasenbaer (nasenbaer) on 2011-05-08
Changed in widelands:
assignee: nobody → Nasenbaer (nasenbaer)
Nasenbaer (nasenbaer) wrote :

Well,...

Good news 1: I found out, why my patch did not works as it should
Good news 2: I fixed it, which most likely made it work as it should*

Bad news: there is an asterisk (*) behind "Good news 2" meaning "Let's see whether anybody faces the problem again ;)

Changed in widelands:
status: Confirmed → Fix Committed
Astuur (wolfsteinmetz) wrote :

This is for bzr5915
Not sure if you want this here, it's about upgrading a barbarian metalworks to axefactory:
When I did this, my master blacksmith in the metalworks went to the warehouse, but
a newbie blacksmith came back when the axefactory was finished and my master blacksmith stayed unimployed.
No other relevant buildings were erected or upgraded during this.

Astuur (wolfsteinmetz) wrote :

I was surprised at what I noticed (#14), but maybe that is an effect of the solution?
Does WL now hold back all qualified workers until you create a site where their qualification is
realy needed?

SirVer (sirver) on 2011-06-17
Changed in widelands:
status: Fix Committed → Confirmed
status: Confirmed → Fix Committed
Changed in debian:
status: Unknown → Confirmed
Marcelo do Pagode (marfcg) wrote :

quote "I was surprised at what I noticed (#14), but maybe that is an effect of the solution?
Does WL now hold back all qualified workers until you create a site where their qualification is
realy needed?"

This is a very good thing unless, for example, when you have a deeper mine and only master miners (an tools for newbies). In this situation, your mine will never be occupied unless you build a new mine and whait for a newbie to become a chief miner. Remember that you'll not always be able to build a common mine and let a newbie become a chief, since you can have exausted all the metals available for common mines. I think that "enhanced workers" should be allowed to occupy any position bellow his own -- WHEN there isn't any worker available for that specific position (or tools for shuch worker).

To make it clear:
When a common miner position is available, it should be occupied by (in order of preference):
-a common miner;
-if a picaxe is available, create a new miner to occupy the position;
-a chief miner;
-a master miner;

When a chief miner position is made availabel (again, order of preference):
-chief miner;
-master miner;

Combining this system check with the newly implemented possibility to evict workers, the user should be able to administrate his working force without problem. At least any problem that I can forsee right now... :P

Nasenbaer (nasenbaer) wrote :

@ #14 #15 and #16:
no widelands does not hold back master workers. Simple stuff:

worker A is enhanced worker B
worker B is enhanced worker C
worker C is the normal worker

A upgraded building needs B and C, but
economy has only A and wares for C

result is: C will be produced and walk to the Building and as B is not available, C will walk to the Building as well and take the place for B - so e.g. Master miners are *not* hold back, if they (or a lower) worker is needed.

In case of #14 - the enhanced metalworks does not need a master smith, therefor, a normal smith is send to the building - this is indeed a feature and not a bug - this way the master smith will wait until it is needed (who knows perhaps you have another metalworks somewhere else and only a normal blacksmith inside, but want to double upgrade it - which would make it need the master smith...) :)

Hope this clears things up. :)

Tino (tino79) wrote :

I am still having trouble with this one, just played the third barbarian mission:
I had 2 iron mines whith each one chief miner. Then i upgraded both mines.
After the upgrade was finished, both chief miner went to one deep mine, leaving the other one useless with one miner (missing the chief/master miner).

Nasenbaer (nasenbaer) wrote :

@Tino (#18) : See explanation in #17. Seems to me, that your economy was not able to produce a normal miner at the moment the first enhanced mine was completed, therefore both chief miners walk to the one enhnanced one. This behaviour is by design . of course this can be annoying, but the proper fix is the "kick worker out of building" feature that is planned.

SirVer (sirver) wrote :

Released in build17-rc1.

Changed in widelands:
status: Fix Committed → Fix Released
Changed in debian:
status: Confirmed → Fix Released
Changed in debian:
status: Fix Released → Confirmed
Changed in debian:
status: Confirmed → Fix Released
Changed in debian:
status: Fix Released → Confirmed
Changed in debian:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.