Fix #147: rounding issues #150
Conversation
|
@frosch123 -- you made the opposite change to the first commit before merging #75 , so I should probably ask why you think it's wrong. ;-) |
|
Hm, now the |
|
Updated -- I still don't really understand what the OpenTTD code does, but now I'm confident the Python version does the same thing... |
This is an integer division in OpenTTD, and the floating-point one rounds to the wrong result for some inputs.
| return (round(value.value / divisor * 10 * unit.ottd_mul) >> unit.ottd_shift) // 16 | ||
| def ottd_display_speed(value, mul, div, unit): | ||
| # Convert value to km/h-ish. | ||
| kmh_ish = value.value * mul // div |
There was a problem hiding this comment.
While this now matches OTTD's GetDisplaySpeed, it throws away the fractional part of the speed.
You can define a road vehicles that has a max speed of 7 units (=3.5 km-ish/h), and the movement code will use that speed. OTTD will round it for display to 3 km-ish/h though.
So, ideally it should be possible to define vehicles in NML with a speeds of 3, 3.5 and 4 km/h, which have different speed in-game, and the 3 and 4 is also shown in the vehicle lists.
There was a problem hiding this comment.
This function is only used to clamp the internal value calculated elsewhere, by incrementing/decrementing it until the display speed matches the input. Fractional values that display as the correct integer should be unaffected.
No description provided.