News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Misleading rounding of goods quantities (Standard + Extended)

Started by ACarlotti, January 31, 2018, 08:22:57 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ACarlotti

At the moment, in the factory info window, the input and output values are rounded to the nearest integer. I think this is misleading, particularly with respect to output - if you have something that's only 3/4 made then it isn't ready for shipping, while the display suggests that it is. As a result, I've spent a lot of time trying to figure out why goods aren't being shipped to their destination in time, when the answer is that they aren't fully built. I've also spent time wondering why the industry list had different numbers to industry details - the industry list (I think) rounds down all of the quantities. I only discovered the rounding just now while looking at the code; it might be good to mention this rounding in the relevant help text(s).

I think that the rounding should be done differently - output should certainly always be rounded down; I have mixed feelings about the rounding of input (and of other values).

The offending code is the stuff using FAB_DISPLAY_UNIT_HALF in simfab.cc

Dwachs

Simutrans calculates with more accuracy internally than displayed. Hence, numbers have to be rounded in one way or the other. Nobody would like to see that a factory has produced 4.22 cars. I do not understand your bug report. What do you see in the factory detail window, what is misleading, what would you like to see.
Parsley, sage, rosemary, and maggikraut.

ACarlotti

The specific issue I experienced was with a Slaughter House supplying meat to a market. The market had no meat, there was no meat in transit, and the Slaughter House claimed to have 1 crate of meat. So I was left wondering why that meat was just sitting in the slaughter house and not being shipped.

My primary suggestion/request is that the display of the output storage should be rounded down, to avoid the above confusion. I also think that consumption should be rounded up, but that's less critical.

The point is that it makes no difference to me if I've got 0 meat or 0.4 meat or 0.6 meat in the output. The difference that does matter is whether I've got 0.9 or 1.1. I want to know how many items are *fully* ready to ship.
For the input, on the other hand, I do care about whether I have 0 or 0.1 meat sitting in storage, hence it would be probably be better to round up in this case to allow for this difference. (There could also be an argument to be made for rounding down here too, and the 0 or 0.1 distinction could in some cases be made by looking at the status of the factory.)

At present, the factory information window rounds everything to the nearest integer, whereas (in Extended, and probably also in Standard; I haven't checked the code) the factory list rounds down. So the two windows are not even consistent with each other.

Edit: I just found myself thinking that I wasn't supplying meat to a market quickly enough (because input reached 0), and then I remembered this. I don't think I have any way of knowing if the supply is getting there on time, unless the displayed values for input storage are rounded up.

Edit: I've just remembered that Standard ships in multiples of 10, so this is probably less of an issue there than in Extended.

DrSuperGood

Standard factories have totally different logic. They work in local factory units which are then converted and rounded for display. This was to fix compounded rounding error due to small production amounts being rounded.

Standard supports sub 10 unit shipping if the output storage is small enough. This is so JIT2 flow control operates properly.

In the future I want to move standard factories back to actual units for production but change the way production works from continious to batches. With batched production it would attempt to only produce whole units (or potentially fractions if pakset specifies) so not only would logic be less taxing (simple counter decrement most ticks) but also rounding would become insignificant (comparitivly big numbers).