I'm not sure if this is an issue with the InSim protocol itself (and therefore the coding of LFS) or with the external InSim library I'm using. I thought I'd report it here just in case. Anyway, here are the problem details.

In the attached replay (split across 5 RAR archives) at the very beginning of the replay (literally as it begins) the player "15 A.Tomczyk" tries to join the session but LFS displays the following messages:

15 A.Tomczyk does not have a car
Could not add car info - unknown id

So, he's not actually in the session. However, a new player packet (NPL) is received for this player with playerID 88 and connectionID 34. No player leaving (PLL) packet is received, so to a listening InSim application it looks as though the player is in the session. Then with 29 minutes 35 seconds left in the session (roughly 30 secs after the replay starts) the player tries to leave the garage again and does successfully join the session. This time a new player packet is received for him with playerID 52 and connectionID 34. So, it now seems that the player is in the session twice.

I am seeing the same behaviour with LFS version Z and Z15.
The InSim library I'm using is JInSim 0.5rc6.

Thanks in advance for any help or advice.

According to InSimSniffer no IS_NPL packet is sent when this message appears. A NPL is sent around 45 seconds later, when the driver does finally join (checking the replay confirms this), but to be honest I don't see the error you describe. Here is the dump of IS_MSO, IS_NPL and IS_PLL packets from the first minute of the replay.


Anyway I hope this helps.

Quote from DarkTimes :

According to InSimSniffer no IS_NPL packet is sent when this message appears. A NPL is sent around 45 seconds later, when the driver does finally join (checking the replay confirms this), but to be honest I don't see the error you describe. Here is the dump of IS_MSO, IS_NPL and IS_PLL packets from the first minute of the replay.

Anyway I hope this helps.

I'm getting different results. Here's my dump of IS_NPL and IS_PLL packets from the first ~ minute:


I don't understand why you haven't got the first NPL (with playerID 88), but it's definitely appearing here.

edit: Ah...the car for the first NPL (with PLID 88) is null. Presumably your library will recognise that and discard the packet whereas the library I'm using (JInSim) doesn't recognise that and forwards the packet to the user anyway. Thanks for the help

OK - I've figured it out I think. Looking at your dump, I noticed all those IS_NPL packets arrived in the same second, which I figure must have been because they were requested by a call to TINY_NPL, probably when the race start packet was recieved.

InSimSniffer does not support this (yet), but I hacked the code and added request for TINY_NPL so that all IS_NPL packets are requested when the IS_RST packet has been received. Here is the dump:


In my TINY_NPL request I set the ReqI to 1, and you can see the problem driver is included with all the other players I requested. What I think is happening is this:

- Driver tries to join (Before replay started?)
- Race start packet is sent
- Your program/lib requests all drivers to be sent
- LFS sends all drivers
- Driver gets "could not join" error
- LFS sends MSO message saying driver has no car

So I think the issue here lies in the ISP_TINY TINY_NPL request. It would seem to me that this is still a bug, as LFS is sending packets about drivers who aren't actually in the race. Anyway, hope this all makes sense.

Yeah, that would make sense. Thanks.

Quote from amp88 :

edit: Ah...the car for the first NPL (with PLID 88) is null. Presumably your library will recognise that and discard the packet whereas the library I'm using (JInSim) doesn't recognise that and forwards the packet to the user anyway. Thanks for the help

Ah, good call. I never noticed that the CName was blank. So I guess just check if the CName has a value and you're set.

I would like to mention though that InSimSniffer does not ignore any packets.