Test Patch U13 is available.

It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.

I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.

Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.


Multiplayer:

Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version

Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version

Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version

https://www.lfs.net/forum/thread/93185

CreateRenderTarget failed (MS4) : ENVIRO~O0
CreateRenderTarget failed (MS4) : ENVIRO~O1

I get these 2 messages whenever I open LFS, I dont know what it means

Did you get those messages with the previous version of LFS, or only with the test patch?

Only with the test patch

CreateRenderTarget failed (MS4) : MIRROR~T

I get this when Im joining a server,only noticed it now

i set up server named "TEST SERVER FOR 0.6U13" running in finland

Quote from THE WIZARD DK :

EDIT: adding one more replay for kagurazakayukari to make comparison.
it seems to relate to latency according to this. and that seems rather impossible to solve.

So here it is. Recorded at 300ms+ latency.



Also notice both advantage and disadvantage brought by high pps rate.

It also explains my theory posted at https://www.lfs.net/forum/post/1962069#post1962069

Thank you for that.

It is interesting to see the comparison between the live online recording (with high ping) and the MPR of that online session.

While watching this, I thought of an interesting point to make about higher packet rate.

That point is: Whatever you see in that video that is different between the live recording and the MPR, *cannot* be fixed by sending more packets.

Or to say that another way: Glitches that *could* be improved by a higher packet rate, are visible in an MPR.


EDIT: It's related to what I keep saying, that the problems of latency (a.k.a. high ping) cannot be solved by higher packer rate. There may be ways to improve predicted positions or the results of collisions, but these solutions are not so simple as increasing the packet rate.


EDIT 2: To be more precise, it's only the glitches in Wizard DK's MPR that can be corrected by sending more position packets. His MPR is a recording of all the packets sent. kagurazakayukari's MPR is almost identical but in a few places misses a few packets that seem to have got lost. The online recording is the same as kagurazakayukari's MPR but with latency added.

Quote from Scawen :

There may be ways to improve predicted positions or the results of collisions, but these solutions are not so simple as increasing the packet rate.

Thank you Scawan, that's what I do want to express~

Quote from THE WIZARD DK :

EDIT:
wow i really disappear completely at some times.
nobody ever showed me this, so how could i know.
but thank you kagurazakayukari for making this aware to me.

You're welcome pal~
Nice to hear my effort can actually help some people.

Quote from THE WIZARD DK :

however im still thinking about if this is infact related to my shifting issue?

I don't think so. I could be wrong though as it's a complex system. But do you get this shifting problem reliably enough to know if it happens in single player or only in multiplayer?

Quote from THE WIZARD DK :

wow i really disappear completely at some times.
nobody ever showed me this, so how could i know.
but thank you kagurazakayukari for making this aware to me.

As far as I know, that is not your problem. I'm guessing you have a good ping to the server, if I remember the server was started in Finland? But if kagurazakayukari is connecting from China, then it is his distance from the server that causes this problem.

My only point is that I expect kagurazakayukari would see this type of lag from anyone else who is connected to the server, not specifically Wizard DK.

The Wizard DK: I've moved your posts about shifting to a new thread in technical assistance because it's not related to the test patch.
https://www.lfs.net/forum/thread/94955

Quote from Scawen :

My only point is that I expect kagurazakayukari would see this type of lag from anyone else who is connected to the server, not specifically Wizard DK.

Unfortunately it doesn't From what I saw last night, other people don't have same issue. Sometimes A long period of over-timed does happen, but when that happen it always let my ping up above 500ms+ (while can still see other cars driving normaly) then after 30sec lost connection, should be my ISP's fault. DK kind of lag...I don't know, perhaps I should upload live recording so you can see what's happened. At the time he disappered in lap 2 it did have some latency change, but when he started lap 3, I had a more serious connection issue(1000ms+) for a short period, but his car was okay. So it probably not my problem.

I updated the server for GTI Thursday to test version Dcon. So we will see tommorow, we got alot of players from all around the world, usually its full server, so we will get alot of feedback hopefully.

will report back.

Thanks, maybe you can suggest they try the U13 test patch if possible?

Most benefits will come from the use of the patch.

DCon only allows the max pps up to 12 but most of the time that doesn't affect anything.

Will urge the community on our discord.

http://borntorace.eu/fragmaster/secret/test.zip

In the zip file there are separate folders.
6U is saved by Maciek, he ran normal lfs.
6U13 was saved by me, i had U13 patch.
Server is saved by server, dcon U13.

If you need, i have a screenshot of players ping.

In BF1 replays, drivers with 13 in their name are using U13 test patch. Others are on official lfs.

I was also there racing during our test tonight, I attached my saved replays, if those are any help. Used U13 client in all of them.

I'm not sure about my findings. First, positives:
- I was trying to check my ping during racing, it was 50-60 ms stable most of the time, with rare lags/peaks. While my ping was stable, I really liked the way cars handle and move around me, so I think on that front, it was better.
- Contacts! Car-to-car contacts were much better and more predictable in my opinion (of course, with good ping for both cars). I heard this opinion on the server from someone else, too.
- While spectating a player with an U13 client, steering wheel movement definitely looks better.

Negatives:
- While it made good-ping racing better, like you said, it's the same, if not worse when someone has 200, 290ms ping. On the GTi replays it was fine, but the lag was really bad on the BF1 race, at the start, from my point of view, it was very distracting (if I remember correctly, Redbot had a 280-290ms constant ping, and after the start, still in the straight, his car was jumping around).
- I heard one report on the server about lower FPS: by his findings, the usual ~70 FPS was halved, he had only ~30-35 FPS in Lap 1, Turn 1, in the GTi races. The CPU he had was a mobile i7, 6-7. gen, so that is not the weakest CPU in the world and shouldn't really drop a sweat. We thought the increased CPU power need caused it (for the double amount of position prediction), but I wasn't really convinced about that, as noone else reported this, and also, I basically have the same caliber of a CPU, and I noticed no change in FPS.

Just realized i didn't actually post anything what i saw. I was spectator for gti races.

On people with u13 patch, it looked like movement was smoother, but it still wasnt smooth, especially steering wheel. It was less jerky, but still not good for broadcasting.
We had one big car to car contact between redbot and rocket on lap 2 of race 1. Rockets car got spun around, but pings involved were 200 and 280, and there was no flying off to the moon, so i think of that as a positive. It was a crash between usa and india (i think) driver...so lag is expected.

My general opinion is that jerkiness is improved, but not solved. I wonder what to do to obtain smooth view when looking at other cars ateering wheel. Its not just about pps, its about how game shows the transition from data of packet to packet. I would like to see that smooth out.

I'm no coder, but we need something that looks at packet data, says ok, diff between first and second packet is 10 degrees left movement of steering wheel, we need to split that movement into 20 frames, with wheel moving 0.5 degree each frame. Because at present we have wheel at 0 degrees, then next frame wheel at 10 degrees left..it basically teleports. Game should try to fill the gap between packets visually.

Just my opinion. I hope this will help scawen.

For what its worth, i saw no real downsides to u13, and will leave the server with that dcon.exe.

Quote from NumberTwo :

I'm no coder, but we need something that looks at packet data, says ok, diff between first and second packet is 10 degrees left movement of steering wheel, we need to split that movement into 20 frames, with wheel moving 0.5 degree each frame. Because at present we have wheel at 0 degrees, then next frame wheel at 10 degrees left..it basically teleports. Game should try to fill the gap between packets visually.

That's what happens now (or did in U12, see below) when watching a replay. It can do that, because it already knows where the position will be for the second packet (it's in the file).

That's not possible in realtime, because the second packet is in the future, so there's nothing to smooth to. In theory, you could delay the position of the steering wheel by 1 packet, but that means it will always be behind and might look weird. Could be something to try I suppose.



On a related note, I've just had a look at a replay to see what it does currently, and I think something's changed with the smoothing of the wheel when a U13 instance watching a replay.
In U12, the wheel slowly moves into the next position just in time (mostly) for the next update, so that the steering movement looks quite natural.
In U13, it's quickly moving to the next position, then waits there for the next update. It's not moving instantly, so smoothing's still on, it just seems to be either using the wrong target time for the next packet or using a constant speed/interval.

Looking at several replays, it appears that the smoothing is still working properly when watching replays in U13 only if the car you're watching was also on U13, but not if they were on older versions.

I'll do more tests and try to record some video later

What about a steering input filter/smoother?

This “instant moving” feature by increasing pps is quite fine. But MPRs saved by U12 looking smoothly is because U12 ignores most of the steering input to achieve “mostly in time”. But for U13, it saving too much input. Even most of the steering for correction count. By having low latency it can be mostly solved by the next packet. But for high latency the car may moving anywhere with any possible steering input.

So a filter/smoother would be useful to let car smoothly even have high latency. The idea is to count every steering input between two or more packets, remove “instant” input (that could cause cars moving crazy) and make an average or guess which condition of last bit of time was correct, then send out. Also can do with each reveiver side maybe? If steering input is significant wrong then just ignore for 1 packet.

If it is any helpful, I'm attaching my mprs for the tests with BF1 that Number is mentioned.

It felt very jittery from my perspective compared to the Mrc BF1 league a attended. But I have no baseline for it as MRc server had 200-220 ping for me and FM server had 270-290. During the tests, I got crashed by lag during slipstream, at start of WE2 race and first lap in AS5. And it felt very weird. Tyre to tyre contacts also caused me to spin out. But, I haven't raced BF1 before on FM servers so it is difficult to compare.

Thank you all for these results and observations.

It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.

The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.

I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.

Quote from Degats :

Looking at several replays, it appears that the smoothing is still working properly when watching replays in U13 only if the car you're watching was also on U13, but not if they were on older versions.

That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.

If you need any more data let us know. We have another big race today but with fox on server that wasn't updated. But its still easy to test after race.

Even without the server updated, remote players should still benefit from you using U13. The server change is really only to allow a higher *maximum* packets per second. The U13 client will send more packets, but that is usually below the old 6 pps cap anyway.

Just been playing around with InSim cameras and it seems like roll isn't being reported in CPP for Shift+U, it's always zero. I can set roll.

Regression since some time after Z19, where it was previously fixed: https://www.lfs.net/forum/post/1285925#post1285925
See also: https://www.lfs.net/forum/post/1897965#post1897965

Yesterday I watched the work of driving drivers online on the FM server. The smaller the ping, the smoother the steering wheel, there are no jerks. The pings were 40-550. Mikke had the lowest ping of 40 (the smoothest operation), mine was 120-130. But it was without a patch.