Quote from PeterN :

cargame is right, this would be far more useful if it contained the handicaps (well, pretty much everything) as in the IS_NPL packet. (Which might suggest that maybe IS_NPL should be repurposed.)

It does look as if I can include that data (everything in the IS_NPL). It's not really available when that packet is sent but I can make the guests send the relevant data purely for InSim purposes.

I'm thinking to use the entire IS_NPL packet but it's NOT actually a player joining. It's still a join request and you'll receive another IS_NPL when the player actually joins. How to identify the join request NPL? Should it have a different packet ID, or maybe just re-use something else. Like for example the NumP could be 255 to indicate it's a join Request. Number of players isn't really a valid field at this point (we don't know how many players might join or leave between the join request and the successful join) so that data is really unused.

Regarding the IS_RQJ

In the IS_RQJ we need everything from the IS_NPL, in order to decide if we let driver join (need to check all the flags, game config, ... -- button clutch, restrictions, traction control, abs...)

I think you rather should not introduce whole new packet and use the IS_NPL. So we send IS_RQR in answer to IS_NPL.


Yet another request
Also, have you looked into other changes requests?
https://www.lfs.net/forum/thread/88125 -- [RFC]TINY_AXM to request IS_AXM packets at any time -- this one will make LFSLazy splits prediction/comparison bar work on open config tracks.

Quote from Scawen :

Like for example the NumP could be 255 to indicate it's a join Request.

Also PLID could be 255, ReqI 255 or any other thing.

In the end you can even have different Type byte

Yes but invalid PLID or ReqI would 100% break old InSim material. I just did an investigation of this and I am quite sure NumP = 255 is the safest to use. No guarantees though

Quote from vitaly_m :

In the end you can even have different Type byte

To make it clear, initially I thought that it would be possible to just send the IS_NPL and depending on response either put car on track or not. Then I saw we can't do it.

Also it will break compatibility with older insim programs -- say we run Airio and another program which does make use of this new feature.

So my current suggestion would be to have the new IS_RQJ packet being an exact full copy of the IS_NPL. This way old programs would just ignore RQJ and get only NPL, working as before.

Yeah, forget I said that, compatibility probably makes a new packet easiest.

Quote from vitaly_m :

Yet another request
Also, have you looked into other changes requests?
https://www.lfs.net/forum/thread/88125 -- [RFC]TINY_AXM to request IS_AXM packets at any time -- this one will make LFSLazy splits prediction/comparison bar work on open config tracks.

I'll have a look.

Quote from cargame.nl :

Yes but invalid PLID or ReqI would 100% break old InSim material. I just did an investigation of this and I am quite sure NumP = 255 is the safest to use. No guarantees though

PLID is already assigned at that point so we'll leave that one valid.

Old InSim programs should not be broken in any case because these new packets are only sent if requested on connection in the ISI packet.

Actually NumP could be zero which is maybe nicer. That value could never be in an actual NPL.

Quote from sicotange :

/join username = typed by admin (or sent by InSim program) to forcejoin someone (would respect the packets)

This does sound useful.

I haven't looked into it. Can anyone see a problem with this? It would be from the host but just as if the guest had typed /join from any menu screen they might be in...

I am quite sure Airio handles NumP=0 correctly, it only writes a wrong syslog line in log about the number of players. I have no idea about how other InSim programs react to this number though. It's theoretically not really a critical field. InSims get this NPL also when somebody leaves the pits so the first check is if PLID matches the internal array of PLID information already or not.

Quote from Scawen :

Actually NumP could be zero which is maybe nicer. That value could never be in an actual NPL.

Even better idea

Quote from sicotange :

/join username = typed by admin (or sent by InSim program) to forcejoin someone (would respect the packets)

That would be useful e.g. when making a custom starting grid before a league race, instead of having to call out all players one by one and wait for them to join the grid.

Quote from Scawen :

Can anyone see a problem with this?

So long as it can only be called from the lobby screen so that they still have to click ready, I see no issue. If it could be called on track then there's the potential for people to not be ready on the grid.

Quote from mbutcher :

So long as it can only be called from the lobby screen so that they still have to click ready, I see no issue. If it could be called on track then there's the potential for people to not be ready on the grid.

IMO, that's up to the admin/programmer to choose whether they want people to spawn on the start grid before a race or not if there's a chance they're not ready. It's not something that'll happen by accident if the server admins don't want it to.

The only problem I see is if /join is called while someone is actively editing/naming/renaming a setup or colours. In those situations it would be unwise to disturb the player IMO. I haven't thought of any other situations that could cause problems.

Quote from Flame CZE :

That would be useful e.g. when making a custom starting grid before a league race, instead of having to call out all players one by one and wait for them to join the grid.

If all joined.
How about IS_REO? It's worked when i tested it some years ago.
Collect PLIDs by UName then store in packet for get your start grid

Quote from repeat83 :

If all joined.
How about IS_REO? It's worked when i tested it some years ago.
Collect PLIDs by UName then store in packet for get your start grid

Yes, IS_REO works only if all people that need to be on the grid are already joined.

maybe useful update IS_REO and not make similar packet.

compatible with old version

Ok, after reading Flame and mbutcher posts I came with an idea, related to my yesterday's post.

If car status could be preserved, we will be able to:
- restart the race (or maybe any session for that matter)
- do 1 or more warm up laps
- once everybody is in his grid slot send a RQR to everyone (to engage handbrake, put neutral and keeping tire temps and all that stuff)
- /setlaps zero
- send to the host a "raceStart" packet (would this by a IS_Tiny?), to launch the starting lights


On top of that, Flame's last post brought to my mind Le Mans style start, where each car class is spreaded along the track to avoid first lap incidentes. IS_REO would require a fixed amount of car per class to do the corresponding layout, the new packet will serve this purpose just perfect.

Quote :

That would be useful e.g. when making a custom starting grid before a league race, instead of having to call out all players one by one and wait for them to join the grid.

A variation on this is multiple races on 1 server. Tracks like the new Westhill can easily host several races simultaneously.

Quote from sicotange :

A variation on this is multiple races on 1 server. Tracks like the new Westhill can easily host several races simultaneously.

And Rockingham has 3 independent circuits - they even advertise that capability (though one is missing a pitlane)

@Whiskey:

I guess the start light capability is probably the same priority as the track lights. I know Scawen mentioned he wanted to get them working at some point and when he does, the start procedure could be allowed to be triggered by InSim too (and by a command at the start of a session perhaps).

@Degats:

Quote from Degats :

IMO, that's up to the admin/programmer to choose whether they want people to spawn on the start grid before a race or not if there's a chance they're not ready. It's not something that'll happen by accident if the server admins don't want it to.

The ready system shouldn't be able to be bypassed in my opinion. Automatic grid stacking via InSim and the ability to use /join <username> is good enough.

Allowing the host to set a countdown timer to 'ready up' might be a good compromise. Those who don't ready up in time are sent to the pit lane or to spectate.

Quote from mbutcher :

The ready system shouldn't be able to be bypassed in my opinion.

Even for practice/qualifying and custom race types? The ready system wouldn't *have* to be overridden, it just may be useful in some situations.

A timeout then spec can already be done using InSim, but if noone clicks ready, the session start can be delayed - then there are the people who insist on quickly joining every time, but never actually click ready, which the relies on an admin racing them and the latency to get the session started

Hello again
I have little explain for some angry people why Scawen need so many time to make real tyre physics.

https://www.youtube.com/watch?v=I8GQCZgCNw8 this is little awsner why You need to wait and wait.

Sorry for little off topic.

There are no angry people, neither people waiting. If you still are you indeed need to see a doctor talking 1h15 about sun, flowers and clockworks.

Quote from Degats :

A timeout then spec can already be done using InSim, but if noone clicks ready, the session start can be delayed - then there are the people who insist on quickly joining every time, but never actually click ready, which the relies on an admin racing them and the latency to get the session started

I was talking about a countdown on the lobby screen, not during a session.

Quote from Flame CZE :

That would be useful e.g. when making a custom starting grid before a league race, instead of having to call out all players one by one and wait for them to join the grid.

There would still be the issue of having to type in the LFS usernames of the drivers to put them on the grid, which you can;t really see because the custom driver name is shown.

It would be very useful if there were a 'one click' solution for this for those with admin rights.
Perhaps an extra button alongside the list of usernames to add drivers as well as removing them from the grid.

Quote from Bean0 :

There would still be the issue of having to type in the LFS usernames of the drivers to put them on the grid, which you can;t really see because the custom driver name is shown.

It is possible if you hold the Ctrl key and right-click the username, it will appear in the text box. Not ideal, but possible.

Umm, I just assumed we were talking about an insim doing this, not a human...