The online racing simulator
Test Patch U16: Updates and fixes
(408 posts, closed, started , go to first unread)
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.
Attached files
u13_mandulaa_1strace.mpr - 16.4 MB - 19 views
u13_mandulaa_2ndrace.mpr - 14.7 MB - 15 views
u13_mandulaa_bf1race.mpr - 1.6 MB - 19 views
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.
-
(kagurazakayukari) DELETED by kagurazakayukari : not useful
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.

Server Player Client Smoothing
U13 U13 U13 Good
U13 U12 U13 Too fast
U13 U12 U12 Good
U13 U13 U12 Good
U U? U12 Good
U U? U13 Too fast

Player is the version the car you're watching was running
Client is the version watching the replay.

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.
Attached files
BF1 test 2 AS5.mpr - 2.3 MB - 18 views
BF1 test 1 WE2R.mpr - 1.8 MB - 15 views
BF1 test 3 AS5.mpr - 1.8 MB - 16 views
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. Big grin

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.
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.
i was using u13 fm gti thursday race yesterday and it way more better and could be more better to! the higher packer rate is still too slow! assetto corsa minimium is 15 and this is 12 packets per second... alot more fun to race today lfs because the cars dont bounce/lag so huge! but still.. i like to see the same level that iracing and assetto corsa has.

when i look online gaming like assetto corsa or iracing i hate to see that the cars dont move in the surface realistic.. they are some kind of shadows that dont live on the track. When you look live for speed good connection 12 packets second live racing you can see how wonderfully the cars dancing on the road.. they move like they move in real life! just make it good as possible for those who had good internet connetions and servers and we can see fantastic looking racing! 12 packets ir better than 6 but 12 is not enough for those who has good connetcion for servers and playing the game.
Just checked my old assetto server setting.
It's called Packet HZ and mine was set to 35.
But in Assetto u have max 24 cars in server.
U14 is now available.

I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.

Changes from 0.6U13 to 0.6U14:

Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)

VR:

Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard

Misc:

Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet

https://www.lfs.net/forum/thread/93185
If anyone got U14 before 15:40 UTC please get it again as there was an error.
not yet the hybrid/knobbly for GTR cars ?
I will test u14 later this day. Interested in those CPU usage things Smile
No tyre and lock changes for the GTR cars yet, because that would make the version incompatible with the current one. As soon as I release the incompatible patch, then half the community will be on the official version and half will be on the incompatible new version, so the online experience becomes thinly spread. That's why it makes sense to first release any changes that do not make the version incompatible. Then they can be tested while I continue with the other incompatible changes.

For example, some of the changes I have been working on, involve additional data in the pospacket. I don't want to release one incompatible version then another one that is incompatible with that one, so we have all these U versions that can't connect online.

I'm trying to make the transmitted car state a better representation of the remote car, so that at least when inputs haven't changed much, the car should continue near the correct path, until the next packet arrives. A good example is BF1 at oval. The predicted remote car car be around half a car's width from the real car even when the controller inputs remain constant. I'm trying to reduce that error by looking at things, mainly in the tyre physics.

I've tested improving the initial start state of prediction including tyre deflection in the position packet. This improved something but not enough. I can also notice difference in the MPR when rewinding to different points. Some of this difference seems to be inaccuracy in the tyre temperatures and I've found that the currently transmitted tyre temperatures are not accurate enough and I plan to try sending a more accurate version in the position packets and see if that solves the predicted car's cornering inaccuracy.
Quote from Scawen :Command /showfuel (no/yes) allows remote car fuel load to be seen

That is an interesting command. I'd like to suggest adding an "admin" option there. I could think of situations where it may be of interest for the race administration to know the fuel load while racers might want to keep their strategies secret.
Quote from Scawen :As soon as I release the incompatible patch, then half the community will be on the official version and half will be on the incompatible new version, so the online experience becomes thinly spread. That's why it makes sense to first release any changes that do not make the version incompatible. Then they can be tested while I continue with the other incompatible changes.

Good to hear, I remember there was a significant division back in the day (Z30?), which caused problems.


I've just tested the CPP roll fix and that works nicely Smile


I've briefly had a look at the pred display using the GT2C replay (server was at 12pps and clients were encouraged to use U13).
At race start turn 1-3, I saw peaks of about 2.0 for /mprlag 50 and 6.0 for 200. A decent relative increase as you suggested, but not that huge overall. 300 went up to ~11 or so.
Quote from Scawen :U14 is now available.

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Save replay while temp_mpr is being viewed - copy instead of rename

I think I found a small bug in messages. I tested this on both 0.6U and 0.6U14 hosts. It's possible to reproduce this bug, if you have one LFS instance in multiplayer race and then open another LFS instance to watch that temp_mpr.

Now this doesn't make sense, but if in that LFS instance, where you are in server, you save that replay as "temp_mpr", it says correctly that it could not rename temp_mpr - copied instead. However, immediately after that, it says "Saved MP replay - temp_mpr", even though that replay's name is clearly not temp_mpr.

In this case, should it say "Saved MP replay - [that replay's eventual name]" instead?

I attached one screenshot about this.
Attached images
LFS_06U14_MessageBug.jpg
Thanks for the report but I'm a bit confused. Are you actually trying to give the replay the name "temp_mpr" ? You should never actually use temp_mpr as the replay name, because LFS tries to delete temp_mpr if it exists, when LFS exits.

That's because temp_mpr (or now, temp_mpr_1 etc.) is the automatic name LFS uses while the replay is being recorded. The user action "save" is really closing that file and renaming it to something else.
Quote from Scawen :Thanks for the report but I'm a bit confused. Are you actually trying to give the replay the name "temp_mpr" ? You should never actually use temp_mpr as the replay name, because LFS tries to delete temp_mpr if it exists, when LFS exits.

That's because temp_mpr (or now, temp_mpr_1 etc.) is the automatic name LFS uses while the replay is being recorded. The user action "save" is really closing that file and renaming it to something else.

Yes I was actually trying to do that and I know I should never use that as a replay name as I already said that it doesn't make sense.

Maybe it's not actually a message bug. Replay is actually named as "temp_mpr" and it works as long as you don't close LFS or start another session. I just thought it looked strange that in that attachment it first said "Could not rename temp_mpr - copied instead" and then said "Saved MP replay - temp_mpr". Sorry for that inconvenience.

However, I noticed something else related to that and it could be a bug: it's actually possible to save replay named temp_mpr in a rather strange way in 0.6U14.

So what I did was this: I started new LFS 0.6U14 host and started a race (I also tried this on 0.6U host, same results happened there).

I tried to save mpr-replay called "temp_mpr" in these four situations.

1) That LFS instance where I hosted that server was only LFS instance opened
2) I opened another LFS instance from same folder (so I could watch temp_mpr) but didn't watch any replays
3) I watched other replays in another LFS instance from same folder
4) I watched temp_mpr (aka now Live Replay) in another LFS instance from same folder

In first three cases, it correctly said that it could not rename or copy temp_mpr (similarly how it says you could not rename SPR in Single Player, if you try to save it as "temp_spr"). I've attached a screenshot about that message.

However, in fourth case, it actually saves that replay as "temp_mpr" in a same way I showed it in that previous attachment.

I tested this on 0.6U.exe as well, there, you can save it as temp_mpr (it actually says that), but it will be immediately removed from replays. The only way it won't be removed immediately if you're watching that specific replay in another LFS instance at the same time when you're saving it as "temp_mpr"

So, I just found it strange and it could be potential bug that 0.6U14 actually disallows to save replay as "temp_mpr" but if you're watching that specific (or now Live) replay on another LFS.exe from same folder, it actually allows and saves that replay in that name.

Like I said, it doesn't make sense to do that, so maybe it should be better to prohibit saving replays as "temp_mpr" or at very least, rename them automatically (probably in a same way how auto-save function names replays)
Attached images
NormalErrorMessage.jpg
Thanks for the tests. Yes, maybe it should disallow entering any name starting with temp_mpr - this could help to avoid confusion.
Question:

Quote from Scawen :
Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
https://www.lfs.net/forum/thread/93185

Is it done on purpose that if I allow this, that remote car fuel load is only shown on clocks/meters? That fuel load is not shown on F12-menu. This came to mind when I saw that suggestion about allowing only Admins to see fuel load. At the moment, even they can't see that exact amount of fuel load if that fuel load can be seen via that command.

Also: should we translators get ready to translate those new U14 features soon? I already saw some lines in English (like those displayed in CPU usage display) which we can't translate yet.
I've tested the live MPR with flushing times and that works as described.

One trivial thing to note is that the replay-viewing instance is reporting 'MPR_BLANK' with each flush when all the cars have left the track and you have clicked the >| button.

More substantially, I've also found that the key-repeat effect for held-down keys is no longer working.
Quote from tankslacno :...fuel load is not shown on F12-menu. This came to mind when I saw that suggestion about allowing only Admins to see fuel load.

Good point. I've now added a fuel line to the remote car F12 menu when /showfuel is enabled

Quote from tankslacno :Also: should we translators get ready to translate those new U14 features soon? I already saw some lines in English (like those displayed in CPU usage display) which we can't translate yet.

At the moment I don't think it is worth adding these new short lines to such an obscure screen. It takes quite a bit of effort to add new translation lines. It's possible that more CPU usage elements could be added to that cut-down live profiler.

Quote from Racon :One trivial thing to note is that the replay-viewing instance is reporting 'MPR_BLANK' with each flush when all the cars have left the track and you have clicked the >| button.

Thanks, I've stopped that message appearing now.

Quote from Racon :More substantially, I've also found that the key-repeat effect for held-down keys is no longer working.

That was changed at some point in the development version, I think to protect against mistaken key spamming in editors. For example a 'new object' key could create multiple objects in the same location. I see that (at least on my computer) auto-repeat still works in the text entry dialog which is important. Is that the same on your computer? If so, then in what situations do you want auto-repeat but it doesn't work?
This thread is closed

Test Patch U16: Updates and fixes
(408 posts, closed, started )
FGED GREDG RDFGDR GSFDG