We've come across this a few times, which was noticed as it caused issues with the Simbroadcasts results overlay.


If a player leaves (Shift+S or disconnect) after finishing a race, but before the IS_RES packet is sent, the PLID in IS_RES is still the old, no-longer valid, PLID.

This is presumably a bug, as the documentation in insim.txt says:

Replay download (again, the same OEC replay as the other threads)


Compressed log: (more complete log attached)

I'm not sure that is really a bug.

I think the comment "0 = player left before result was sent" is more about something that could theoretically happen due to how packets are processed internally. It might be something like, if a player sends his result to the server then immediately disconnects before that packet is processed. It's a bit complicated so I can't say for sure if that would actually ever happen.

Although I may really be wrong and the comment might be related to an older version. Maybe in an older version the PLID wasn't stored in the result, internally, and was found by a player search when the IS_RES was sent. These days all the values including the PLID are stored in a result structure and it just sends the lot when you request it, without further checks. That's how the expired PLID can come out in the IS_RES.

But is there a real problem with reporting a result for a PLID that no longer exists? I suppose you could ignore it safely, the way it is now. Is it possible that PLID could be useful if you kept a list of recently departed players?

It seems like by setting it to zero we lose some information. Or do you have the information anyway, so there's no need for that?

I'm not seeing a clear reason why this should be one way or the other. I think I could make it work the way you expected, by checking the list of results if any player leaves the race, and setting any related PLID to zero when that happens.

I suppose there is one possible problem, the way it is now. If a result is added to the table then the player leaves and after some time and several new players have arrived then one new player is assigned the recycled PLID then there could be confusion. I expect this is rare.

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.

OK, the PLID in results should now be zero if the player has left or spectated.
https://www.lfs.net/forum/thread/95016