I just noticed our servers having internet trouble again. Forum, LFS.net, LFS World and master server were not accessible from my location for a few minutes. A dip in the online graph suggests that's not just me.
For some reason I can't see cargame.nl S2 any more. S1 seemed to be missing for a while but now it's back.
Ive noticed this happening quite often with the forum over the last few months. Every now and then, it's not there - always comes back in a minute or two. I just assumed it was a problem with my ISP... DNS issues or something... I've not been racing for a while, so only noticed with the forum.
Thats a bit unfair, because its possible that car with lag appears behind. I remember we had situation on drag where cars had same time, and car with laggy conection appeared to be like 1.5-2 m behind.
Thanks for elucidating this Scawen. I have nothing pertinent to report concerning my 0.6B4 server except for a couple of these (harmless) logs:
• OOS - CAR
• JOOS - ENG
• JOOS : Resync RES (1)
• JOOS - SET CAR WHL ENG
(This is on a server with low activity but with an InSim running.)
In karts we use transponders, which means we are classified by when the actual transponder crosses the line.
Of course the rules state to have the transponder on the same piece of the kart for everyone, so it means missing/crushed bumpers become irrelevant.
I don't know how the game works, but I assume there is an imaginary location on the car that must pass the s/f? If so, I doubt bodywork would affect the outcome, no?
Without studying the code in detail at this point, I think it is when the mesh centre passes the finish line path node (usually the first path node after the visible finish line). Or, in the case of custom timing, when the mesh centre passes the user checkpoint or finish line.
I admit that's not very realistic or good. The mesh centre is an arbitrary point somewhere near the centre of the car. But at least it is fair, because the start positions are also based on the mesh centre. I do want to do thousandths at some point but it will not be in this set of patches.
Well, I can provoke that by manually dragging the dedi-window (running on a Windows system) around for 30 or more seconds. I guess it happens when the server detects that the timespan between 2 ticks was larger than x seconds. (maybe 30). IIrc ,that was one of the fixes that Scawen made recently.
Edit. No serious problems on TC servers.
uptime 72 hours, 2097 connects, just a few JOOS like it has always been before
This means that the time step reported to the server, between one frame and the next, was longer than 6 seconds.
This may be for one of two reasons.
1) The elapsed time reported to LFS by the operating system suddenly jumped forwards by more than 6 seconds. This is a known bug in Wine - it happens when the system time is adjusted (unlike in Windows).
2) LFS was not given any CPU time for 6 seconds. Maybe the system was busy for some reason. This can be reproduced by clicking and holding the title bar of LFS for more than 6 seconds.
Both of these are quite bad situations. Clocks should increase steadily and programs should be given CPU time. Anyway, LFS now tries to deal with it by bounding the time increase to between 0 and 6 seconds, which stops various problems (timeouts and so on) that could come up as a result of negative or large positive time steps.
It's not possible to truly solve the problem in these cases. LFS cannot know how much time has really passed. There will be a time jump that will be seen on the guests either as a hang during which time their car does not move, or a jump forward in time when their car is a bit further down the road than it was.
I don't know. If the external insim program shuts down then it must have a bug in it. If LFS causes a timeout of the insim program, that is strange because the changes I've made should make it less likely to time out.
I really have no idea and you probably need to talk to the insim programmer or any other users of it, giving them more information.