This is an incompatible version intended for programmers.

It needs testing and I am not advertising this for normal users.
I expect to add more incompatible features as discussed.
The download contains LFS.exe / a DCon.exe / InSim.txt


Changes from 0.6K21 to 0.6K22 :

Layout editor :

Temporary start lights (in layout editor) middle light is now amber

Interface :

Message "Connection has no car selected" info adding remote driver

InSim :

New packet IS_SLC reports a connection's currently selected car
Packet TINY_SLC to request an IS_SLC for all connections

Fixes :

Racing car spawned outside pit lane had speed limiter enabled


Changes from 0.6K20 to 0.6K21 :

InSim :

Changed TINY_SEL to more useful TTC_SEL to get a connection's selection
Similarly IS_AXM with PMO_SELECTION can set a connection's selection
Overridden start lights states are now sent to joining players


Changes from 0.6K19 to 0.6K20 :

Layout editor :

You can now set an identifier for a start lights object

InSim :

IS_SSH documentation updated as it is no longer only for bmp files
New packet IS_OCO can be used to override some or all start lights


Changes from 0.6K17 to 0.6K19 :

Layout editor :

New button "place on ground" to restore ground check to objects
You can now adjust width / diameter of multiple marshall objects

InSim :

A car moved by an IS_JRR packet now has the handbrake applied
Added TINY_SEL to request an IS_AXM with layout editor selection
New value PMO_REQUESTED renamed to PMO_TINY_AXM for consistency
New IS_AXM option PMO_SELECTION to set the current editor selection


Changes from 0.6K12 to 0.6K17 :

Layout editor :

Multiple object selection is now available in marshall mode

InSim :

Added TINY_AXM to request IS_AXM packets for the entire layout
InSim checkpoints and circles can be placed in the autocross editor
New packet IS_UCO sends info about InSim checkpoints and circles
Zbyte added to IS_OBH so the layout object can be identified

Misc :

Maximum number of autocross circles increased from 150 to 180


Changes from 0.6K11 to 0.6K12 :

InSim :

INSIM_VERSION increased to 7 to support new incompatible packets
Backward compatibility system - send INSIM_VERSION in the IS_ISI
Added TINY_ALC and SMALL_ALC to get and set allowed cars

Misc :

No longer stored in message history : /press /ctrl /shift /alt

Fixes :

FF was not initialised when "Input when window is inactive" was set


Changes from 0.6K10 to 0.6K11 :

InSim :

IS_MSO / IS_III / IS_ACR message out packets now have variable size
IS_BFN can now be used to delete a range of buttons with one packet
In game spectate then SHIFT+P and type /join - message is now shown

Start grid controls :

Start grid clear button is now available in multiplayer for admins
Add to grid buttons for admins beside names in list of connections
New arrows to move grid positions - removed "swap position" button

Fixes :

Player with car in game leaving pits no longer sends a join request
In 0.6K10 the IS_MTC Msg To Connection with UCID 255 did not work


Changes from 0.6K9 to 0.6K10 :

InSim :

New join request system if ISF_REQ_JOIN is set - see InSim.txt
New system to reset a car at a location with or without repair
New admin commands /ujoin username and /uai username


Download : Test Patch 0.6K9 must already be installed!

http://www.lfs.net/file_lfs.php?name=LFS_INSIM_TEST_6K22.zip

I am also interested in:

[DONE] TINY_AXM to request IS_AXM packets (to get the layout)
[DONE] Interface buttons beside connections in lobby for admins to add players to grid
[DONE] Delete buttons using a range or an array
[DONE] Variable size IS_MSO https://www.lfs.net/forum/thread/88999

Lower priority:

- An option to disallow spectate or pit
- Packet to enumerate allowed cars - or other info?

Working on this now, thanks

I forgot to mention that if enabled, join requests are sent when a player joins a race and also when returning from the pits.

Both of these cases may occur in game or in the lobby. Specifying a start position in a join request reply has no effect in the lobby. Start positions are one-time use only and must be specified each time you want to override the normal spawning.

Entering from the lobby or restarting a race will use the normal spawning system for all players (default positions or custom start positions). To override normal spawning in these cases you should use custom start position objects or reposition players with IS_JRR packets.

Got join request working here, works nice, thank you. Would it be possible to keep the car setup window open (if the player had it open) while waiting for the join reply? This would stop it from looking like the join is always going to work.

EDIT: Oh, exactly this is happening now. Must have been a timing issue before.

Quote from PeterN :

EDIT: Oh, exactly this is happening now. Must have been a timing issue before.

Possibly if you were using a debugger on the external program, the join may have succeeded without receiving a reply. This happens if there is no reply for 3 seconds.

Quote from vitaly_m :

Also, yet another request:
Can we have a packet enumerating allowed cars on the server? This will be really nice, because that way my app could automatically detect what car to show with !top command.

About the enumeration of allowed cars, what about setting the allowed cars? I suppose now you use the /cars command? But maybe that is a bit clumsy / inconvenient? Do you think there should be something similar to IS_PLC but equivalent to the /cars command? Then the same packet could be used to report the cars allowed information.

Quote from Scawen :

About the enumeration of allowed cars, what about setting the allowed cars? I suppose now you use the /cars command? But maybe that is a bit clumsy / inconvenient? Do you think there should be something similar to IS_PLC but equivalent to the /cars command? Then the same packet could be used to report the cars allowed information.

The symmetry with set/query packets is a good thing indeed. Currently I have to pack the command like ALL-XFG-UF1 if I want to set more cars than admin command packet can contain

So, yes, better to have both set and query packets.

Regarding detecting allowed cars I started a thread earlier:
https://www.lfs.net/forum/post/1874022

Also error reporting in InSim would be useful (eg wrong admin pass):
https://www.lfs.net/forum/post/1893119

So eehh this JRR... What Index needs to be used @StartPos?

Quote from cargame.nl :

So eehh this JRR... What Index needs to be used @StartPos?

I've just been using zero for the Index so far and it seems to work ok. We're not actually dealing with layout objects, so Index doesn't really have a meaning.

Alright thanks.. I ask this to be sure because I tried some other methods to get this working and if I use the wrong values to begin with I can be busy for hours without getting anywhere. So you guys can spawn out of spectator mode everywhere you want, no matter what track combo?

Yes, the documentation is lacking for StartPos.

Flags should be 0x80, Index should be zero, then X, Y, Zbyte and Heading are used in the same way as for objects.

I got the values by looking at a packet that came out when I placed / moved a start position.

Found an issue (IIRC I mentioned this possibility the other day):

1. User is in setup/colour edit screen and /ujoin is called on that user.
2. Car is spawned on track (position determined by JRR). The player can drive the car, however the setup screen is still rendered on screen.
3. Player clicks OK, setup screen goes away and "<player> already has a car" message is shown in chat.

Edit: the above happens when the user starts from spectate. If they had done shift+p to get to the setup screen from the track, "User is already in the race" message is shown when /ujoin is called and afaict the car *is not* spawned

Yes, I was testing that yesterday to make sure there were no bad consequences. I'm not sure what to do about it. The same behaviour existed before, if you typed /join while in the pits, but then it was less of an issue.

I've just tested the JRR thing and it works fine for me.

Even with this "join from pit" thing Degats described, I see no problem with it so far.

By the way, it looks like the sequence goes like this:

/join
NPL join request packet sent
NPL regular packet sent
click OK button
NPL join request packet sent

Thanks for adding this new packet Scawen. It works like a charm (I haven't tested all features sufficiently though). One thing I noticed. The ground level check is on by default. If it is an easy addition, would it make sense to add the no ground level check option to StartPos? Or would this go too much in the direction of "surrealism"?

Quote from sicotange :

Thanks for adding this new packet Scawen. It works like a charm (I haven't tested all features sufficiently though).

Thanks for the test. Please let me know if it seems there is enough to do your ideas like multiple races in one environment, or if something else would help. Also the behaviour when a player gets /ujoin on his username while he is in the garage. How would this affect things in your case?

Quote from sicotange :

One thing I noticed. The ground level check is on by default. If it is an easy addition, would it make sense to add the no ground level check option to StartPos? Or would this go too much in the direction of "surrealism"?

To help me understand, what would this be used for? I think LFS always does some kind of ground check to avoid dropping the car too far. But as far as I know, the current system should work on things like concrete objects and doesn't have to be the actual ground.

BUG REPORT:

Somehow with DCon 0.6K10 an IS_MTC with UCID 255 (=server message) does not work. It is displayed on the DCon console though. Could someone try to send an IS_MTC with UCID 255 and confirm it works normally so I know I'm paranoid or not?

Quote :

Please let me know if it seems there is enough to do your ideas like multiple races in one environment, or if something else would help.

IS_JRR is the final addition I needed to make multiple races work. On the other hand some requirements I had in mind to make multiple races work flawlessly:

• A new control object like the current autocross checkpoint but without index reporting a timestamp and x,y,z,h of the checkpoint when the player crossed it. It is useful because the current 4 checkpoints are not enough to have multiple races obviously. At the moment I have a custom method reporting when player x crosses a custom checkpoint (a line made of 2 points) but it's far from ideal because I have to predict between IS_MCI updates when the player crossed the line.
• A unique laptiming packet with ability to start/stop and reset it by PLID (a stopwatch basically) and some way to get the TimeSpan data.

Quote :

Also the behaviour when a player gets /ujoin on his username while he is in the garage. How would this affect things in your case?

I don't think I like the current behaviour. If I understand it you can't force join a player in garage with /ujoin because he might be busy with the setup screen in the garage (it gives message "User is already in the race")? I think it should still force the player out of the garage. I might have missed a very valid reason not to do this though. If I'm not mistaken you can detect for how long the player has been in the garage (IS_PLP?). I think it's up to the programmer to prevent the use of /ujoin when the player seems busy in garage for a long time. If a player signed up for a race, he would receive a warning message or a countdown before the race so he knows when he will be "kicked" out of the garage.

Quote :

To help me understand, what would this be used for? I think LFS always does some kind of ground check to avoid dropping the car too far. But as far as I know, the current system should work on things like concrete objects and doesn't have to be the actual ground.

I don't have very convincing arguments but it could be interesting to simulate drops from certain heights (would physics cope?) and it could be useful for derbies and those sort of things.

Quote from sicotange :

BUG REPORT:Somehow with DCon 0.6K10 an IS_MTC with UCID 255 (=server message) does not work. It is displayed on the DCon console though. Could someone try to send an IS_MTC with UCID 255 and confirm it works normally so I know I'm paranoid or not?

Yes, confirmed.. Does not work.

Quote from sicotange :

BUG REPORT:

Somehow with DCon 0.6K10 an IS_MTC with UCID 255 (=server message) does not work. It is displayed on the DCon console though. Could someone try to send an IS_MTC with UCID 255 and confirm it works normally so I know I'm paranoid or not?

I can confirm that.

Regarding the /ujoin, I think we could go the way we are... If the car is not ready (being in pits, changing settings) to join the track, from the insim you can tell it, and you can either ignore it (so he likely fails the start) or you can spectate him alltogether and alert him to join at the end of the grid.

EDIT:
I think, that making us able to see (from insim) if the car is joined being in pits (send IS_PLP), would be enough regarding the JRR stuff. So that if the car is not ready (being in pits, changing settings) to completely join the track, from the insim you can tell it, and you can either ignore it (so he likely fails the start) or you can spectate him alltogether and alert him to join at the end of the grid.

I've made the IS_MSO packet have variable length. The maximum is still the same so the packet structure is not changed in any way. It's really a very simple change (one line) and should be very simple to fix external programs to handle the variable (usually smaller, never bigger) size. So I thought I should really do it for the IS_III and IS_ACR as well. Any objections?

Quote from sicotange :

BUG REPORT:

Somehow with DCon 0.6K10 an IS_MTC with UCID 255 (=server message) does not work. It is displayed on the DCon console though. Could someone try to send an IS_MTC with UCID 255 and confirm it works normally so I know I'm paranoid or not?

Thank you. I've fixed that in my version.

Quote from sicotange :

• A new control object like the current autocross checkpoint but without index reporting a timestamp and x,y,z,h of the checkpoint when the player crossed it. It is useful because the current 4 checkpoints are not enough to have multiple races obviously. At the moment I have a custom method reporting when player x crosses a custom checkpoint (a line made of 2 points) but it's far from ideal because I have to predict between IS_MCI updates when the player crossed the line.

Interesting.

Quote from sicotange :

• A unique laptiming packet with ability to start/stop and reset it by PLID (a stopwatch basically) and some way to get the TimeSpan data.

A stopwatch per player? Do you mean so they could see their own custom clock on their screen, so as if each player can have a different race start time? I'm not sure what you mean by TimeSpan data.

Quote from sicotange :

I don't think I like the current behaviour. If I understand it you can't force join a player in garage with /ujoin because he might be busy with the setup screen in the garage (it gives message "User is already in the race")? I think it should still force the player out of the garage. I might have missed a very valid reason not to do this though. If I'm not mistaken you can detect for how long the player has been in the garage (IS_PLP?). I think it's up to the programmer to prevent the use of /ujoin when the player seems busy in garage for a long time. If a player signed up for a race, he would receive a warning message or a countdown before the race so he knows when he will be "kicked" out of the garage.

It's not quite like that. If the player is in the garage, having not entered the game, then you *can* make him join. But he stays in the garage, although his car has appeared on the track. Then a pointless join request is sent when he eventually exits the garage and it says that his car is already in the race. For a start I should avoid sending the join request that is sent when he eventually leaves the garage screen, if his car is already in the race. You can't join if you have already joined and your car is in the race.

I don't want to kick someone out of the garage. The player might be in the middle of editing a setup and even moving a slider bar at the time. But maybe there should be a message on his screen making it quite clear that his car has entered the race.

Actually you don't know if the player (connection) is in the garage, because we are talking about the case when the player is not in the race, and has just gone to the garage, from being a spectator. Currently you don't know about that.

Quote from vitaly_m :

I think, that making us able to see (from insim) if the car is joined being in pits (send IS_PLP), would be enough regarding the JRR stuff. So that if the car is not ready (being in pits, changing settings) to completely join the track, from the insim you can tell it, and you can either ignore it (so he likely fails the start) or you can spectate him alltogether and alert him to join at the end of the grid.

Yes. In conjunction with making it clear if he has joined the race, and avoiding the pointless extra join request, maybe this is the best solution. Allow the host to know if a certain connection is in the garage, even if he does not currently have a player in the race...

Quote from Scawen :

I've made the IS_MSO packet have variable length. The maximum is still the same so the packet structure is not changed in any way. It's really a very simple change (one line) and should be very simple to fix external programs to handle the variable (usually smaller, never bigger) size. So I thought I should really do it for the IS_III and IS_ACR as well. Any objections?

My C++ based InSim can already handle all that - it honours the size byte, so incoming variable length packets should be no problem.

The CityDriving InSim will probably need tweaking, though I'd have to test it (a Java get() function may throw). If it does need changing, it should be very simple.


However, it's possible some old/no-longer maintained apps may not handle it well.
It won't affect me, but LFS External (which people should really stop using anyway as it's so far behind already) and Airio would need testing. They seem to be the two most common unmaintained apps afaik.

Quote from Scawen :

Yes. In conjunction with making it clear if he has joined the race, and avoiding the pointless extra join request, maybe this is the best solution. Allow the host to know if a certain connection is in the garage, even if he does not currently have a player in the race...

It is not pointless one! If he ends up editing setup after his car was already on the track, he will abuse the restrictions we want to enforce, so we need that extra final JRR

Quote from vitaly_m :

It is not pointless one! If he ends up editing setup after his car was already on the track, he will abuse the restrictions we want to enforce, so we need that extra final JRR

Changed settings aren't applied to the car after it's joined the track. The car on track will have whatever the original setup contained before editing started (i.e. the same as if you clicked undo). Therefore the first NPL will be correct.

I know for sure my insim will need (minor) modifying to handle variable size III/ACR