[0.4.0] Train stop delay time decrements by one

[MF-]

I am pretty sure you are aware of this one..

Select a stop, set it to 10s
select another stop, select back the first stop
It now reads 9s

[kovarex]

We were both trying to reproduce this without success.

[MF-]

Or, even simpler:

Place down some track, place a train stop, place a locomotive
open the locomotive
add the stop

It reads 29s (instead of expected 30s)
I was too lazy to build turrets around the train test area and time the actual stop delay.

(When I drag the slider one notch to the right, it starts saying "30", but it reverts back to "29" and the old slider position when I close and open the UI)

If that's not happening to you, I guess it could be some linux-specific oddity?

[kovarex]

Now I understood the cause of the problem.
We are compiling the linux ship version with the -ffast-math, but we don't have it in debug version, so it was hard to find out.
With this options, it seems like 600 / 60.0 results in 9 instead of 10, we will fix that.

[MF-]

Now I understood the cause of the problem.
We are compiling the linux ship version with the -ffast-math, but we don't have it in debug version, so it was hard to find out.
With this options, it seems like 600 / 60.0 results in 9 instead of 10, we will fix that.

I though that the float math doesn't guarantee exact results.
How does one fix this? Use a rounding function instead of floor()? Add a small number to the "600" ?

[kovarex]

Now I understood the cause of the problem.
We are compiling the linux ship version with the -ffast-math, but we don't have it in debug version, so it was hard to find out.
With this options, it seems like 600 / 60.0 results in 9 instead of 10, we will fix that.

I though that the float math doesn't guarantee exact results.
How does one fix this? Use a rounding function instead of floor()? Add a small number to the "600" ?

The float does guarantee exact results as long as it follows the IEEE specification.
By exact results, I mean determnistic, same on all computers.
And about precision, due to the Standardized floating point specification, 600 / 60 should be really 10 precisely, I'm quite sure about that.
Our replay (and later multiplayer) will heavily depend on that, so we need to solve it globally, not just for this case, we will probably just just some "safe" subset of the math optimisations for the next release.

[slpwnd]

This was resolved by disabling the -ffast-math.