Topic: Measuring working time of productionsites
Tibor Topic Opener |
Posted at: 2020-01-12, 19:04
Also I think in never reaches 0% neither. We can just map range 2-98 to 0-100 in user interface and it would be good enough.. Top Quote |
hessenfarmer |
Posted at: 2020-01-12, 19:22
that was what I had in mind if the community is voting for this. Top Quote |
hessenfarmer |
Posted at: 2020-01-15, 06:42
ok testing showed that it reaches 0% and I saw a building having 99% as well, while most buildings stay with 98%. So for me this is good enough. in my branch I have renamed the related functions and variables to better reflect what is going on. Top Quote |
Tibor Topic Opener |
Posted at: 2020-01-15, 07:17
I think people expect to see 100 % sometimes, and I would vote for a tweak here. Also this might be an issue with rounding in C++ when 999 / 10 is rounded to 99 instead more logical 100. Top Quote |
hessenfarmer |
Posted at: 2020-01-15, 07:45
in C a integer division is basically always a floor function, which is causing this. Problem is that i saw 99% as well once, while the majority stayed at 98%. so if we normalize by 100/98 we may get 101% in some rare cases. Top Quote |
Tibor Topic Opener |
Posted at: 2020-01-15, 07:49
Of course "normalize" would involve also cropping to 0-100. Note that we would normalize only the string to show, not actual variable Top Quote |
JanO |
Posted at: 2020-01-15, 07:57
How about finding a theoretical output for each productionsite (easy for the ones which work inside) and take the real outputs' deviation (within the last 10 minutes or whatever) from that for the calcualtioin? All the stuff about how to handle skipped cycles would be obsolete then. If a building's productivity drops because of 'ware not needed', then the number might stay green, even if it is below 66%. Top Quote |
hessenfarmer |
Posted at: 2020-01-15, 09:04
as we use integer arithmetics this would result in the same issues or even worse results if the cycle does not fit into the time base for which you calculate the deviation. Furthermore it is much more complicated then what we have now. Currently we have a short elegant formula that delivers good results for all Productionsites without the need of deeper knowledge of the site. The problem arises simply from the integer arithmetic which delivers a gap at the top dependent on the length of a working cycle from 4% at the shortest working cycle (e.g. atlantean and empire mill) to about 1% for longer cycles (e.g. bakeries). But I believe this could be solved
that would be nice but complicated as the format function has no knowledge of the reason why the productivity drops. Top Quote |
hessenfarmer |
Posted at: 2020-01-15, 09:14
Sounds reasonable. will try this out Top Quote |
WorldSavior |
Posted at: 2020-01-16, 20:19
Does this new method also work fine when the worker walks a lot around or if there are a lot of animations? And what about buildings with various output? Wanted to save the world, then I got widetracked Top Quote |