Hemiptera Bugtracker at bugs.linux-forks.de

The current dtime setting forces dtime to be smaller or equal to 0.2.

This can cause the following problem for stations with timing systems:

1. Forced dtime causes train to depart late;

2. Train arrives late at the next station;

3. Train misses the departure time and has to depart at the next cycle;

4. The following train has to wait outside the station becuase of the

delay;

5. ...

FYI: I have noticed similar problems that are caused by the desyncronization of advtrains dtime. Trains that leave on time arrive the stations at different times.

The dtime clipping check is present since the very beginning. It was

originally introduced to prevent trains from doing weird things (like

moving too far in a single simulation step) if dtime should ever go

unreasonably high. At that time, 0.2s was a reasonable limit since I

never imagined at that time that there would be thousands of trains in a

single world and the limit could become a problem in regular operation.

Raising the limit could, however, cause possibly unwanted side effects,

and needs to be tested.

I understand the problem related to raising the limit. However, is there any proof that it's the best case to use 0.2s as dtime limit?

A bit of calculation gave me the results that I wrote on LinuxWorks Minetest Server Wiki: https://wiki.linux-forks.de/mediawiki/index.php/Talk:Lag

The bug will be fixed along #137, and the current branch that fixes the two bugs (branch h137) is now stable.

%close