Quote from Scawen :

Good point, I've now added a remote flag (bit 2) to the PType member of IS_NPL.

Yes, I kind of talked bit about this in the previous (now locked) thread (or at least tryed to talk).

"Maybe a flag could be put into the MSO packet to tell if it came from the 'owner' of the LFS which is running this insim? Or even better if the connection (NCN) had an "IOwnYou" type flag for similar purpose. Or is there some other easy way to tell which connection owns this insim?
(in server use you could assume host is always the 1st connection, but not so in client tool)"
(by 'host' i mean the insim owner)

I think it should be in NCN. After all you don't necessarily have a car in use. If you know the UCID of the insim owner, you can compare it to UCID of the player (in NPL) and check that it is not AI. Of course it can be in NPL too, but in NCN it would be useful if you don't have a car out.

Right?

Yes that is a good point that the connection should also be marked as local.

EDIT :

I added one flag to the NCN packet so you know if it's a remote connection.
This way you know which connection is your own, similar to the new flag in the NPL packet.

That is in W32 which is released in the test patch forum.

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

I have some troubles with changing the camera view in W32 and the IS_CCH packet.

I tested this in Single Player mode with only one vehicle and no AI driver. I drove only into the pit lane and changed the camera view.

1. I got an ISP_STA packet when changing the camera with the V key (thats clear)
2. The ISP_CCH came 2 or 3 seconds later
3. When changing to or leaving the custom view (SHIFT+U) I got no IS_CCH packet.

So my questions:
1. Is the time delay between ISP_STA and IS_CCH ok?
2. Is it inteded to get no ISP_CCH packet when changring to or leaving the custom view?

Quote from LupusC :

I have some troubles with changing the camera view in W32 and the IS_CCH packet.

I tested this in Single Player mode with only one vehicle and no AI driver. I drove only into the pit lane and changed the camera view.

1. I got an ISP_STA packet when changing the camera with the V key (thats clear)
2. The ISP_CCH came 2 or 3 seconds later
3. When changing to or leaving the custom view (SHIFT+U) I got no IS_CCH packet.

So my questions:
1. Is the time delay between ISP_STA and IS_CCH ok?
2. Is it inteded to get no ISP_CCH packet when changring to or leaving the custom view?

Yes, that's expected.

The CCH packet is designed for the host to know which camera view you are using to drive. Using this info, a server can force cockpit view, or disallow follow view, for example. There is a slight delay before sending the CCH packet because I don't want to just send loads of CCH packets when someone is pressing V repeatedly to get to the right view. There is no CCH packet when entering or leaving shift U mode. That is a completely different mode, you are actually entering the autocross editor, and the in-game selected view has not changed.

Maybe the STA packet should be anti spammed a bit as well.

Thanks for the info

Quote from Scawen :

Maybe the STA packet should be anti spammed a bit as well.

Just notifying you of some more InSim and other relevant updates in W33.

Can now save MPR from dedicated host (auto or manual - using /save_mpr)
FIX : /end command in single player did not exit correctly
InSim : ISS_VISIBLE no longer changes due to text entry dialog box
InSim : IS_PEN packets now sent on autox false start or wrong route
InSim : Total time penalty is now included in IS_RES (compatible)

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

I noticed that ViewPLID in STA packet shows some (random?) other player's ID when you go to pits (shift + P). Shouldn't it be in this case zero = none?

Also, how do I detect if LFS is in autox mode?

Some more

In the tiny enum which lists all tiny types
ISP_RST, // 17 - info : new connection
should be
ISP_RST, // 17 - info : race start

#########################

What does LEAVR_NUM, PENALTY_NUM, PENR_NUM stand for?

#########################

I'm a bit confused atm because of the IS_CPR Packet. You get a new playername and plate for a CONNECTION - but playername and plate are specified for players? I didn't test this so it might just be a documentation glitch

ISP_RST comment is wrong yes, but it's not in TINY enum.

xxx_NUM - those just show how many elements are in this enum.

As for CPR, find player with right UCID, and check that it's not AI - in this case find next.

OK, I've fixed that documentation error.

The rest is as hackerx said - It mirrors how it is done in LFS, actually AI can't change name, but a connection can change name (and plate). After changing this in the connection, LFS searches for a real player with that connection and updates that player, if it exists.

You don't need to store number plate in the connection, because if that player isn't in the race, you are sent the plate again next time he joins. In that case just forget about the plate.

So... to simplify - when you get an IS_CPR

- Search for the connection and change the name
- Search for a player with that UCID
- If you don't find the player : finished
- If you do find the player : update name and plate

Hi Scawen,
Would it be possible to add the session* start time, in UTC, to the MPR file headers? This would be really useful for something which I am working on with Misan.

*By session I mean either practice, qualifying or race.

Edit: In unix form preferably.

One suggestion: would it be possible to include the race position of the car in the NLP/MCI packets?

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

Quote from joshdifabio :

Hi Scawen,
Would it be possible to add the session* start time, in UTC, to the MPR file headers? This would be really useful for something which I am working on with Misan.

*By session I mean either practice, qualifying or race.

Edit: In unix form preferably.

OK, I have added at offset 36, the number of seconds since 00:00 on 1st January 1970

1 int 36 start time (UTC) : seconds since 00:00 1/1/1970

Quote from BurnOut69 :

One suggestion: would it be possible to include the race position of the car in the NLP/MCI packets?

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

OK, There were spare bytes in the CompCar structures so I've put the race position in there. That will be in W37.

Quote from Scawen :

OK, I have added at offset 36, the number of seconds since 00:00 on 1st January 1970

1 int 36 start time (UTC) : seconds since 00:00 1/1/1970

Great, thanks Scawen.

too bad, that there are no spare bytes in the nodelap structs :/

Quote from Scawen :

OK, There were spare bytes in the CompCar structures so I've put the race position in there. That will be in W37.

Thats awesome Scawen, thanks a lot.

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.

W37 tested, positions byte works like a charm

For future patches (Y?), however, it might be a good idea to add this byte as well to the NodeLap struct as someone already pointed out.

I need higher button resolution ^^

I'm adding a button next to each entry in the driver list on the bottom but with ~25 drivers the buttons are about 3,5 units in height

Screenshot is with 32 driver and it just fits with height 3.
With 20 drivers 4 is perfect.

Edit:
nvm. just drawing full driver list

But the position in the mci is not very accurate if you join mid-race or some people are already finished.

Quote from BurnOut69 :

W37 tested, positions byte works like a charm

I tested it too (W39). However i found one interesting 'feature' in it. Not sure if this is intentional...

The positions change even when the race is over. I tryed with few AIs and after the race I moved my car ahead and behind the AI cars and my and AI positions changed respectively.

I don't use this byte for anything (useful) yet, but maybe it could be frozen to the end standings after the race is over (and the result is confirmed)? This might get important when some of the cars have finished and some are still racing. So you would need to do tracking which cars have finished which are not, because the byte is nonsense after the finnish line.

Also in the beginning (at the start grid) the positions are 0 for some time.

I don't know if these are big things. At least the 0 at the start can be handled easily with a test.

Quote from Aquilifer :

I tested it too (W39). However i found one interesting 'feature' in it. Not sure if this is intentional...

The positions change even when the race is over. I tryed with few AIs and after the race I moved my car ahead and behind the AI cars and my and AI positions changed respectively.

That is confirmed, MCI packets keep arriving even after all cars have finished, which mess up positions and IMO doesnt make sense since from the point the race is over, tracking should be over too. It can be dealt with by 'locking' the position of each car after their corresponding IS_RES arrives, but a better solution would be that LFS stopped sending MCIs after all cars have finished.

Well, to keep getting MCIs every X milliseconds only to be discarded seem like a waste of bandwidth and CPU for me. Yes, its no big deal to solve the problem, but even better than solving a problem is not having it

Quote from BurnOut69 :

Well, to keep getting MCIs every X milliseconds only to be discarded seem like a waste of bandwidth and CPU for me. Yes, its no big deal to solve the problem, but even better than solving a problem is not having it

I don't see any problem here. MCI are also useful when players are not in race, you know... and I believe your CPU and network card will survive those additional loopback packets .

I just wanted to bring your attention to one small change I am proposing, to the IS_NLP packet.

http://www.lfsforum.net/showthread.php?p=443266#post443266

It wouldn't be good if it stops sending MCI after the race is over (I use it for number of other things too).

I'm not saying it's a very big thing if the position keep changing after the race. You can control it little bit yourself in Insim app. Just made an observation publicly known.

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)...

...
1) cars 1 and 2 cross the finnish line
2) car 2 overtakes car 1 (after the finnish line)
3) you get MCI which have the new positions
4) you get FIN and RES for cars 1 and 2
...

Now if you are doing something immediately after the position changes (like draw a chart of positions or what ever), the point 3 would generate erronous indication that car 2 overtook car 1 during the race.