Quote from ELDemon :

Hi scawen, would there be any leverage in the amount of smoke produced from the tires, would be nice to see a thicker and larger trail of smoke that would look a little more realistic, I know you probably would like a balance for performance reasons, but if you could even look at this I would be grateful. thanks.

edit: The length of the current smoke is fine but seems a bit thin

The smoke gen is changing in the new tyre physics, see https://www.lfs.net/report-dec2009

AFAIK, all InSim app implementations follow the connection list/player list documentation in insim.txt; when a player leaves, the PLID gets deleted from the list as it is no-longer valid and therefore dangerous to keep around unless marked as removed (which would need keeping track of).

Because of your last paragraph, there's no reason to hang on to the PLID once a player leaves (except maybe for a few seconds as there are a few packets with the PLID that can be slightly delayed).


I initially reported this because we came across it at the end of the race, where it is indeed unlikely for a PLID to be reused. It was a problem at the time, because I had expected an invalid PLID value to be zeroed as per the documentation comment.

However, I've since had situations where I need to request a list of RES packets at the end of quali and have seen PLID collisions a few times - it's quite common on a full qualifying session as some people will often Shift+S rather than Shift+P, thus getting a new PLID every time. On a 40 car session, it's ~1/6 chance a PLID will get reused each time someone spectates and rejoins.

If the PLID in a RES packet has the potential to be invalid, I basically have to ignore it and always use the username/nickname in lookups instead.


IMO, a zero PLID is more useful than an invalid PLID (otherwise the PLID field is useless most of the time). Either way, the documentation could do with updating to match actual behaviour as it's currently a gotcha.

Hopefully, this is something simple/quick:

For various reasons, I want to sort a collection of data from RES packets without being able to trust the ResultNum field*.
This is mostly fine, however when I need to tiebreak identical lap times, I thought I could use the TTime value, but it's always zero during quali.

Would it be possible to set TTime to the session time when the lap was completed, or is there a technical reason why it can't be?

If it's too complicated for a quick fix, I'll have a look at changing the way I'm doing this.


*e.g. the cached value is wrong if capturing them live and someone later beats the time



p.s. While testing I remembered this bug https://www.lfs.net/forum/thread/94503 as it's basically guaranteed to happen during quali if manually requesting a batch of RES packets a while into the session.

Quote from Scawen :

InSim:

New bytes output if /showfuel=yes
IS_NPL Fuel : initial fuel load
IS_PIT FuelAdd : fuel added

Tested and working fine

Would it be an idea for the "refuelling allowed" rule to be shown on the server rules when clicking on a server in the server list? (along with pitstop required etc)

Quote from Flame CZE :

I would say it's more convenient to call shifttype.lfs first, which will allow to override some car-specific bindings in the CAR.lfs file if needed.

Agreed

Quote from TFalke55 :

First thing I noticed was just when watching the cars race, it is hard to tell who is on what tyres. It'd be nice to have that information in the F11 menu as well (not sure if it is part of Insim). That'd make it easier to monitor/admin the race.

InSim has all the tyre data and the new car config at least.

What seems to be missing from InSim currently is the fuel level.

Victor: I'm speaking with someone who's having problems starting up an lfs.net U0.6 host. They can select U19 and U is still in the list, but it gives an error message:

Quote from Aleksandr_124rus :

And I noticed some looks like bugs, idk it mention before or not, when you switch the configuration from RX\Drift to Default and back, then the active setups gets lost parameters of Steering lock and tire type, lock is going to 24 and tires to slicks.

That's to be expected IMO, because the Default config is restricted to those settings. I would expect it to clip the values to valid ones. Not doing so would either involve remembering 2 conflicting settings or potentially leaving the default in a bad state.

Quote from Aleksandr_124rus :

And , about steering wheel hand animation, its quite broken now on 1080 degrees lock to lock when you have a large steering lock value.

Already mentioned a few times.

Quote from DarkKostas :

Also despite the fact that FXR/XRR is sequential and we're force to use it instead of H pattern, i'm more annoyed that once you select upshift as gear 4th(same applies to downshift and 3rd), it removes the H-pattern's 3rd button, so i have to constantly change the controls whenever i swap cars.

Pro tip: you can use per-car scripts in lfs/data/script/ to automatically change your control scheme to match the car.

I used to do that so my old G25 would auto-switch between H, sequential and paddle depending on the car's gearbox.

CPP Pos being relative to Centre view is working now, thanks


For some reason, I'm only ever seeing Config == 0 in NPL

Also, I've noticed that the driver model stops turning the steering wheel when the GTR cars hit their normal, non-drift, end stop, but the wheel continues spinning through the hand. Minor thing, but looks a bit weird.

Quote from Racon :

I'm currently playing around with a little insim toy for drifters using MCI data from the host - it draws a trail of chalk lines, each aligned with the car - and it's sometimes falling victim to the optimisations of packet rate. When there's little/no control input change, the time between updates drops to what looks like about 1.5 seconds.

If I'm understanding it correctly, because I'm connecting the insim to DCON (ie, no physics), all the data reported in the MCI packet is a position/heading/speed/time type prediction. Clients can cope with this gap because their predictions come from running the physics with no input change.

I've attached a very quick replay and screenshot of driving in a circle, half the time with no control input change and half with a constant, gentle jiggling of the throttle. (The 'jaggies' are 6 to 8 elements long, at 200ms MCI interval)

I don't know if it's worth having a shorter maximum time between packets than the clients need, for the sake of host MCI data? Or if the DCON prediction could be improved by adding a value for rate of change of heading? Or if it's even worth refining, given that you do have to hold pretty still to trigger it

That might explain another position packet issue we've been having in several InSim applications/minigames - when using MCI data to try to check whether a car is inside an area or not; I have to do some hackery (involving waiting a couple of seconds and testing again) to make sure that the result I'm getting is actually accurate. Without that extra check, the server-side InSim can sometimes think that the car is the wrong side of a (sometimes quite thick, eg pitlane) wall.

Would this also explain why PLA pit in/out packets are often significantly delayed?

I've just had a quick test of the CPP InSim changes.

FOV works fine, but the custom view still seems to be relative to the user's view file, not the "Centre view" position.
Other than the Pos data etc, I'm using

Am I missing something?

Quote from Scawen :

I'm planning to release one more compatible update with a few fixes before the incompatible one.


I've now done this. It will work fine but there is no smoothing on the FOV value. If FOV in the IS_CPP is zero then current FOV is left unchanged.


I've been looking at this but have slight difficulty as the ISS state flags are used in this packet and they are all in use. It's a bit of a crazy design but we're stuck with it for now.

I've thought of two possible approaches to achieve what you want.

1) Not include an option at all - Make the offset relative to the "Centre view" always with "custom" view but relative to the driver's eye position in "in car" view. So that means if the view is overridden from InSim then the user setting offsets are ignored.

2) Make it an option by re-using the ISS_SHIFTU_FOLLOW flag. Renamed to ISS_VIEW_RELATIVE so that it could refer to FOLLOW view (in free view mode) or offsets relative to user position in custom view mode.

I prefer the look of option (1) because it looks simpler and less confusing, both on my side and in the specification. Neither option is guaranteed not to break existing code. But I think option (1) does not break existing code if the user has not set any offsets.

But you did suggest it as an option. Is there a reason why it should be an option, or would it be better to always be relative to the central position?

Thanks for looking into this.


I only suggested it as an option in case it might break other people's code.
Having said that, I don't know if anything else actively uses it; I'm pretty sure TV Director uses another method.

As far as I'm concerned, all my cameras are already based on the "Centre view", so if it were to always be relative to the centre view with no option, that's fine by me.

IMO that would make the most sense anyway - it took me a while to work out why it wasn't consistent on other peoples' machines.


I hadn't actually realised that you could do an offset using VIEW_DRIVER, I've only used VIEW_CUSTOM for this.

Team full name: Sim Broadcasts
Team tag: SBTV
General manager: Peter Butcher | mbutcher
Managers (max 2): Degats, dekojester
Nominated drivers: Degats, k_badam, TFalke55, Kid222, dekojester, Flame CZE, mbutcher, tmehlinger, vRenegade, .Mikee., CSF, EoinH5

Quote from Flotch :

I know in the past there was some strong proselytizing ( ) for using vertical synchronization to have fps matching the screen max frequency, but at my level when doing some tests in various games, I tend to have a slightly less fluid experience than not using it ... it is of course very subjective I guess.

In a lot of games, the processing of controller inputs is tied to the frame rate, so a high FPS will give a lower latency, making the game feel more responsive, even if the same number of frames are rendered on the display.
When inputs (and sometimes physics) are decoupled from the frame rendering, you can still benefit from good latency without having your GPU render loads of frames that will just get thrown out anyway. Some newish GPUs/drivers do some magic to try to improve the latency without having to render so many unneeded frames.

Quote from Scawen :

Free view mode minimum field of view reduced from 10 to 2 degrees

That should make our cameras a lot more versatile, thanks

Small bug:
When using the 4+5 keys to zoom, it hits a minimum of 5.7 and stops zooming.
The slider and InSim packet control work fine and will go right down to the 2 degree limit.

Would LFS even need to know whether it was 1024 or 2048? Couldn't the web server just pick the highest resolution available of the two?

While you were digging around with pitstop code, did you get a chance to look into these bugs?
https://www.lfs.net/forum/thread/94490-InSim%3A-IS-PSF-STime-Inaccurate-On-TOC
https://www.lfs.net/forum/thread/94491-InSim%3A-Missing-IS-PSF-packet

I did find another pitstop/InSim bug around that time, but it was considerably more complicated. I'll try to find my notes later.

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.

Last edited by Degats, Wed, 27 Jan 2021 09:37.

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

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 :

Quote from Redbot :

When you are changing tyre pressures with F12 menu for a pitstop and you change the compounds or change a worn tyre to a new one, it still takes extra time saying setup changes. So, it would be nice if no extra time is spent on pits when getting new tyres fitted.

That sounds kind of like a bug. Not a bug in code but in logic. So it would be good to look at that. I don't think I can go into the planned strategy system at the moment.

Related to this, from a realism point of view; when changing tyre compounds, LFS currently forces damage repair. This isn't particularly realistic for minor damage - like slightly worn shocks - and forces longer pitstops than probably should be necessary.

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

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

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).