Don't know if other guy working with those MCi packet can confirm.

This bug is very rare , don't happen very often and will not stay very long when happen.

Description of the Problem:
A driver is on the track i receive MCI packet 1,2,3,4

1 == Good
2 == NULL all data are 0 except is CarId
3 == Good
4 == NULL all data are 0 execept CarId


Since a while now i noticed weird data into rare case! i was thinking was something wrong into my software , so last day i made a proxy that filter MCI, from there i really know this is the exact data i receive.

I really don't know yet how to reproduce that bug and it seem to solve by it self after some second , i never see him happen more then about 30 second and happen normally only on 1 car at time! that mean if we are 32 car racing , only one will get this problem. As i say it a very rare problem i encounter , let say 1 time for each 40 racer i see.


I will love to know the status of other people working on Insim software before i do a hackfix to solve the problem inside my insim application.

Thx in advance!

P.S. i noticed into insim.txt that MCI request interval is recommended minimum to 50ms , i work most of the time at 10ms , since 1 week about i got 35ms and seem that probleme happen less ofent ... so maybe it not a bug but the recommendation is very important for that?

I've never seen that issue myself, but I usually use an interval of 100ms.

Are you using a lib? Does it occur in mp, sp and replays? How many racers?

I'll have a look at my lib and see if I can reproduce this with a low interval.

I managed to reproduce it in a replay (38 laps / AS Club rev / XFG / 25 racers) with 1ms interval.

I don't know if the MCI data is stored in the replay or generated in realtime,
I ran the replay twice, and it happens at exactly the same time (few seconds after race finished), and with exactly the same player id's.

I have no idea why it happens, but it happens exactly like you said, 1 car at the time, lasts for several seconds.


EDIT:
funny thing is, it happens with 50ms too.

EDIT:
happens with 500ms too, but it's a replay so i don't know it this is the right way to test.

Server: Win32
Process: dlfss.exe(insim addons) , lfs.exe(dedicated server version)

UDP for MCI and TCP for all other packet.(both process are local)
MCI interval: 10 to 35ms
Racer count: 1 to ~

i have gather all map data i don't say i know all ... but from what i've saw NEVER a car will get coord X == 0 , it not possible for them to reach that place!

From there it the fastest way i can see to hackfix this until we learn more.

i've made a proxy as i say , but heu... i was using the same procedure as dlfss to retrive packet so if something inside that procedure goes wrong i miss it.

and lfsexternal use same technique about: pointer to structure or structure to pointer

i think a replay contain KEY input a driver do + some server data ...

So when you play a replay the client do the exact same thing as the server it convert the data into MCI packet as example after behind thought the Incredible physic code

So i think your test are good!

Maybe not a bug , maybe it really to us to trash this data.

Maybe it mean the position for that car is unknown at that tick so we receive 0.

I don't think so, why would the lap count be 0 then.

Threads with this bug are appearing in a regular intervall since ages :-D. The position system of LFS also isn't very good. Some time ago while I was developing Live for Stats I had to do many work arounds to have a more or less correct calculation.