Hi, there!

For something like 18 months now I've been developing the Airio server tracker and newly also the Aonio client tracer. In the apps I'm using just about EVERY single piece of InSim/OutGauge info available through custom created complete .NET library. While working this extensively with the available data I found a few things that would be worth an update in some future LFS version/patch, even one obvious bug.

Note that the following info/requests are NOT for some InSim application, but they come from an InSim developer to LFS developers. Please use this thread only to add serious InSim update requests, once you fully studied the currently available information. Thanks! And now to the individual issues, arranged by severity:

1) First the bug: When a player is leaving pits and at the same time updating his controls (I'm afraid I'm not sure how it is done), there is an incorrect Player ID reported in IS_NPL. Please see this example extract:


A driver is leaving pits here, his player ID in IS_NPL is reported as #39. At the same time he somehow updated his controls and IS_PFL reports his player ID as #28, and this is actually the correct PID, as seen from the last IS_PLL packet. The problem is that IS_NPL is binding connection ID with incorrect player ID in this case, leading to all kinds of troubles. (To solve the trouble, Airio spectates the driver, announcing rare LFS bug as the reason, forcing another race join.)

2) Currently it is not possible to enforce having traction control turned on or off. It is only part of car data as seen in IS_NPL (player joining race). If someone turns on/off TC when already on track, it is not reported and the state cannot be checked. TC bit should be in my view part of player data, such as e.g. auto gears are, with changes reported by IS_PFL. Doing TC on/off checks would then be possible.

3) Support somewhere at least a new bit saying if car is damaged (or even a byte with some details of the damage nature - body, wheels, ...). It would then be possible to require drivers to have repairs turned on during pitstop, making them more careful about their cars.

4) Messages to connections/players could really be longer, the current 64 bytes limit is too severe. When a nickname in the message is required, also some colors and language changes, suddenly there's only something like 20 to 30 bytes for info. Upgrading 64 bytes to 96 bytes would make life so much easier for me (and Airio translators), and also to other InSim developers, I think.

5) Include avg. tyre and clutch temperature in OutGauge data, so that custom displays can be made. It would be also nice to have oil/engine temperature data actually with some values. Also some indication of engine damage would be most welcome, but I realize this is a more involved matter.

6) Allow sending "hidden" info to InSim apps on clients. Clients can send hidden information to server (and InSim running there) using /i, I think there's currently no way to communicate the other way.

Thanks for reading, I hope to see some updates soon!

Excellent suggestions, I agree with all of them but I'd go even further on #4.
To allow the implementation of this suggestion, I'd rather have 128 bytes with no trailing Zero.

Apart from that I'd really love to have some control over layouts via InSim, such as:

• Notification when objects are added, moved (by an admin, not a collision) or deleted; should contain an ObjectID, X/Y/Z coords and Rotation and the UCID of the user responsible for the change of state.
• Ability to add objects by specifying ObjectType, X/Y/Z and Rotation. If ReqI != 0, a response is sent containing the added object's ObjectID.
• Ability to move or remove objects using the ObjectID and new coordinates and rotation if moving.
• Ability to instantly reset an object that's been moved in a collision.

That's all I can think of right now, it's a hell of a task I'm sure, but no harm in suggesting it, right?

InSim direct DLL that allows for direct plugin development utilizing a callback mechanism. (When player pits, call function player_pits() on each plugin if the function exists within the plugin.)

Hello,

Some improvement in buttons ( i added some of this feature, but this eat bandwidth )

- More than 240 buttons
- Blinking buttons
- Rotation message buttons Mess1, mess2, ..., messLast,mess1,mess2 etc..
- More then none, light gray, dark gray background for button
- GPS speed for drift scoring, not only whells rotation speed ( try to do that with coordinate in LFS, but packet are no so precise, globally yes, but for a 1/10 s no )

I don' know in wich version of LFS, but we lost UTF8 support char in LFS ( fuel logo disapear and more other logo ).

Quote :

InSim direct DLL that allows for direct plugin development utilizing a callback mechanism. (When player pits, call function player_pits() on each plugin if the function exists within the plugin.)

I have added this feature in experimental LFSLapper to add plugin in DLL, but i don't know if there are people who want or can use that.

Gai-Luron

Quote from Gai-Luron :

- GPS speed for drift scoring, not only whells rotation speed ( try to do that with coordinate in LFS, but packet are no so precise, globally yes, but for a 1/10 s no )

Unlike Speed in OutGauge packets, the Speed reported in CompCar is actual movement on the X and Y axis and not based on differential, wheel or engine rotation. You can safely assume the reported speed to be the actual velocity of the vehicle

Regarding the precision: The problem is not actually precision, but the fact that the LFS host does not calculate the physics. The position data sent via MCI/CompCar are always the latest data received from the client. With an NLI of 50ms, that means it's entirely possible to receive the same position data twice or even three times without the LAG bit on (at pps 6). Sadly, this makes it impossible to accurately time position data. A server-side G-meter is still reliable enough to determine whether a vehicle had a crash or not though, I tried

Quote from Gai-Luron :

- Rotation message buttons Mess1, mess2, ..., messLast,mess1,mess2 etc..

I had somthing like this in lfsalapper with sced. events but i removed it for lag reasons

Quote from Dygear :

InSim direct DLL that allows for direct plugin development utilizing a callback mechanism. (When player pits, call function player_pits() on each plugin if the function exists within the plugin.)

This. For local InSim apps it would be better to talk directly to the game and cut the network out of the picture. This kind of goes without saying for OutGauge and OutSim. I don't mean to say that the network interface isn't useful, it's just a little much for the majority of local applications.

Also, I'd like to see telemetry information OutGauge.

Quote from tmehlinger :

This. For local InSim apps it would be better to talk directly to the game and cut the network out of the picture. This kind of goes without saying for OutGauge and OutSim. I don't mean to say that the network interface isn't useful, it's just a little much for the majority of local applications.

Also, I'd like to see telemetry information OutGauge.

I very much agree with that assessment, and that's a direction I hope to see the devs move into.

Just to be clear what type of telemetry info?

"telemetry" just means getting information remotely. So it doesn't itself explain what information should be received.

That said; OutGauge has loads of useful info: though I assume you guys are talking more like TireHeat / conditions and things of that nature? I ask because if it is going to be implemented it needs to be understood.

This is not exactly an InSim suggestion; but it is in a way a programmer suggestion;

I would like very little more control over the input using the current command / scripting system or InSim/a connection itself.

basically my command would be:

/hold [key]
/release [key]

or

/setaxis val //where val is 0 to 1, -1 to 1 or even some other means.

-----------------

The request comes from my attempt to use LFS as a platform for the AI project, and with that I believe this will never happen. If there is already a way to do this I have overlooked it - and trust me, I've read the Commands.txt over and over again.

Quote from EQ Worry :

1) First the bug: When a player is leaving pits and at the same time updating his controls (I'm afraid I'm not sure how it is done), there is an incorrect Player ID reported in IS_NPL. Please see this example extract:

09.12.23 14:15:36 #2 JPeace left the pits (FBM)
09.12.23 14:15:36 #2 C15P39 [IS_NPL]
09.12.23 14:15:36 #2 JPeace updated controls
09.12.23 14:15:36 #2 C00P28 [IS_PFL]
09.12.23 14:15:38 #2 JPeace joined the spectators
09.12.23 14:15:38 #2 C00P28 [IS_PLL]

A driver is leaving pits here, his player ID in IS_NPL is reported as #39. At the same time he somehow updated his controls and IS_PFL reports his player ID as #28, and this is actually the correct PID, as seen from the last IS_PLL packet. The problem is that IS_NPL is binding connection ID with incorrect player ID in this case, leading to all kinds of troubles. (To solve the trouble, Airio spectates the driver, announcing rare LFS bug as the reason, forcing another race join.)

Thanks for this bug report.

The sequence of events in that log does look quite wrong and really should not happen like that at all.

So... apparently not just an InSim bug but a real LFS bug. I wonder if it could be in any way related to that other bug that causes a message "x does not have a car".

I've been looking in the code and how the packets are sent on exiting from the garage but I am struggling to see how this could happen. If there was a way to reproduce it, that would of course be the best thing. But failing that, we need some more information. Was there anything else nearby in the log relating to JPeace? Was another player joining when JPeace was trying to leave the pits? Was JPeace a spectator trying to join, or was he a player already in the race who had temporarily gone to the pits?

This is complicated and I can't see the fault in LFS code so I will need more info. Maybe the MPR would help if you have it, or a bit more of the log file, before and after the event.

"Somehow updates controlls" is most likely a script, switching shifter mode or something like that.

If it helps, I've found that the order in which NPLs are sent sometimes differs from the order in which player joins are shown ingame, i.e. while it says

Quote :

Mr.X has left the pits (XRT).
Mrs.Y has left the pits (RAC).

it sends the NPLs in reversed order, meaning Mrs.Y first in this particular case.

Another interesting thing is that somtimes Shift+R, which causes the client to send spectate followed by join if more than 1 player is present in the race on Autocross layouts (with a starting position), fails with either a carsmax 1 warning (meaning the join arrived before the spectate) or, somewhat logically because there really is only one player and therefor car (and setup) in memory, the "does not have a car" message (if carsmax is >1 on that particular server). What I gather from this is that there are certain conditions where the client sends packets without awaiting confirmation of a previous request from the server.

Whenever a player is leaving pits and at the same time updating controls, I believe the basic succession of events is always the same. First NewPlayer packet is sent (the "Joining race" line), then the PlayerChanged packet is sent. But this one includes different PID, which Airio does not find (and thus can display the "Captured" line).

The following is just for info: Airio remembers the faulty condition and as soon as it sees is server output (normal text) that someone "updated controls", it spectates the player by his nickname (this is the "Solved" line). Note the wrong PID is then seen also in entering pitlane and leaving race events.

The primary problem is that I cannot recreate the condition, I do not know what to do to be joining race and updating controls at the same time. I was sking people that I saw somehow accomplishing this, but I was not able to get some reasonable answer. A guy said: "Now automatic gears," but when I tried to change autogears in pits, I never generated the two events.

Mu humble suggestion: Find out all cases when the "updated controls" is displayed and how come it is sometimes shown when joining track. Sorry if this is not for some reason workable. :-) Also, unfortunately I do not have any replay of this event available, but I'll try to spread the word and get one...

Below are examples of theprobable bug. Notice the basic mechanism is always the same. Thanks a lot for looking into this (and hopefully also updating other InSim or OutGauge info)! :-) Good Luck!

EQ Worry: As I said, scripting. In LFS/data/scripts, you will find scripts for every car and a couple of "class" scripts, such as paddle.lfs and sequential.lfs. Now each of the individual car scripts (which are executed when you leave the pits in the corresponding car) executes either road.lfs, paddle.lfs or sequential.lfs by default. Some users may have configured their shifter related scripts to change shifter mode, which would update the player flags, hence resulting in a PFL

Edit: I've just tested this by echo'ing something, the interesting bit is that the script is executed BEFORE the join is sent to the server, possibly sending the PFL equivalent from client to server BEFORE the actual join as well, could that be the bug?

Very interesting note about the scripts. However, how come the bad sequence of events happens only exceptionally? See below. A guy was joining several times and then suddenly and only once the bug happened. I do not use scripts much, but this confuses me.

Very interesting indeed, I did some further testing and it seems scripting is not the cause of this, because it doesn't trigger the "updated his/her controls" message.

Lengthy read below :rolleyes:

I have, however, found a way to reliably reproduce the "x does not have a car" bug, here's how:

• Enter the track in any car.
• Hit Shift+P and Shift+O in quick succession, it has to be quick enough for the options menu to come up before you enter the pits, which if you succeed, you will not. Instead you will be spectated, but remain in the race at the same time (still present in NLP/MCI), no PLL is sent even though you cannot join unless you pit and join from there or Shift+S and join.
• Change any of the controls, i.e. change shifter mode, hit Ok.
• "X does not have a car"

But, even though the pit/spec status of the client is messed up, the server does not re-assign the PLID you had (or have, as far as the server is concerned), so this is not the cause of PLLs with invalid PLIDs.

However, there is a way to reproduce this as well, although it's hard to do on a decent machine. It requires either a heavily loaded server, or patience, luck and a good connection, ideally local. I didn't have the former available for testing, so I went with the latter:

• Start a server with carsmax >= 3 and carsguest = 3.
• Place a starting position and put a restricted area over it, or alternatively, place restricted areas over all pit boxes and start a qualifying session.
• Bind /ai to an F-key.
• Spam the server with AIs using your hotkey.

Although debugging this would be much easier if we had a little more information about LFS's internal communication, I decided to have a go at sniffing and see how the synchronisation works.
It's initialised by the client (obviously) with a 70 byte packet containing player flags and controls, as well as the player name, number plate, suit (driver skin) and helmet skin name.
The server responds to this with a 75 byte packet containing the same information, plus the PLID and some stuff I didn't bother investigating since a) Scawen knows and b) I don't have to know
After receiving the confirmation, the client sends a 219 byte packet containing the car info, including car full name, skin name, colours and the setup.

Now for some reason, the client starts to ignore the confirmation when spammed with commands (join, quick restart [shift+r on autocross lyts] or ai) and sends the "CAR COL SET ENG"(?) right after the PLY(?), resulting in "Could not add car info - unknown id" and causing the server to send PLLs for PLIDs that it never sent NPLs for.

I believe the PFL bug cannot be reproduced with a single connection, we would have to organise a testing session of sorts to fill up a server

Quote from morpha :

Very interesting indeed, I did some further testing and it seems scripting is not the cause of this, because it doesn't trigger the "updated his/her controls" message.

Lengthy read below :rolleyes:

I have, however, found a way to reliably reproduce the "x does not have a car" bug, here's how:

• Enter the track in any car.
  
• Hit Shift+P and Shift+O in quick succession, it has to be quick enough for the options menu to come up before you enter the pits, which if you succeed, you will not. Instead you will be spectated, but remain in the race at the same time (still present in NLP/MCI), no PLL is sent even though you cannot join unless you pit and join from there or Shift+S and join.
  
• Change any of the controls, i.e. change shifter mode, hit Ok.
  
• "X does not have a car"
  

But, even though the pit/spec status of the client is messed up, the server does not re-assign the PLID you had (or have, as far as the server is concerned), so this is not the cause of PLLs with invalid PLIDs.

However, there is a way to reproduce this as well, although it's hard to do on a decent machine. It requires either a heavily loaded server, or patience, luck and a good connection, ideally local. I didn't have the former available for testing, so I went with the latter:

• Start a server with carsmax >= 3 and carsguest = 3.
  
• Place a starting position and put a restricted area over it, or alternatively, place restricted areas over all pit boxes and start a qualifying session.
  
• Bind /ai to an F-key.
  
• Spam the server with AIs using your hotkey.
  

Although debugging this would be much easier if we had a little more information about LFS's internal communication, I decided to have a go at sniffing and see how the synchronisation works.
It's initialised by the client (obviously) with a 70 byte packet containing player flags and controls, as well as the player name, number plate, suit (driver skin) and helmet skin name.
The server responds to this with a 75 byte packet containing the same information, plus the PLID and some stuff I didn't bother investigating since a) Scawen knows and b) I don't have to know
After receiving the confirmation, the client sends a 219 byte packet containing the car info, including car full name, skin name, colours and the setup.

Now for some reason, the client starts to ignore the confirmation when spammed with commands (join, quick restart [shift+r on autocross lyts] or ai) and sends the "CAR COL SET ENG"(?) right after the PLY(?), resulting in "Could not add car info - unknown id" and causing the server to send PLLs for PLIDs that it never sent NPLs for.

I believe the PFL bug cannot be reproduced with a single connection, we would have to organise a testing session of sorts to fill up a server

what about when u talk and do that like on a laggy server u press shift p and start typing it will also do this i belive

Quote from blackbird04217 :

"telemetry" just means getting information remotely. So it doesn't itself explain what information should be received.

That said; OutGauge has loads of useful info: though I assume you guys are talking more like TireHeat / conditions and things of that nature? I ask because if it is going to be implemented it needs to be understood.

Sorry, I'm guilty of the common misuse of "telemetry".

You pretty much hit the nail on the head; tyre temperatures are the really big one. Beyond that, things I can think of right now that I'd really like to have:

• per-wheel suspension forces/travel and rotation speed
  
• steering angle
  
• applied braking force
  

I'll say right up front that it's not even half as useful as the functionality InSim/OutGauge provide... it would be kind of a novelty feature. On the other hand, given the information that's already available to us, I don't expect (admittedly, I could be totally naive here ) it would be too difficult to supply that information as well.

On the other hand, if Scawen could expose a way in InSim to dump a raf at the end of each lap, that would work too. Obviously, much like fuel load is omitted in OutGauge for any car but your own, it should only work for a local players.

Quote from morpha :

However, there is a way to reproduce this as well, although it's hard to do on a decent machine. It requires either a heavily loaded server, or patience, luck and a good connection, ideally local. I didn't have the former available for testing, so I went with the latter:

You could under clock your server, and you could also change the packet per second to a lower values, these two things might help.

Quote from tmehlinger :

You pretty much hit the nail on the head; tyre temperatures are the really big one. Beyond that, things I can think of right now that I'd really like to have:

• per-wheel suspension forces/travel and rotation speed
• steering angle
• applied braking force

I would add to that:

• compound
  
• grip (how much force is require to remove tire from the surface, includes areo grip applied to wheel as needed)
  
• mass (mass on wheel)
  
• presure (pressure in tire)
  
• temprature (on surface, and internal)
  
• load (log, lat) in % (float).

• Angle
  
• Drag (impedance the element is adding to the drag of the whole unit)
  
• Down force (combined with wheel grip would allow you to find how much the tire is getting from down force vs mechanical grip.)

Thanks for the logs but I think you missed one important question.

Quote from Scawen :

Was JPeace a spectator trying to join, or was he a player already in the race who had temporarily gone to the pits?

What I am asking is - when the bad sequence of events comes up (text appears on the screen "JPeace left the pits" followed immediately by "JPeace updated controls") ... what was the previous message about JPeace?

Was the previous message "JPeace pitted" or "JPeace joined the spectators" ?

These are two different situations which go through the code in different ways.

Quote from EQ Worry :

Mu humble suggestion: Find out all cases when the "updated controls" is displayed and how come it is sometimes shown when joining track. Sorry if this is not for some reason workable. :-)

Yes, I have spent a few hours now studying all cases of this. And in every case, it seems impossible for this to happen. Of course, it is possible - that is why we are seeing it. It's complicated and confusing, a sequence of events using multiplayer packets and various functions all over the program, so a bit too confusing for my human brain. That is why I need the information to narrow down the search.

Quote from Scawen :

Was the previous message "JPeace pitted" or "JPeace joined the spectators" ?

The log provides the answer as it lists a new PLID everytime, meaning the player spectated. I doubt the "x updated his/her controls" message is from the client actually updating the controls, I figured it's caused by either the client or the server comparing one PLY to another, invalid one. Since this is probably a key point, you might want to think about some debug info around where that message is generated, a PLY hash or some way to identify an invalid PLY.

I've managed to reproduce the bug now. I don't know if it's really the way your users got the bug but at least it's one way to do it.

1) Put the text "/join" into an F key
2) Start a local host and join with a guest
3) Press the F key twice in quick succession

- If the second hit of the F key is too late, you'll join then get a message "driver already in race" (not a bug)
- If you press it too quickly you'll get "x does not have a car" and "Could not add car info - unknown id"
- If you press it at just the right speed you'll get "x left the pits" and "x updated his controls" (sends PFL with the new unique id)

More investigation...

OK, I've found a way to do it without any key binds. It is by using the SHIFT+J keypress (twice) to join. I can't seem to do this in normal spectator mode because there is anti-spam projection on the keypresses. However, it can be done if you have the ESC menu open. Then the first SHIF+J is done from the ESC menu and the second one is after the ESC menu has closed, so there is no spam protection between the two keypresses.

So... a more likely / realistic way to reproduce the bug :

- Join a host (in-game)
- Join the spectators
- Press ESC
- Press SHIFT+S twice quickly

After several attempts you can reproduce the bug - the timing has to be just right.

Explanation :

The second join request is wrongly interpreted as a player updating their controls (because the same player info packet is used for that purpose). But the changing unique id is caused because actually the player was not updating their controls at all - the host just accepted two join requests in quick succession so assigned each joiner with a new unique id.

It would be very easy to fix in an incompatible way but I'll see if I can do a clean fix in a way that retains compatibility. My first guess at a fix is that the host could make a note that a join request is already in progress, so ignore the second one.

Thanks a lot for the explanation! It perfectly fits the situation that can be observed - it actually does not concern updating controls, but (unfortunately) it assigns new PID to the driver, changing the one linked previously to CID, which is a problem.

Thank you for looking into this, I know how exhausting it is trying for many hours to discover one small thing happening only occasionally and impossible/hard to reproduce. I have actually now a replay available where the problem happened, but I think it is not needed anymore.

Looking forward to a fix and maybe some other InSim/OutGauge additions. Really helpful would be moving the traction control bit to driver data, adding damage bit (or byte). Good would be longer messages to connections, additional OutGauge data (tyre/clutch temperatures) and I'm sure lots of other things could be devised, but I don't want to flood this thread with too many requests.

PS: A very inappropriate request here, but in case you, Scawen, will be reading this post yet, please do consider returning BL1R and BL2R back to demo. I feel, and I'm not alone, that demo got substantially weaker by removing the two tracks, by which the whole LFS community suffered, possibly with negative impact to S2 racing as well. Of course I do not have any exact numbers to support my feeling, but there it is...

yes i would like it back also