Stop the rounding to full 10ths for productivity percentages

aren't status messages enough? like: not connected, not manned.

i didn't even know there was a message for not connected; Never seen it, even when it should have appeared.
I had thought it a helpful thing, and easily done.(I suppose) And why not show exact number, if you can get them for free?
But, well, put it to won't fix, if you think it's nonsense.

there is no status message for not connected ;). And I didn't intent to downvote your suggestion, I just wanted to spur some more information about this feature.

The rounding of the producitvity was done in the first place to avoid the jumping of numbers, as they numbers jump anyway we can as well remove it. The remaining question for me is, if status messages would not be of (even) more use.

I'd like to see exact numbers, because I find some of those jumps hard to explain in some cases.
I dont know how the percentages are calculated, but maybe averaging over a longer time would yield good results?

Personally I prefer the numbers to status messages, as I keep checking them all the time in order to maximize overall productivity. I had even thought about a color coding of these percentages (high=green; medium=yellow,; low=red), but that might be overkill.

okay, so to close this bugs, the rounding of the statistics numbers should be given up. I agree that this is worth a shot.

Analyzed and discussed this wish during WiHack 2010 Reloaded.

The current implementation does not allow a finer granularity than 5%. In fact, even those 5% steps are misleadingly precise. The productivity information is gathered using very unprecise guessing methods.

We need more opinions on this. My personal suggestion would be using only 3 to 5 steps instead of 20, and even not showing them as percentages, but with kind of symbols.
I'd also be fine with leaving it that way, and using this information only for a rough glimpse if there might be a serious problem or not.

Setting incomplete, reflecting the need for more input.

The real trouble with this is at the low range.
I dont care so much whether it's 80% or 100%, but
0% is always a cause to check for the reason and
with the "because not economy needs"
many buildungs (kiln, woodhardener etc. go to 0% if
you are not currently in the process of expanding
That is why I'd be happier with more precise numbers.
Of course I was thinking that they were the result of a calulation
not estimation, and only rounded to prevent flickering on the display.
However in the light of the new information it makes no sense.
Perhaps just leave it as is, and really go for a "not connected"
indicator (like status displayed in red, instead of yellow?)?

I thought the case of "did not produce anything because not needed" already takes care of not affecting productivity? Perhaps I am remembering this wrong...

[Expired for widelands because there has been no activity for 60 days.]

Reopening, since people initially agreed something should be done.

Hm, I think Jens' suggestion could be interesting. If the percentages aren't precise, we might as well choose a less precise unit to measure productivity. I'm not sure what we should display though, 3/5 stars/dots/generic wares, or something else. The thing I think would be ideal, would be to have something that's rather small (the current 100% doesn't take up much space, and makes it easy to see which building is beneath) though still showing the relevant information clearly. If done wrong I think placing dots on each of the buildings could easily look cluttered or like noise, so I'm not really sure how it should be done. Perhaps someone could sketch up a couple of suggestions?

An alternative would be to display a "health" bar, like the soldiers have. I'm not sure how hard it would be to tweak it to the buildings, but I reckon it should be possible. However, this might be misleading, as a bar on top of a building is precisely primarily used for health, which doesn't really make sense in Widelands.

Hoping not to annoy anyone...
How hard is it, to code a better calculation for the productivity?
I mean, why adapt the display to unprecise guesswork, instead of leaving the percentage display (wich is good IMHO) and doing a decent calculation to get more reliable numbers?
What we would need could be something like (cumulated production output in the last 10 minutes) compared to (highest possible production output, if running nonstop and all ingrediens are present).
Or am I again too naive?

Actually I do not see a problem here. Of course the code can be enhanced at some placesm but the current way is quite intuitive in my eyes - btw. some comments above are not completely true, some even wrong.

Currently the statistics are based on the last 20 "working tries" where a "success" means +5% and a "fail" means +0%.

If production is skipped because the ware is not needed, no "working try" is written and thus the statistic is unchanged.

If production is skipped because a needed ware is missing a "fail" is written and thus the statistics get lower (or stay at 0% ;) )

The "+" and "-" indicator is based upon the last 10 "working tries", where every "success" is counted as +10% - if the sum is bigger than the complete statistic, a "+" is shown, if smaller, a "-" is shown.

I experienced some strange building statistics as well, but am not sure which buildings showed them, however if someone wants to take a deeper look into it, it would be good to check the production programs of all buildings. Generally the check should look like:
* skip if not needed
* sleep
* check ware

so skip should be before sleep so e.g. the smiths don't sleep only because no hamer is needed - the damn worker should produce shovels, so no reason to go to sleep ;).
Anyways, all check ware calls should be after the sleep call, else the work program will directly be restarted and the ceck ware call will again fail, which will directly pull the statistics of the building down to 0% - mabye that is the case for some of the buildings.

So to conclude: I vote for checking all buildings, but leaving the statistics calculation.

So I finally have an answer to a long standing question!
Thank you; Nasenbaer! It's a good thing, you found some time to appear here :)

You are probably right at the mark with your analysis of
the strange jumps in productivity for some buildings.
I guess there may really be some mixups in the sequence of
checks, sleep- and working cycles for some houses.
I have read it again but here is a part I don't understand:

(in the paragraph explaining the coniditions of the +/- signs)
...if the sum is bigger than the complete statistic...
Could you be so kind and clarify this a bit more?

@#13 of course I can :)

Let's take a look at an example: "1" means "success" and "0" means "fail"

A productionsite has the following "working tries" written to the statistics (always 20 - older ones get removed):

0 1 1 0 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1

the statistics value (85%) is created out of all values. The indicator (whether the productionsite's productivity is increasing or decreasing) is generated out of the last ten values in comparison to all values (last ten = 9 x 10% = 90 % > 85% = 17 x 5 % = all twenty) -> "+"

hope that explains it.

Yep -- thanks again!
I understood:
The "complete statistic" that puzzled me in the caluclation for the + and minus sign, is the "sum" from the last 20 "tries" you collected for the percentage display.

Setting to incomplete for bug sweeping.

The current system (showing the productivity in steps of 5%) is fine to me, and I think the +/- indicator works well, too.
Has the order of the command in the conf files as suggested in #12 already been checked? It is:
- skip if wares not needed
- sleep
- check wares (I guess this includes the whole production process.)
I think the order is logical, and I cannot remember having seen a building drop very quickly, but I wanted to ask if someone has checked the conf files.

[Expired for widelands because there has been no activity for 60 days.]

nobody has checked all conf files AFAIK. And I remember somebody complaining about the productivity of one of the atleantean farms dropping real quick.

I have checked the Atlantean conf files. Most of them are not okay.
Bakery, burner’s house, crystal mine, coalmine, goldmine, gold weaver, horse farm, iron mine, mill, sawmill, smelting works, smokery, tool smithy, weaving-mill and weapon smithy have the following order:
return
consume
sleep
animate
//some buildings have playFX or mine statements
produce

As described in comment #12, these buildings drop from 100% to 0% very fast when their output is needed, but their input wares are not available. (Tested with the bakery which drops from 100% to 0% in about 5 seconds.)

The spider farm has sleep, return, consume, animate, produce. I do not think that that is a problem because it only has one kind of output, but it should be changed to be consistent.

I did also a test with the armor smithy (which has the desired order return, sleep, consume, animate, produce). It took about 42 seconds to drop by 5% (sleep time is 32 seconds; I do not know why it differs).

@comment #19: I do not know what you are referring to. In case it was bug 1332455, please re-read it: It was not about productivity dropping too fast, but about converging to 35%. Since none of the farms has a return or a consume statement, this does not matter here.

Right, I mixed something up. That is a (probably related, but) different bug.

I am going to change the conf files (this makes sense independant of the productivity statistics).
A question to the quarry: Would it make sense to have the order worker=cut_stone, sleep=25000? It would then not be consistent with the other entries (where the inverse order is better) and the productivity would drop very fast. The reason is that once all stones are gone, the productivity will never raise again. 0% would therefore be a kind of prediction for the future. It would be a clear indication to the player and maybe also help the AI (I think it uses the productivity to decide whether a building is dismantled).

I think your reasoning about the quarry is sound. Just make sure that you define all quarries equally.

- I have changed the conf files as described in comment #12 - see the attached branch.
- Buildings that skip production now have blue percantage for their productivity.
- The discussion on how productivity shall be calculated has restarted/continued in bug 1316929.
Can this bug be closed, or are there other issues I overlooked?

Fixed in build19-rc1.