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

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


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.

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)

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?

Quote from Scawen :

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?

Ahh, makes sense. I think the only place I normally use it is in the layout editor, for rotating objects with the dot/comma keys, and raising/lowering them with pgup/pgdown.

I was also trying to hold down the left arrow key in a dialog to move to the start of a word yesterday, but that's not a thing I do often. (I wanted to load a few layouts from my local directory into the server with the editor, then use /axsave to get it into the server's directory. I was copying the name from the load dialog to avoid typos, but needed to delete the environment prefix). I went back to test the dialogs and they do indeed repeat for keys other than the arrows - sorry, I had assumed it was all the keys.

Thanks for the info.

You probably know, in the layout editor you can use SHIFT+dot/comma to rotate in steps of 22.5 degrees. Also SHIFT+PgUp/PgDn to move in steps of 1m instead of 0.25m. But if the lack of auto-repeat will be annoying then let me know, I could see if I can think of a good way to enable it for specific situations.

For moving whole words in text entry you can use CTRL+arrows.

If it can be enabled for the rotation that would be great, but I can live without it and I dare say my most common use case (making randomly scattered objects as in the picture) is pretty rare. I should probably insim up something to do that automatically anyway.

There's the slider control for quick rotation too, I just don't like to move my mouse away from placement position if I can help it (I have fast mouse setting, so lining up carefully takes a while).

Thanks for the CTRL-arrow tip, I didn't know that one.

Quote from Scawen :

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.

Would that more detailed info prevent this kind of thing from happening? The right front tyre was shown as punctured for other players, when it wasn't yet for the original car. After the race once the car had stopped, it kept switching between punctured and not.
https://youtu.be/yoD-EtDLVd8

Do you have the MPR for that? I'd like to see in the debugger what keeps causing the puncture.

EDIT: I think I can see what's happening. If I'm right this only happens when the car is viewed in U14. The real car's tyre has a thickness near minimum. On the remote instance, compression of the thickness value makes it comes in as exactly minimum thickness. In U14, thickness is changed due to wear and that causes it to go below minimum and the puncture appears.

Quote from Scawen :

Do you have the MPR for that? I'd like to see in the debugger what keeps causing the puncture.

Slightly too big to attach, so I uploaded here.

Puncture appears on the replay at ~1:21:10, Jaroslav Dohnalík's car, though I gather that he didn't actually get the left front puncture until a lot later and didn't get the right front at all (see chat).
By the way the rim is jumping around, you can probably tell when it happens on his end.


Edit:

Quote from Scawen :

EDIT: I think I can see what's happening. If I'm right this only happens when the car is viewed in U14. The real car's tyre has a thickness near minimum. On the remote instance, compression of the thickness value makes it comes in as exactly minimum thickness. In U14, thickness is changed due to wear and that causes it to go below minimum and the puncture appears.

Ah, I was on U14.

Edit 2:
Similar behaviour has happened for a long time with the fuel level - other players can tell when another car is about to run out of fuel because the value gets rounded down and the physics behaves as if there's no power.

Thanks, got it and reproduced locally too.

Another similar bug can be reproduced with temperature. If you get the tyres very close to 200 (around 196 or so) then wheelspin a little (not exceeding 200 locally) the remote cars will get a puncture until the next wear packet arrives.

Yesterday I increased the accuracy of the transmitted fuel load as that became quite obviously inaccurate with the /showfuel option.

Car state (excluding damage) is covered by wear packets and position packets. The wear packet is for slower changing things, including fuel load, tyre temperatures and tread thickness. These changing values are worked out in physics on the remote cars but updated around every 10 seconds by a wear packet to keep them close to the local car. The position packet is of course for rapidly changing values.

In my tests I've included more in the position packet. As mentioned before, the initial tyre deflection which can stop some slight wandering of the car in the split second after the position packet arrives. In the next day or two I'll try including some of the tyre temperature data in the position packet to see if it makes much of a difference. Conceptually the tyre temperatures are somewhere between the slow changing and fast changing values. So maybe they would be better placed in the position packet rather than the wear packet. Although that's not quite such a no-brainer as you might imagine, because they are worked out physically in the remote instance anyway and they would cause quite an increase in the size of position packets. Anyway we'll see what the tests show.

Yesterday I was going through the other thread and seeing what other compatible changes I could get done. So there will be at least one more compatible patch before the incompatible ones.

Quote from Racon :

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

Quote from Scawen :

If so, then in what situations do you want auto-repeat but it doesn't work?

I've also noticed few other situations where it could be useful to have that auto-repeat:

1) When holding (Shift+)TAB to view driver you want. I know I could just click left mouse button on standings to watch that driver, but I'm just used to hold that TAB button until I'm watching that driver I want. Of course, it's not too bad when there are just few drivers, but when there are many drivers racing, I need to press that TAB button several times now because I'm just so used to hold that TAB-button.

2) Probably auto-repeat could be allowed when changing camera views as well (aka when holding V-button).

3) Even though I'm not using wheel, I also noticed that if you want to have less or more force on your wheel, you need to press that ",/."-buttons several times now. I think in this case, auto-repeat could be allowed, so players could get that force amount they want more quickly.

Maybe I'd better reinstate auto-repeat!

By the way, I've been working on pit stops - a compatible change and an incompatible change. I found a bug that I can reproduce in the existing test patch. Is it a well-known bug?

I took FOX on FE1. Using default setup, do a lap and set front tyre pressure to be adjusted (leaving it symmetric). Enter pits, there is "setup changes" as expected and drive away. Now the bug is that "Setup changes requested" remains set although you can't see any changes requested. Next pit stop there are "setup changes" again although you haven't changed anything. I think it's related to the 'assymetric' setup (although the setup is set as symmetric so you can't see that).

About setup changes in pitstops, this thread might be related (I'm not sure): https://www.lfs.net/forum/post/1960373#post1960373