Quote from Aquilifer :

One suggestion was that you lock the position yourself if you get RES. It's just that I wouldn't trust, especially with UDP, that the RES is the first packet you get after the car crosses the finnish line. You could get a time line like this (I think)...

Right, I wouldnt rely on that either, specially with UDP. But keep in mind that I was talking about locking the position with the ResultNum of the IS_RES packet, thats the guaranteed confirmed position of the car, so there shouldnt be a problem locking position with that value

Sorry Scawen... I've got another request .

Would it be possible for us to have driver handicaps (weight & intake restriction) in the replay headers?

Quote from BurnOut69 :

Right, I wouldnt rely on that either, specially with UDP. But keep in mind that I was talking about locking the position with the ResultNum of the IS_RES packet, thats the guaranteed confirmed position of the car, so there shouldnt be a problem locking position with that value

Yes, I understood it. Sorry, my post was bit unclear about that. Of course you rather trust the end position in RES than MCI.

The point is, however, that RES gives only confirmation what the end position is, not how it has changed during the race. So the problem I described in prev post is still there.

OK, I understand it now: you want to track the position of every car at any given moment, so the standings dancing at the end of the race in the scenario you described would mess up your positions chart.

How about this: Even if you get MCIs before RES, you have the MCI.node in which the car is, so you can check if the current node is after the finish line. In that case you would just ignore that position info.

Quote from BurnOut69 :

OK, I understand it now: you want to track the position of every car at any given moment, so the standings dancing at the end of the race in the scenario you described would mess up your positions chart.

Mmmm... I don't want to do anything with the byte... at least currently. But somebody might want to do.

Quote from BurnOut69 :

How about this: Even if you get MCIs before RES, you have the MCI.node in which the car is, so you can check if the current node is after the finish line. In that case you would just ignore that position info.

Yes well that might help somewhat. Although it feels bit hacky and if I was playing with the byte I would feel safer if it was fixed after the race. Besides you might not know the finish line for certain. Maybe you know it is say 5 lap race and so the 5th lap must be the last one. But what about timed (1h, 2h,... 24h) races?

Quote from joshdifabio :

Would it be possible to have the starting positions of each driver available in the replay headers for race MPRs?

I wholeheartedly support this request!

Quote from joshdifabio :

This request is probably harder to facilitate, and I should really have asked earlier, but here goes... Would it be possible to have the starting positions of each driver available in the replay headers for race MPRs? This way all of the important information can be retrieved from the replay instantly, without the replay having to be run.

Do you mean, just one byte added to each RESULT INFO block in the MPR header, and that byte being the start position of that finisher?

Quote from joshdifabio :

Sorry Scawen... I've got another request .

Would it be possible for us to have driver handicaps (weight & intake restriction) in the replay headers?

Again are you talking about just for the finishers in MPR, and in this case also the hotlap SPR header?

Quote from Scawen :

Do you mean, just one byte added to each RESULT INFO block in the MPR header, and that byte being the start position of that finisher?

Yes, that would be tip-top.

Quote from Scawen :

Again are you talking about just for the finishers in MPR, and in this case also the hotlap SPR header?

Again, yes. I personally don't plan on parsing SPRs any time soon, but I'm sure it would be useful to have the data available there too.

Edit: While I'm not planning on parsing any hotlap replays at the moment, I think it may be a useful addition for people who require hotlap submitions for leagues, and plan on possibly imposing handicaps for those hotlaps. Does that make sense? That way it could all be automated instead of admins having to view the hotlap and check the handicaps manually.

Hello Scawen,

much to my regret you have removed the NumPlayers and FirstPly from the MCI packet some time ago. Now it is hard to detect if I have received a complete set of MCI packets. For instance if there are exactly 16 or 24 players in list, I would not know what is the first and what is the last MCI packet, all packets contain 8 valid CompCar structs.
Is there any chance to get this information back?

kind regards
Sören

OK I think I can do something for that in a compatible way.

I could change the Sp2 byte to Info or Flags.


If anyone thinks of another flag that would be useful, let me know. Maybe there could be CC_FINISHED as well (for a car that has finished, or started after the winner finished - I think that info is readily available).

OK Soeren, that's done now in W45.

http://www.lfsforum.net/showthread.php?t=25446

Just a minor note:
There's no information about the number of valid TCP and UDP connections in the InSim.txt, atm, it's just in this thread.

A really low priority request:
A packet informing about "Player xyz sent his setup" would be nice (LFS to InsimApp). With a second packet (InSimApp to LFS) one could reply with "save setup as 'BL1R Username'" or "discard setup".

This would allow us to write an autoaccept-application.

Kind Regards
Jens (Red Runner)