Stopped production sites do not have their reserves filled

[Angelo Locritani]

May be related to bug536570, but I've seen that if you stop a building, than reduce the waresqueue to 0 and then raise it again, the queue will remain empty.

To reproduce, simply build a wood hardener, let it fill, stop production, low the amount you want to store into, wait the wares going out, raise again.

[Nicolai Hähnle (nha)]

This is not strictly speaking a bug, but it's a fair point. Stopped buildings do not get deliveries so that you have fewer idle wares "wasted" inside them. Now that the number of wares can be set explicitly by the player, perhaps this behaviour should be changed to give the player more control.

[Jens Beyer (qcumber-some)]

+1 for filling the stock of stopped buildings.

But, we should think a little more about that in that case.

I can imagine two buttons: Pause and Stop.

Pause:
Does what the current stop button does plus the suggestion: Stops the worker scripts, fills the wares to the limits set by the player.
Unpause:
Does what the current run button does: Runs the worker scripts.

Stop:
Stops the worker scripts and reduces the limits of wares in the building to 0 for every ware. If possible, eject all "superfluous wares" in the building's queues. Cancel wares requests for wares which are on the road.
Run:
Runs the worker scripts, resets the limits of wares in the building to either full or the last values set by the user, whatever is possible.

[Jens Beyer (qcumber-some)]

Sorry, can't edit comments and clicked too early.

The reason why I suggest this is:
There are buildings with long queues and buildings with many queues. It might become a bit... tedious to manually have to set them to reflect the user's need.

[Astuur (wolfsteinmetz)]

Yes, the behaviour Angelo describes was done intentionally to stop waisting wares that might be needed elsewhere.

+1 for changing it back to filling up the stock of the site.

I am not overly fond of the "Stop" and "Pause" destinction. I think, it's hardly ever needed and just another complicated option to explain.

Instead, how about automatically setting the priority of all wares deliveries for a stopped site to "low" and back to "normal" or "whatever-it-was-before", once it is re-started?

[SirVer (sirver)]

I agree: +1 for filling stopped buildings.

I am against the UI suggestions of Jens. I agree that one should think carefully about the "number of clicks" players need to do but one must also balance the complexity of the UI. I feel the UI should only provide one way to do things in 99% of cases. Also, making the desired stock buttons repeating means that you can just click and hold the button to quickly adjust the wares.

[_aD (ad-simplypeachy)]

I can see why "Stop" and "Pause" might be considered a good idea, but I agree with Astuur's comment #4 - it's a very elegant solution in several ways:
No additional UI elements are needed. The cleaner the UI the better.
No explanation needed for the difference between "Stop" and "Pause".
The automatic priority adjustment uses existing game logic to achieve the desired result.

Automatically reducing the priority means the site will not receive wares that are needed elsewhere. Once the required wares are excess they will then be supplied, which is optimal. When a site needs a ware I want it delivered. When I have excess wares I want them delivered where they "can" be useful later.

In my opinion emptying a bakery of flour and water when it is stopped is not efficient. If my economy is so low on flour/water that I need every single ware I will use the ware storage buttons to remove them. I would say this scenario is rare enough to leave it to the user to remove the wares if this happens.

[SirVer (sirver)]

Setting to incomplete for bug sweeping.

[wl-zocker (wl-zocker)]

I think filling up stopped buildings (but with a lower priority) is a good idea. When the shortage of the input ware is overcome or the building's output is needed, it can immediately restart working. As already mentioned, the player can set the max fill indicator to zero if he does not want that.

[SirVer (sirver)]

Fix in r7066.

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.