I’m actually not sure if it’s a real bug, it rather looks like it’s there on purpose. But I don’t know what the reason for it being this way could be.

Basically, all IS_PLA packets sent from the players, when they enter and leave the pit lane, arrive with a slight delay (about 3 seconds it seems), which makes some things impossible when you need to detect the pit lane entry/exit moment more precisely over InSim.

Relevant to interessts and noticed that too.
In singleplayer at least it gives the message in chat "player entered pitplane" and so thought one could use the ISP_MSO instead. But no such message and no ISP_MSO in replays for example. Maybe for hosts it gives the message?
(Wanted to have statistic how much time player spent in pit lane. Not just the stop, but from entry to leaving)

Surely though, someone who really wants to automate the pitlane speed limiter could use the xyz coordinates included in the IS_MCI packet and a defined box/line at which to activate / deactivate the pit speed limiter? In that case, this delay is defeated anyway, so it would in essence render the delay moot? Yes, doing the MCI xyz is more work but if it nets the same process, is there a point to still do the delay?

It's rather inconvenient when trying to automate detection of entering a closed pit during some of the races I run, and I don't want to risk mis-timing an adjustment of something that should be rooted in nothing but fact - guessing the exact delay is not elegant, and also the drivers need to be confident that the system is accurate and not fudged to benefit the admins.

Also, automating application and removal of the limiter is pointless if the driver isn't reacting - it's not a magical get to pitlane speed instantly, so someone trying to use it on entry still has to slow, and has to have the hammer down on exit to get speed back. All the automation would do is generally prevent forgetting to apply or remove the limiter, which to my mind isn't a significant advantage and happens so infrequently that the issue is almost non-existant.

I obviously could use the aforementioned xyz coordinates to circumvent the delay for my use, but that would be a flood of mostly useless data taking up application time because I'd have to constantly track all cars - a driver would benefit more because they would in theory be able to disable the function that reads the packets until their pitstop time - I'd have to leave it on all the time because I won't know when a car is pitting.

Although, if you did reveal the EXACT delay, then they still can't use it to defeat the IS_PLA delay for the prevented nefarious use, but then I could subtract the timestamp of the PLA fact from the time pits were open / closed to flag the entry for action / further investigation, or Gutholz could use it to get his pitlane times.

I also think the ~3 seconds it's delayed is a £10 solution to a £1 problem, surely anything greater than about half a second would have sufficed? Half of a second even at 80 clicks is still an appreciable distance and would probably be sufficent to incur a penalty?

The delay is 2.5 seconds.

Most of your post is true, except the part about removing the limiter at the end of the pit lane. A driver using an automated limiter wouldn't need to react then, just keep his foot planted, so that would be helpful. Half a second delay would probably be better than a human can do as he needs to allow a safety margin.

I wish I knew where to find the original discussion about this as I probably didn't just make it up on my own. I'm sure the gist of it is that people want that real world skill (timing the pressing of the button) simulated, and for us not to provide a super-easy way to automate the process. I agree you can use coordinates to achieve the same result but it's not so easy.

oho thanks!