Upgrading building: number of wares in stock window not updated

Bug #902464 reported by Angelo Locritani on 2011-12-10
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Undecided
Unassigned

Bug Description

After upgrading a building, the number of ware in stock doesn't match the number of wares really present in the game.

How to reproduce:

start a new game and immediatly build a metalworkshop

As soon as the construction is over, stop the production.

wait until carriers fill the workshop with needed wares (iron + wood)

Starting with the headquarter only, you should have 12 iron pieces - 8 in the workshop and 4 in headquarter.

watch the statistics-stock window.

Keeping this window open, upgrade the workshop.

Note how the iron counter on stock goes down by 1. (why?) - 11 iron pieces.

wait until the end of upgrade process than stop production of the axefactory and wait until carriers fill the axefactory.

Looking the stock window you'll see that the total of iron is now 11, but only 4 are in the axefactory and 0 remains in the headquarter.

So where the other 7 (+1 disappeared at the beginning of the upgrade process) are? they are lost, it's ok, but the stock window should be update accordingly

Also, is it normal that if you stop the production of a building its internal "reserve" is not filled?

You can test this pausing the game as soon as the workshop has been built and sometime you will found that less than 8 pieces of iron are delivered.

Related branches

Angelo Locritani (alocritani) wrote :
Hans Joachim Desserud (hjd) wrote :

This sounds like a duplicate of bug 726139. Could you check if this is the same as your issue, or if there is some separate problem when updating buildings?

Angelo Locritani (alocritani) wrote :

It may be the same bug, because if I save and reload the game, the stock window shows the correct value, but if I close/reopen the window the value is still wrong.

Strange that the window is updated when the building start upgrading (-1 ware) but not at the end.

Joachim Breitner (nomeata) wrote :

Not sure if this is a duplicate of ug 726139. There, I assumed it is due to window caching, but the code for the stock menu (src/wui/stock_menu.cc) does cal set_cache(false), so in every call to think() completely recalculates all four tables...

Maybe player.get_economy_by_number()->get_wares is reading some from some not-up-to-date cache... It could be that there is a call to remove_wares missing...

Joachim Breitner (nomeata) wrote :

This is actually supported by the fact that the numbers are fixed by reloading the game; then the economy values are re-calculated from the wares queues. One guess is that some wares queue is just not cleaned after the upgrade.

Joachim Breitner (nomeata) wrote :

I found the cause, introduced by this innocent looking change, can you spot it:
http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/revision/4917.11.18#src/economy/wares_queue.cc

SirVer (sirver) wrote :

Wow. That was my fuckup. I didnt even catch it when i was looking over the diff of my change again - so subtle. Great catch Joachim! Good to see you back in action.

I merged this, but removed the unneeded temporary variable, it now reads:
 if (m_filled && m_owner.get_economy())
  m_owner.get_economy()->remove_wares(m_ware, m_filled);

I hope I didn't miss something subtle here again :)

Changed in widelands:
status: New → Fix Committed
Changed in widelands:
milestone: none → build18-rc1
SirVer (sirver) wrote :

Released in build-18 rc1.

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

Other bug subscribers