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.
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.
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
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
Added a little more logging about D3D initialisation to deb.log
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?