Quote from Scawen :

There is only one way I can think of that this could be done, and that would be to watch a live replay, slightly behind time. I was thinking about this when watching a race on Sim Broadcasts. As mentioned, increasing pps may bring some small benefits, but cannot improve things anywhere near as much as some people seem to think. Packet frequency cannot solve latency. I was thinking if the commentator of sim broadcasts could have one instance of LFS saving a MPR, and another instance watching that MPR, a second or two behind time, this could in theory allow two things.

1) the smoothing you see in replays
2) allow rewind to replay something interesting before switching back to real time

I do know this isn't very easy. I'm not sure how far away it is from being possible but I'll have a look into it.

I've had some ideas for a while of how to implement instant (or not so instant) replays in the Sim Broadcasts software, though I haven't had chance to start testing anything as yet.

Running the stream on a slightly delayed replay to smooth out some things is an interesting idea, I'll have to have a play at some point. It may cause some logistics issues with the commentary/director team though.
Is there a maximum time between file writes? I see there seems to be a 4k buffer, but if it can take longer than a second or two between writes, this may be problematic.


On the subject of the temp replays, would it be possible to change LFS' the way LFS reads (or just saves) replays? Currently if the temp file is open in another LFS instance, that replay will be lost when the session ends/restarts on the live LFS instance. The replay for the next sessions seems to be able to record fine though... Creating a copy rather than renaming might be the easiest way to fix.

I also looked into a related weird bug the other day, where if LFS opens another program (using /exec) while a replay is being recorded, LFS then fails to record new replays from that point. I'm not sure what the cause is, but at least some of the time, Windows seems to think that the temp file is being locked by that spawned process and not LFS.
Procmon shows some weird errors, but no attempt by the spawned process to access the file at all (see attached). I can move this to a bug report thread if needed.

Quote from Degats :

OK, so there are two things going on here.

You talk about "muscle memory" on mouse.
The way LFS is at the moment and using your example above:
XRT has 45° steering lock with 720° wheel turn, XRR also (hypothetically) has 45° steering lock but only 540° wheel turn.
If you move your mouse 2", the front wheels will turn the same amount on both cars, as they both have the same lock.
Your muscle memory moving the mouse the same distance will result in the cars moving in the same way (ignoring understeer). Your mouse doesn't have more "wheel turn" on cars that have it, it's just the *visual representation* of the steering wheel on screen will be different.

LFS mouse control is based on where the pointer is relative to the edges of the game window. If you turn on the mouse pointer, you can see it clearly. This means that when your pointer is at the far right of the window, your car will be full lock to the right regardless of whether the limit is 30° or 45°.

If it's the visual representation of the steering wheel being different that's throwing you off, then you may be better off turning off the steering wheel to stop it being a distraction, and rely on your muscle memory instead.


Regarding the different steering lock/wheel turn on the different cars, this is completely realistic.
If you drive two different cars IRL, you will get different amounts of lock and wheel turn. A drift car with a fast rack and 50° lock will move the front wheels very quickly, whereas an old road car with no power steering and 30° lock will take many turns of the steering wheel to go lock to lock. It's just something that drivers have to get used to.

Alright my bad for somehow never noticing the steering wheel's rotation doesn't actually reflect the same mouse position across all cars. I was aware something always felt off when switching between cars, but I never had that realization as I never drove with the cursor visible. I would always assume it was just the difference in steering angle, and after testing the XRR with 45° lock I was lead to my previous assumption.

I still think my original suggestion isn't a bad idea though, having the wheel rotation raised on the XRR and FZR to be in line with the other cars that have 45° steering lock would be nice just for the sake of consistency. As would allowing us to edit the max rotation value ourselves so in theory you could have wheel rotation correspond to the same steering angle across multiple different cars (even though I now realize it doesn't necessarily correspond to input).

I understand that getting used to differences like these when switching between different cars is realistic. But assuming it isn't too difficult to implement I don't see any harm in just having it as an option for those who want it.


P.S actually now that I know this, I feel like this could also be a very good suggestion:

Quote from nikopdr :

That being said though, would it be a good idea to also allow mouse axises to be adjusted under 1.0x sensitivity in the axis menu in controls? It could eliminate the need to edit windows or mouse driver settings.

There's already an option to increase it above 1.0x if you select it in the wheel/joystick controls. But allowing us to have this option in the mouse/keyboard controls as well as allowing us to change it to a value bellow 1.0x would be handy.

Quote from Scawen :

tag

Just as a reference on why we need to focus on having better pps and refresh rates.... well, it was not a pretty opening corner for GT2c yesterday.



Coming from a background of horrendous ping (I'm semi-OK now, at 190ms), the refresh/netcode is trash. At a ping of anything higher than 250, if you drive any other way than totally smooth, the car overreacts to any side to side steering movement and way too slowly for smooth, side to side racing.

At a lower ping like 190, it's manageable, but really, other platforms are able to give more decent netcoding that allows even people from the ends of the earth to race semi-well.

I personally do not think putting knobblies on GTR cars should take precedence over a more major issue like pps which... well, affects "racing" - isn't that what this sim was designed for anyway? Not trashing the drifters, I love drifting too, but we're barking up the wrong tree now. What's the use of brilliant graphics and physics if the boys can't race reliably with each other?


I understand the game USP isn't great graphics but the physics and simplicity, but if we're going to shift to target a market that prefers a more visually stunning and physically-accurate sim platform, why are we not amending the netcode/packet delivery system that allows for clean, mass racing in the first place?

I wouldn't really call 190ms any way near OK. Anything above 100 is pretty horrible in most games. Hell, if I go above 50 something is wrong.

How do other racing games handle these super high pings?

Quote from Bose321 :

How do other racing games handle these super high pings?

As far as i've seen, there's no warping like in LFS, the cars slide on the surface more smoothly and "continuously".

The contact between Dennis and THREE Brazilian drivers last night in turn 1 was mostly just unlucky. For all three of those guys to be in the same place at that time when the contact was initiated would have set off a chain reaction at any pps most likely. In that situation the drivers really need to be doing everything possible to avoid contact on lap 1, especially in such a multi national race.

Quote from Kid222 :

As far as i've seen, there's no warping like in LFS, the cars slide on the surface more smoothly and "continuously".

Most other games don't simulate the physics of other cars in multiplayer, they just smooth the positions of the cars around. It may look consistent (though the body language of other cars doesn't look realistic at all) but I'd amazed if the positions are actually that accurate. There are some games that *look* smooth, but when you compare different players' viewpoints, the visual positions of the cars can be wrong by several metres.

I'd be interested to know what these other games are, because as much as LFS seems to get complaints about netcode these days, it doesn't seem to be as bad as pretty much any other game I've seen when there's a bit of lag involved. LFS is just more obvious than some, because it doesn't try to fake things.


From what I've seen and heard so far, I think LFS would definitely benefit from 12pps (or higher). It seems to be better in nearly every way, even for contact at high ping.
I'm yet to have the opportunity to test it in a very full server, but if there are CPU issues in some cases, I think it should be the choice of the server admin as to what is acceptable.

Quote from MicroSpecV :

Just as a reference on why we need to focus on having better pps and refresh rates.... well, it was not a pretty opening corner for GT2c yesterday.

Thanks for the reference video but the rest of your post is basically antagonistic, irritating and factually incorrect.

Maybe you've missed the updates in the test patch thread.

This is not about 'pps' as I keep saying but it goes over the head of people all the time. The issues involved are far more subtle.

Petrol makes cars go, right? So if my car is broken I can pour petrol over it to fix it, right? No, that is wrong. So dear people, please stop saying that more and more packets per second will solve everything. It won't.

Also, MicroSpec, I'm here working all yesterday and today looking into how to improve the predictions. So telling me my code is 'trash' because you have a terrible ping is not helpful. Also your advice that we shouldn't be prioritising tyre choices is entirely irrelevant, because that is something you've made up, and has nothing to do with what is actually happening.

If anyone would like more information about the current work on prediction and packet frequency, here are a few posts on the test patch thread.
https://www.lfs.net/forum/post/1961950#post1961950

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

Quote from Scawen :

Test Patch U13 is available.

I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased.

So it's not 12pps at all times? Question: Why don't you try even higher pps? No harm can be done anyway, people simply will stop using it if it's bad. Last time I ran a server in AC it was 15pps by default so I am assuming that number was just mid range and not even maximum. And AC is even seen as kind of inferior in terms of online experience compared to iracing and acc. (ACC handles high ping the best)

Quote from Scawen :

Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds

Shouldn't this be the other way round? At lower speeds people use quicker/wackier steering inputs & higher angles. And at higher speeds we all keep it smooth. (If by higher speeds you meant the vehicle speed and not steering wheel rotation)

Quote from nexttime :

So it's not 12pps at all times?

No, see the discussion in the other thread. tl;dr if input changes aren't big enough, a new packet may not be sent to save bandwidth.

Quote from nexttime :

Shouldn't this be the other way round? At lower speeds people use quicker/wackier steering inputs & higher angles. And at higher speeds we all keep it smooth. (If by higher speeds you meant the vehicle speed and not steering wheel rotation)

As discussed probably in the other thread, the BF1 is so fast that delays in sending small steering inputs result in massive errors.
By reducing both the threshold of the amount of input required before sending a packet and making sure more packets are sent when the car is going very fast, this error should be significantly reduced.

Quote from nexttime :

So it's not 12pps at all times?

No, that would cause an enormous increase in server bandwidth and intolerable CPU usage from the extrapolation (prediction) of the position of remote cars. In the case where the remote player has a high ping, the CPU usage can become quite bad because, every time a packet is received, LFS must run the full physics from when the packet was sent, up to the current time. That could be 100ms, so 10 full physics updates and if that was 12 times per second that would be 120 physics updates per second and this would exceed even the normal physics calculations.

I ask people to consider turn one situations when a lot of cars are close together and there is a lot of physics usage and the cars are drawn at high resolution and the frame rate drops. I am fully aware of this problem and I am always trying to avoid it.

Along with this huge cost, there would also be only tiny benefits, from sending more packets when the previous packet already provides a good prediction.

There's no point in using a sledgehammer to crack a nut.

This is why the code tries to send new position packets when the previous packet can no longer be considered to provide a good prediction of the car's location. This happens faster when there have been changes to the input provided by the user.

Quote from nexttime :

Shouldn't this be the other way round? At lower speeds people use quicker/wackier steering inputs & higher angles. And at higher speeds we all keep it smooth. (If by higher speeds you meant the vehicle speed and not steering wheel rotation)

When you are at higher speeds, you move the steering much smaller amounts. Before today's version, that would be interpreted as very little change to the input. But actually at high speeds your car moves across the road much more for a smaller steering input, that is why the steering-related packet frequency is now increased with speed.


EDIT: I don't claim this is the end of the job. I had some changes today that made sense and are moderate but noticeable enough, in my opinion, to be put out there for testing. It's safe and I want to play safe for now. This is a minor update for the existing public version and I need to be on this for as little time as possible.

Quote from Scawen :

Thanks for the reference video but the rest of your post is basically antagonistic, irritating and factually incorrect.

Maybe you've missed the updates in the test patch thread.

This is not about 'pps' as I keep saying but it goes over the head of people all the time. The issues involved are far more subtle.

Petrol makes cars go, right? So if my car is broken I can pour petrol over it to fix it, right? No, that is wrong. So dear people, please stop saying that more and more packets per second will solve everything. It won't.

Also, MicroSpec, I'm here working all yesterday and today looking into how to improve the predictions. So telling me my code is 'trash' because you have a terrible ping is not helpful. Also your advice that we shouldn't be prioritising tyre choices is entirely irrelevant, because that is something you've made up, and has nothing to do with what is actually happening.

Ah sorry, didn't mean for it to come across that way. But happy to the pps update, hopefully that relives some percentage of the issue.

I'm pushy by nature because sometimes people get all media/idealist centric and don't actually listen - not just here but in most games as well. I guess it takes someome to say something direct for action to be taken; action in the right course that is.

Again, didn't mean for it to say your work is trash, not sure how it went past my head that way but keep up the good work so far, everything is good and looking forward to the mega-super-big update when it comes

Quote from Scawen :

Some other changes have been requested, for the use of GTR cars for drifting and off-road.

Drifters have asked for the maximum steering lock to be increased and to allow the full range of tyres, for the XRR and FZR cars. We received a request to allow up to 65 degrees steering angle but it seems a bit much to me. Those two cars have double wishbone suspension so that seems to put a limit on the amount a wheel could turn before part of the wheel hits part of a wishbone with disastrous results. I don't have any real world reference for what maximum lock is achievable by drifters in real life.

About off-road use, I found a note from about 10 years ago suggesting to allow the off road tyres on the smaller GTR cars as they have some resemblance to rallycross cars and that could allow some fun racing. I've seen a recent request to allow the FXO GTR to use the off road tyres for rallycross.

So, combining the above two purposes it seems like it could be a good idea to allow the knobbly, hybrid, road and road super tyres on all the GTR cars, and to increase the allowed maximum lock on the XRR and FZR.

I think tín real life is many drifting steering variables but there is one (real picture from youtube video named: "Extreme steering angle (close to 90 degrees)"). In LFS that 60angle steering with acerman 0 works fine for drifting if use super tyres or lower grip tyres. If use slick tyres need more power and better tyres because they will pop instantly.

And there is example how those cars works: https://www.youtube.com/watch?v=wRxbktpG4qc&ab_channel=SLADIMasters

And i think users "R-To" J.Hautanen and "rantsila" T.Sivonen can tell about real drift car.

PS.
This simulator has the best physical features

Quote from Scawen :

The idea is to reduce glitching

IMO what cause the problem is,

When the receiver received the last packet, via calculating the certain input from wheel/tyre, the car can running nicely. When che receiver received the new packet, the car maybe not changing that much owe to the gentle input from sender, but on the receicer side it could cause problem. And that is where the glitch likely to happen.

Let's think about a corner and car A is currently side by side with car B. Very likely there is a moment the packet from car A shows that the gap with car A to car B is closer, even negetive due to a sudden steering input to correction the movement. So both car A and car B should glitched at this moment(flying into the sky or something) but it is just a calculation and show from car B side. In car A side, car B just starting flying for no reason. Then the next packet reveived, and both client discoverd that car A is not that close with car B, so car B is contiune flying while car A is like nothing happened.

This make people don't dare to side by side racing with people with higher latency. And this might happen in low latency too.I think there should have a function to predict the position of the car before the next packet arrived, and decrease the difference from them. Maybe do some receiver side smoothing will help? I'm not a network engineer anyway...

Sry for my bad English.

It's interesting to read about some details of LFS multiplayer implementation, the interaction of network communication and simulation of remote cars, especially.
Does LFS extrapolate the steering inputs of remote cars (for simulation, not visuals)? Or does it only use constant steering inputs from the last network packet for a given car?

Quote from w126 :

It's interesting to read about some details of LFS multiplayer implementation, the interaction of network communication and simulation of remote cars, especially.
Does LFS extrapolate the steering inputs of remote cars (for simulation, not visuals)? Or does it only use constant steering inputs from the last network packet for a given car?

Looks constant from what I've generally seen - if someone starts lagging, steering angle & throttle inputs of the car usually stay the same until the car disappears (or another packet finally arrives).

By have 300ms ping, I saved an mpr with WIZARD DK.

When cornering it's like watching a car having multiple clone in 1 second lol

So high pps does solved something, but not side by side.

A very interesting side-by-side video by kagurazakayukari showing the difference between a live recording and an MPR, with Wizard DK driving a lap of Blackwood.
https://www.lfs.net/forum/post/1962078#post1962078

The glitches you can see in the MPR recorded on Wizard DK's computer can be improved by sending more packets, but the issues seen in the live recording cannot be improved by sending more packets. They are due to latency (high ping).

Quote from Scawen :

A very interesting side-by-side video by kagurazakayukari showing the difference between a live recording and an MPR, with Wizard DK driving a lap of Blackwood.
https://www.lfs.net/forum/post/1962078#post1962078

The glitches you can see in the MPR recorded on Wizard DK's computer can be improved by sending more packets, but the issues seen in the live recording cannot be improved by sending more packets. They are due to latency (high ping).

So your own car in a mpr is always 6pps even if the server is set to 4 or something? Or 12 in this case. Because in some of my own replays (6pps version) I see a lot of glitches sometimes on my car.

I think having that terribly glitchy video with 300 ping on the left makes the typical glitches on the rest that shouldn't ideally be there look too "innocent". Also the follow camera, I am sure we would see them mini-teleporting in fast turns or even on the straights.

We all know that anything over 150 is an issue and 100 is seen kind of decent. Wish he had 100-150 ping so that we could see the most common scenario.

What is the solution then? As a player I can clearly see there are differences in how different sims handle the issue because when 200 ping is death in one sim, it's just fine in another. Not just in racing but cars look smooth as well. They must be doing something different.

I wonder why LFS does physics calculations and not just send where the car is, to the server? It would have been fine wouldn't it, as long as my client and the server knows where the car is? It's like you can either try to simulate each piston and fuel flow of the engine and millions of different stuff, or you can just simulate the power of it at the wheels. Former will be much more "advanced" but won't be any more accurate than the latter.

Apart from that, could there be a "common sense" system that would be like "Dude, come on. 1200 kg car won't immediately teleport 50cm that way, it's physically impossible"? Or maybe even something graphical to get rid of that. I am just throwing ideas at this point and I don't know which one would actually make sense for a real solution. Because, yes we have lag issues in all sims, but we can pretty easily differentiate between a lagger and not. When a person has a good ping, it looks good on the track. In LFS everybody has that glitch regardless of their ping, either always or somewhere on the track.

Quote from nexttime :

So your own car in a mpr is always 6pps even if the server is set to 4 or something? Or 12 in this case. Because in some of my own replays (6pps version) I see a lot of glitches sometimes on my car.

No, that's not how it works.

Quote from nexttime :

In LFS everybody has that glitch regardless of their ping, either always or somewhere on the track.

Well I released a patch yesterday that should have improved that quite a bit for people with good ping. I haven't had a lot of feedback about the results yet.


EDIT: That's not a complaint - it's not an easy thing to test so may take time. And the person who downloads the test patch isn't the one who will see the results. It's the other people who should see their car glitching less. Best results are when driver and observer both have the new version, because the steering glitch reduction is at both ends (that is a separate feature from the extra packets).

One possible test would be to observe two people with equally good ping, driving on a flat surface, maybe slaloming gently left to right in sync with each other, in the same car. One driver has U13 and the other driver has U12 or earlier. The observer should have the new version. The result of the test should be visible in the MPR.

Actually there doesn't really need to be a live observer, only the two drivers. The 'observer' could be anyone who watches the MPR later.

Quote from nexttime :

So your own car in a mpr is always 6pps even if the server is set to 4 or something? Or 12 in this case. Because in some of my own replays (6pps version) I see a lot of glitches sometimes on my car.

How it works is: Any MPR stores all the network packets that are sent (as long as they are received).

So if there is a good connection, an MPR stored on player A's computer should look identical to the MPR stored on player B's computer. As you can see in kagurazakayukari's video, the MPR from both computers is mostly identical, other than a few points where some packets got lost.

So you can actually test the effect of the packet rate by saving an MPR locally.

But there are two things different in an MPR:

- In an MPR, prediction time is only the time between two packets. Live online prediction time is the time between two packets plus the delay between the packet being sent on the driver's PC and received on the observer's PC.

- In an MPR, inputs can be smoothed between one packet and the next which helps make the prediction a bit better.

Flame reminded me of a small feature request I made in a VR demo video I made a couple of years ago surrounding the VR keyboard (@2:20). I wonder whether you could move it, or give the option to move it around (maybe directional arrows next to it like the mirror adjustment gimble?)

Just jumping on the tweaks bandwagon here. Cheers.

Scawen is it possible to do in future in the game, that you can make your own cars in the game but you have to go "LFS CUSTOM MODE" or something like that what wont allowed to touch world record lap times and so on... And what i mean by making your own cars is only modify those cars what are in the game.

My dream lfs would be like, that i can modify those cars what are in the game way i want. The game allows you to go some kind of "custom car room" and you can adjust hp/nm power curve way you want. You can chose steering angle way you want, you can chose rim and tyre size way you want, you can chose weight way you want, you can chose drivetrain is it fwd, rwd or 4wd. you can chose what the car revlimit is, you can chose how many cylinder it has, 4,5,6,8,10 or 12 cylinder! you can chose weight balance and many other important things. All the options straight in the game that you can modify your dream cars features in those cars what are in the game.

And then when you have made your "dream/favourite" cars you can add them into your own multiplayer server. Example 3 FXO cars. 1 is fwd, 1 is rwd and 1 is 4wd and everybody can chose them and race those only, but only in the "LFS CUSTOM MODE"

That feature in LIVE FOR SPEED will kick ass so hard that you cant even imagine. You can make your favourite racing series easy just by modify your own cars in the game in to your own special racing series.

i dont know how hard that is to do, but that is alot if it possible. We are talking alot about you scawen here in finland and thinking that you should make more "nerd" friends and make live for speed the best simulation game ever! (it is the best, but it can be alot better)