Wizard, please can you stop talking about this problem with your computer and your install of LFS. It has nothing to do with the test patch and I'm not going to be trying to improve that for you. This thread is for talking about changes in the test patch.

Scawen, about pit stops, could there be added thing to pit stop such as engine repair? But with added option in f12 to enable engine repair on, and depending on damage it would repair it in 20-180seconds. That would really help i think(times to repair choosed randomly it can be diffirent or in made in scale according to damage that engine has).

I don't know if this is related to multiplayer patch currently on going. There was a timerange in MPR when everyone turn into timeout and at the same time all the messages can receive nicely. Start at 7:18. This is the first time I've experienced this. Weird. I raced with U15.

Quote from Pathseeker :

Scawen, about pit stops, could there be added thing to pit stop such as engine repair? But with added option in f12 to enable engine repair on, and depending on damage it would repair it in 20-180seconds. That would really help i think(times to repair choosed randomly it can be diffirent or in made in scale according to damage that engine has).

20 seconds engine swap? I'm in.

On the serious note, I kinda like the fact the engine cannot be repaired at all, it makes you run the engine with care in long races, not destroying your car is a vital skill after all.

Quote from michal 1279 :

20 seconds engine swap? I'm in.

On the serious note, I kinda like the fact the engine cannot be repaired at all, it makes you run the engine with care in long races, not destroying your car is a vital skill after all.

If damage is 0.01%-0.10% 20sec is kinda fair i think, as in long endurances that damage is pain in ass, and if its like 1% damage its pretty much end of your endurance. So having option to fix it, but with long time to do that would be nice.

EDIT: because other damage fixing as suspension and body doesnt takes long either, just around 6-50seconds, so i dont see much problem to have now engine fixing time not wntirely massive, just in future if pit stop time will be reworked on make it like 10-20minutes engine swap having like 5%-10%+ engine damage.

To be frank, damage repair in LFS is already (too?) quick... Suspension damage only takes a couple of seconds to solve whereas the motorsport mechanics would need a couple of minutes at least (Le Mans style or Verstappen's crew in Hungary last season).
It would be nice to know what kind of damage the engine damage shall represent in the first place, i.e. derive from endurance races how much time the repair would need.
I'd rather see a (maybe even imperfect) real life based metric then some postulated time. If that damage is fixed by component change, then it should be a fixed time rather then a sliding scale for example.

Then again, that would need quite some research, I guess.

I feel like iRacing's damage repair is (for the most part) a bit more reasonable. Hard hits do take likle 30 minutes to fix sometimes. Only part I find "off" is that a 30+ minute repair doesn't leave the car driving well in many cases. You'd think if they rebuilt the suspension or something that they'd have aligned it even a bit correctly.

Test Patch U16. I'm expecting this to be the last compatible patch before the incompatible test.

Interface:

Key control (4/5/6/7) of free view FOV improved and reaches 2 deg
Prevented auto-repeat on block message and light switching keys

InSim:

IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
IS_CPP Pos is now relative to "Centre view" not the user setting
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
NOTE: for these fixes the new driver taking over must have U16

Misc:

Added a little more logging about D3D initialisation to deb.log

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

Its really great that we have these small updates starting to be rolled out that actually make the game better. Only thing left for us is to wait for the official release.

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?

Sorry about that. I confirm the changes are not in that version. I made the changes in the separate development branch of that source code file.

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

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?

Could well be, that was only around 40mph/65kph in that replay and the gap gets to be about a car length. I hadn't even thought of area detection...

I updated the german translations.
What is the meaning of 3h_matc_obj ("matching object") ?
Is it a "match" as in result, like returned result of a search-function?

Thanks for doing that.

Yes - It is not allowed to add an object with the same X, Y, Z and Index as another one.

If you try to, it combines two strings to say "Can't add : matching object"

It also uses the same string if a matching circle is found when trying to add a marshall circle.

Thank you all for your help, suggestions and testing!

INCOMPATIBLE version U17 is now available: https://www.lfs.net/forum/thread/95016