I'm going to report myself because that was stupid.

Session AND SERVER of Incident: Race 1
Lap AND MPR timecode of incident (or session time or UTC Time of Day): Lap 1, MPR timecode 2:20
Car(s) involved: 21, 19, collateral damage 51 and 54
Location of Incident: Turn 1
Brief Description of Incident: 21 dives on the inside and collides with 19.

Bokujishin/Read and Understood

GodotInSim is now feature complete after I added InSimRelay and fixed more bugs, so I released version 1.0.0 on GitHub.
If you are interested, you can take a look at this simple demo.

Okay, so as per usual, it turns out I did make a mistake (though I don't fully understand it): when I refactored my connection code, I changed the PacketPeerUDP socket's bind() method to connect_to_host(); this works perfectly fine for InSim itself, but not for OutGauge, OutSim and the NLP/MCI packets sent via UDP. On the other hand, using bind() triggers an error when connecting InSim (this is the part I don't get), but it works for the others.
I solved this a bit hackily by changing how I connect the socket for InSim and the others, and everything is working so far. Still getting the InSim errors when using the same port, though.

Networking isn't exactly my forte, apologies for the short monologue

As I'm close to releasing a "production-ready" version of my GodotInSim library, I went back to the details of the TCP/UDP settings in the ISI packet. Using full TCP or full UDP works just fine (UDPPort = 0 for both protocols), however I am having issues with NLP/MCI packets on mixed TCP/UDP, as well as just UDP but using a different port (basically, any time I set UDPPort to something other than zero).

Using Wireshark, I can see the packets are being sent (with port numbers e.g. 29999 -> 30000, haven't checked their contents), however I can't seem to get any packet in Godot (I already checked the UDP socket is connected on the correct port). Additionally, setting UDPPort to the same port as the TCP one causes LFS to throw errors for each NLP/MCI packet sent:

Quote :

InSim : first packet has unexpected size - should be ISI
InSim : first byte in packet does not represent size

To sum up the possible options:

1. connect using TCP, UDPPort == 0: works fine
   
2. connect using UDP, UDPPort == 0: works fine
   
3. connect using TCP, UDPPort != connection port: cannot get NLP/MCI packets
   
4. connect using TCP, UDPPort == connection port: cannot get NLP/MCI packets, InSim throws errors
   
5. connect using UDP, UDPPort != ISI port: cannot get NLP/MCI packets
   
6. connect using UDP, UDPPort == ISI port: cannot get NLP/MCI packets, InSim throws errors (more of the same error when sending packets)
   

For reference, my implementation has an LFSConnection class/pseudo-interface to handle connect, disconnect, send_packet and get_packet, with LFSConnectionTCP and LFSConnectionUDP implementing those functions. LFSConnectionTCP also creates an instance of LFSConnectionUDP. Both the "main" UDP connection and the child one with TCP exhibit the same issues, and the main UDP connection can still send and receive other packets, only NLP/MCI are missing (though in case 6 above, sending packets causes additional InSim errors).

I will investigate some more on the Godot side and in my code, in case I made a mistake somewhere, but I would appreciate any insight, also the errors do seem to be an issue on LFS's side. I just cannot understand why those packets are not being picked up by Godot, especially in UDP-only mode (cases 5-6 above), as other packets are being sent and received properly.

#21

Nice, I wanted to try Bad Apple in LFS using modded "vehicles" with lights for pixels, but then realized you could only control the local car's lights with this, so the only way I can hope to do something half-decent would be to have 40 people running some "pixels" in sync.
Never thought about using InSim buttons, this looks quite good! Maybe using filled rectangles instead of underscores would make it better?

To add to the "changing one line of code": maybe (and I say maybe) it would be that simple to change the maximum number of gears.
But then, you have to check other parts of the game, make sure it works on any vehicle with more than 7 gears, update the UI properly to allow tweaking gear ratios for all gears (does it still fit the screen if you have 10 or more?). You also have to consider InSim, which sends packets with the current gear, is there anything that needs to change to accommodate the higher number of gears?

It really never is that easy to change something in code, or rather it is usually only somewhat easy in smaller projects. That said, I agree that at some point (ideally of course after the new physics and graphics), it would be nice to see more than 7 gears for some vehicles. As has been said, although it is a *racing* simulator, we do have street cars in the official selection of cars, and they can race...

I just released version 0.9, including a bunch of fixes for various packets, better color handling for text (including stripping and conversion to/from BBCode), and utility functions for unit conversion (kph to mph, rad to deg and various other units).

I will now work on adding InSimRelay support, and try to test host packets, as I haven't managed to connect to InSim with host/admin privileges yet.

Thanks for the kind words!

21/Bokujishin/Cyril Bissey/France/no team

I found some time to work on text encoding, once again shamelessly adapting/stealing code from Flame CZE and adapting it to Godot.
I have released version 0.8.1 on GitHub containing this feature as well as fixes for several other issues with various packets.


I should now have everything I wanted to add (unless I'm forgetting something), so will bump the version to 1.0 after some more testing and bug fixing.

Some projects I am working on with this tool:

• Telemetry recording and display
  
• Live race stats (minimap with driver names, standings with tyre compounds, pit stops, time deltas, etc.)
  
• PTH and SMX file parsers to display them in 3D
  

From the set pitstop suggestion thread:

Quote from Scawen :

We can set number of laps and a penalty, so I guess the number of pit stops done is the one missing thing.

I noticed that the PEN packet has a spare byte, could it be used to set custom penalties in addition to predefined ones? e.g. 5s, granularity of byte allows for single second penalties.

These penalties could be easily adjusted, though I must say I'm not sure how it should be presented to the players or actually set as part of the PEN packet - alternatively, add a new packet for this, such as PET (PEnalty Time)?

The command to set the penalty could take the format /penalty USERNAME TIME.

#21

21/Bokujishin/XRR

Quick nitpick in IX.4.a), I believe "all other teams" should be "all other drivers".

yes/21/Bokujishin

In the Signups post, it says we need an S2 license, but isn't Rockingham S3 only?

21/Bokujishin/Cyril Bissey/France/no team/cyk774

Session AND SERVER of Incident: Main, Race 2
Lap AND MPR timecode of incident (or session time or UTC Time of Day): lap 2, MPR 4:48
Car(s) involved: 21, 35, 27
Location of Incident: turn 5
Brief Description of Incident: 35 spins 21 into the gravel, may have been "helped" by 27 (not sure if sliding on their own or following contact with 27).

For anyone using the Godot game engine, I released an InSim library written in GDScript, which includes support for InSim, OutSim OutGauge and InSimRelay.

GitHub link to the library (MIT license)
GitHub link to a very simple demo



The library supports InSim version 9 as of LFS version 0.7E.

What is included:

• All InSim packets are implemented.
  
• All text input is done from UTF8 and converted to LFS format, all packets convert text back to UTF8.
  
• OutSim can be used from the configuration file.
  
• OutGauge can be used from the configuration file.
  
• InSimRelay is available.
  
• There are some utility functions in the GISUtils class for converting units.
  

Feel free to try it if you're interested, I will update with examples as I have time to work on them.
There are also a .pth file reader and a .smx file reader included, for 3D rendering.


Special thanks:
Flame CZE and his Node InSim library, where I found how to parse car names for mods and took inspiration for text conversion.

Last edited by Bokujishin, Wed, 3 Apr 2024 21:26.

Updated #21 with some more logos.

Quote from mbutcher :

We (Sim Broadcasts) also noticed some frame drops during our broadcast of round 1 last Sunday. We'll be trialling a new AMD CPU with a 50% higher clock speed for round 2 to try and combat this (3 cheers for AWS ) - Your experience would have been smoother than ours because you were driving, not observing 35 cars at full LOD all at once.

I can assure you my experience was not that smooth as my game actually *crashed* on both occasions (that's why I dropped out and had to start both races from the pitlane), though that was due to my Linux/wine not being properly configured and should not happen next Sunday (I hope, I'm not planning to install Windows ever again on my PC...).

The T1 incident with the Ferrari mod looks horrendous though, I've never seen such frame drops (or such T1 carnage ), it's definitely necessary to have sensible limits to avoid this kind of situation.

@Scawen I suppose the freezes occur while the game is loading the assets (car model and/or skin), would it be possible to load those on a non-blocking thread instead? And either keep the car invisible while assets are still loading, or load and display them from lowest LOD to highest, so that the game could still display something while it loads the higher detailed stuff, and avoid stuttering/freezing?

I know you don't agree with many modders about triangle count, and I understand the reasoning, though I don't personally agree that 65k triangles is *too much* - however I do agree that getting 65k for the sake of getting them, even if they don't bring anything visually, is a waste of resources. I just think that some other popular sims (think iRacing or ACC) manage grids larger than LFS, with cars that I believe are probably all more detailed than LFS cars (and probably LFS mods as well), and they seem to work pretty well; the engine running the games is different though (Unreal for ACC, not sure about iRacing), so while I agree modders should not abuse the limits, and I understand why you don't want to increase those limits, maybe there is still something you could do to alleviate this particular issue?

I'm not sure what the threshold is where the problem appears, I know some people talked about it after the NDR GT4 Sprint Cup with the N.400S GT4 (there were 35 cars racing + safety car and rescue vehicles), I didn't personally notice any stuttering but I do have a rather powerful computer (Ryzen 7900X, AMD 7900XT, 32GB of RAM, NVMe SSD).

Last edited by Bokujishin, Tue, 16 Jan 2024 22:13.

yes/21/Bokujishin

yes/21/Bokujishin