I created 2 scripts to run when I change wheels, so I can quickly reassign buttons.
All standard functions work fine (pit_speed, flash, etc.), but the script throws errors for all ctrl_f10, alt_f10 and such lines:
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.
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:
To sum up the possible options:
connect using TCP, UDPPort == 0: works fine
connect using UDP, UDPPort == 0: works fine
connect using TCP, UDPPort != connection port: cannot get NLP/MCI packets
connect using TCP, UDPPort == connection port: cannot get NLP/MCI packets, InSim throws errors
connect using UDP, UDPPort != ISI port: cannot get NLP/MCI packets
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.
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.
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.)
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.
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.
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.