A small wish or suggestion for improvment:
The information for the allowed pit lane speed and the drive direction is only displayed in a short time window. Please display this information for a few seconds longer. The luxury variant would be if that you could determine this value yourself in the settings. :-)
Faster skin downloads when joining server (and auto updater)
Slightly faster skin downloads when driver joins race in-game
FIX: Skin downloading could get stuck after a large header
Pit speed limit is shown when car speed is below 2/3 of limit
Command /spectv no - prevent selecting TV camera on spectate
Momentary flick to rear view after SHIFT+R is now avoided
Avoided downshift after pressing SHIFT+X to exit free view
In fact any 'key held' function after SHIFT+key is prevented
Some updated translations - thank you translators!
People talked about it on discord a while back, so here's a summary to the best of my recollection: Lazy works on U6 but not afterwards. The big differences for people are the recent FFB improvements and a bug that meant that serving a stop-go penalty in a custom pit stall would stick you to it. If you can avoid getting a stop-go on a custom layout and you don't need the FFB tweaks, you can use U6 to get Lazy.
Scawen is looking to put the recent skin fix into an official version, so hopefully they can be back in sync soon
A small update 'U13' for the dedicated host (DCon) is attached.
It allows /pps 12 in internet multiplayer mode.
I don't think it makes much difference, as it is only an upper limit on "position packets per second" but in some situations it could help. It will *not* cure the problems of latency and can make some problems resulting from latency even worse (namely CPU usage on your local computer during the 'catch up' from when the packet was sent on the remote computer, to the current time).
The previous maximum was 6.
The command /pps X was found not to be working to change pps while already running but it does now work and there is a message on guest computers when the resulting packet is received.
This is a compatible update.
EDIT: removed attachment, it's now the official test patch.
There is more to the calculation of the actual resulting packets per second. The pps setting is only an upper limit. LFS already tries to estimate how soon a new packet is needed, based on how much the controls have moved. For minor steering / throttle / brake adjustments it will not go up to the rate set by pps. I think some of the worst inaccuracy problems come up when inputs do not change much but the car is in some state where slight inaccuracies at the start of the prediction give a quite different outcome at the end of the prediction. In this case the remote instances of a car may end up in quite a different place from the local instance but LFS doesn't send a packet quickly because the controller inputs haven't changed much.
I'm not sure if that's explained very well. There is also a maximum time between position packets of 1.28 seconds. This time is used as a starting value after each position packet is sent, then any changes in the analogue inputs over the coming frames reduce that time to a smaller value. More and more has changed, so send the next packet sooner. Of course any 'digital inputs' (like a gear change) cause the packet to be sent immediately.
That explains what I was seeing on the straights on the test server, the same update frequency I saw before on 4/6pps servers. As the cars turned for a corner, it was noticeably more frequent. I'm sure others will have some feedback and observations, and we plan to test this en masse tomorrow after GT2C on the death rally server, which should give us a good test case for close racing, collisions etc..
That may also explain part of why fast cars (BF1 in particular) can look like it's jumping all over the place in fast corners - due to the agility of the car and massive speed, a very small change in input can result in a huge change in position a short time later.
From our testing earlier, the general feeling was that it was better overall. Especially glancing car to car contact seemed less violent.
We didn't have many people in the server (though we did have quite a large range of latencies) so any CPU limitations wouldn't have reared up.
Will have to see if we can wrangle enough people for testing tomorrow.
I'm not sure what latency threshold it's thought would cause a problem, but for reference, 12 PPS is still at least 2 Round Trip Times for basically anywhere within Europe. It's nearly 5x the RTT from me to my server in Northern Europe.
Presumably, a higher PPS should also improve the perceived latency for many people? At 6pps, a large input made just after a packet was sent would wait for about 150ms before the next packet can be sent. 12pps would reduce that down to about 70ms. Those times are before taking into account Internet latency, which would increase the delay.
For reference, one-way Internet transmission time for a UDP position packet should typically be less (often significantly less) than 180ms between Australia and Europe.
A server with players up to 2/3 around the world away would typically see position transmission times of <100ms. That's a server based in Europe covering players between the whole of North America (and a lot of South America) to Singapore.
If it turns out that high latency is a significant cause of problems for high packet rates, perhaps it would be possible for LFS (or InSim, if given latency data) to dynamically adjust the pps to take into account the latency of players currently connected to the server?
That worst case situation of fast cars jumping about (e.g. BF1 as you mentioned) seems to me the most important thing to focus on at first. If I could do a better estimate of when it's important to send the next packet, that would help a lot. We can't just send full packet rate per second for all cars all the time as it would be a massive increase in bandwidth and CPU usage, so the solutions are really about the estimate and also making sure the remote car is initialised the best way it can be at the start of the prediction.
Do you know any simple and reproducible ways to create the worst looking effects, in these situations where high latency is not the cause of the problem? You mentioned the BF1 at high speed in corners, which I remember seeing.
Of course I also remember seeing cars all over the place due to users with a poor or distant internet connection but we can't really solve that. But if you can think of any simple ways to cause large displacement issues on good connections, that could help me as examples I can consider.
I can start DCon on a remote Linux computer using Wine and it is easy, at least on that server. I realise we are relying on external software so that's not ideal but it seems to work well. What are the problems with that?
BF1 at high speed corners seems to be the most obvious manifestation of it. From memory, it does seem to still happen on good (<40ms reported by LFS) connections.
We've used DCon on wine for years. The only real problem we have is that Linux doesn't close the listen port fully for 60s, which prevents us from quickly restarting the server.
There may be some workarounds for that, but it seems the issue is quite complex involving various sides not fully conforming to the TCP spec or something. I think it rears its head because of conflicting differences between wine/windows and the Linux kernel.
From experiments today I've found a few things that should be adjusted to send more position packets when needed. I think it should send packets more quickly for a small change in steering and this should probably be speed related, because a small steering change has more effect on your car's position at higher speeds. Maybe it should look at the resulting angle of the front wheels rather than the user input, to make it more consistent between cars. I think it may also be possible to reduce a slight jiggle on the steering each time a position packet is received which probably reduces the prediction accuracy.