As a quick module development introduction, here are some guidelines, virtual methods for module management, InSim callbacks, and what I consider to be best practices.
Modules are Godot scenes based on a MarginContainer, with a script inheriting GISModule. The only thing a module is required to do is provide a name for itself, in the _initialize_module() virtual method, which must return a String. After that, modules are free to do whatever they want within the possibilities offered by Godot: logic only, 2D graphics, or even 3D graphics.
While Godot InSim provides signals to connect to, GIS Hub connects itself to those signals, and provides callback functions instead, that you need to implement. For instance, you don't manually connect to the isp_mso_received signal, but directly implement the _on_isp_mso_received() callback.
GIS Hub provides wrapper functions for all Godot InSim helper methods that send packets (send_message(), add_button(), etc.); helper methods that are only used to get data or otherwise don't result in sending packets have no wrapper, and should instead be accessed via the hub_insim variable available to all modules.
Virtual methods for modules include the following:
Now for some "best practices", I would recommend the following:
Modules are Godot scenes based on a MarginContainer, with a script inheriting GISModule. The only thing a module is required to do is provide a name for itself, in the _initialize_module() virtual method, which must return a String. After that, modules are free to do whatever they want within the possibilities offered by Godot: logic only, 2D graphics, or even 3D graphics.
While Godot InSim provides signals to connect to, GIS Hub connects itself to those signals, and provides callback functions instead, that you need to implement. For instance, you don't manually connect to the isp_mso_received signal, but directly implement the _on_isp_mso_received() callback.
GIS Hub provides wrapper functions for all Godot InSim helper methods that send packets (send_message(), add_button(), etc.); helper methods that are only used to get data or otherwise don't result in sending packets have no wrapper, and should instead be accessed via the hub_insim variable available to all modules.
Virtual methods for modules include the following:
- _initialize_config(): Assign a custom module config class to your module.
- _initialize_module(): Assign a name to your module, and optionally perform initialization before adding the module to the scene.
- _ready_module(): Perform scene initialization, called when the module is first enabled.
- _load_config(): Define steps for loading module configuration (such as updating the module's GUI).
- _save_config(): Define steps for saving module configuration (such as updating values from the GUI). Call save_config() (no underscore) when you want to update the saved configuration.
- _on_insim_connected(): Called when InSim connects to LFS.
- _on_insim_disconnected(): Called when InSim disconnects from LFS.
- _on_module_enabled(): Called when the module is enabled. If InSim is connected, _on_insim_connected() will also be called.
- _on_module_disabled(): Called when the module is disabled. If InSim is connected, _on_insim_disconnected() will also be called.
- _on_module_sent_custom_data(): Called when a subscribed module sends custom data, that you can then handle here.
class_name MyFirstModule
extends GISModule
@onready var rich_text_label: RichTextLabel = %RichTextLabel
func _initialize_module() -> String:
return "My First Module"
func _on_insim_connected() -> void:
send_message("Hello GIS Hub!")
func _on_isp_mso_received(packet: InSimMSOPacket) -> void:
rich_text_label.append_text(
LFSText.convert_colors(packet.msg, LFSText.ColorType.BBCODE) + "\n"
)
Now for some "best practices", I would recommend the following:
- Naming: Name your module class "ModuleMyCustomModule", and your module config "ModuleMyCustomModuleConfig", to avoid naming conflicts. You can return whatever you want in _initialize_module(), but should likely stick to "My Custom Module".
- Typing: I strongly recommend that you use typed GDScript as much as possible, as this helps both with code autocompletion and catching errors. The GIS Hub project considers untyped variables as errors, and also errors on most "unsafe" GDScript warnings.
- Code order: You should ideally follow the official GDScript style guide as a general rule. For GISModule virtual methods, I suggest the following order: _initialize_config(), _initialize_module(), _ready_module(), remaining virtual methods (grouped by theme, such as _load_config() and _save_config(), or ordered alphabetically). After that, GISModule callbacks (so all _on_isp_xxx_received() methods) and remaining overridden methods, then public methods, then private methods.
- GIS Hub vs Godot InSim: Modules can access the hub_insim variable, which is the InSim instance handled by GIS Hub. You should only use it when you actually have to, and use methods provided by GIS Hub when possible. Feel free to report missing wrapper methods in GIS Hub if you find yourself using hub_insim too much or when you don't expect it. However, you can and should use other features provided by Godot InSim, such as LFSText for text handling, GISTime and GISUnit for converting data, etc.
- Module integration in the hub: Handle all InSim packets you need to provide a smooth integration in the hub; if your module displays an InSim button GUI to currently driving players, you want to make sure those buttons are removed when the player spectates or pits, or when the module is disabled, for instance. Keep your module's internal state as clean as possible, and provide options for InSim button placement. You should also make sure your code is not likely to crash the entire app, so you need to handle situations where you may try to access data from null objects, etc.
Last edited by Bokujishin, .
GIS Hub
The GIS Hub (or Godot InSim Hub) is, as its name implies, a hub application for Godot InSim. Its main goal is to provide a common interface for multiple Godot InSim apps to interface with LFS via a single InSim connection - which means you can have as many "apps" running as you want, sharing the same InSim connection, instead of being limited to the 8 connections LFS supports.
This allows the hub app to be the only "heavy" part, as a single Godot executable (and its ~80MB) is necessary here; all Godot InSim apps can instead be distributed as "modules", as small .pck files, and run directly in GIS Hub.
GIS Hub provides the following features:
These 2 modules are considered "core": they are included in the GIS Hub app, and cannot be disabled. You can however disable logging through the Log module's options.
All other modules, including those distributed with GIS Hub, can be enabled or disabled at any time. Adding a module is as simple as dropping a .pck file in the "modules" folder next to the GIS Hub executable.
Modules can write config and data in their dedicated folder, located in the "user://modules" directory, which corresponds to:
Downloads and documentation:
GIS Hub is not released yet, but will likely be soon after Godot InSim 3.0, which I plan to release shortly after Godot 4.5 is available. You can still download it from the GitLab repository and use it or create modules. Do keep in mind that it may still be unstable at this time, and requires a beta version of Godot 4.5 to work with the latest version of Godot InSim.
A documentation website for module developers is in the works; the public API is also documented inside the Godot editor, and you can read the source code of both core and other modules for reference.
Provided modules:
GIS Hub: [Core] This module provides the main interface for InSim settings and module management.
Log: [Core] This module displays all InSim packet traffic, including timestamps, packet direction (and the sender module if relevant), and a human-readable version of the packet contents (which may omit some data, depending on the packet type). It also creates a log file with the full data for all packets, and allows loading such files back into its GUI for easier reading.
Log options include color management for log files (none, ANSI, BBCode), whether to log files to screen and/or file, and whether to include NLP/MCI packets.
Teleporter: This module provides the "teleport" command to display a simple InSim button GUI allowing to choose a teleport destination. Such destinations can be included in a "track.txt" file according to the format in the provided examples, and files should be named according to the track they are intended for (e.g. "BL1.txt", "SO4R.txt"), or only the first 2 letters for open configs (e.g. "WE.txt" instead of "WE1X.txt").
The "teleport" command can be typed either as "/i teleport" or using the InSim connection's prefix ("!teleport", "@teleport", or any other prefix character).
Messager: This module provides a simple text entry GUI allowing you to type messages directly in UTF8, without having to go through the multiple LFS character pages. You can also easily change text color on the fly without having to retype text, and you can also mention someone using the list of connected players, just like you would in the game.
Do note that LFS has poor support for UTF8, despite the addition of code pages for multiple languages, so many characters are not supported and will produce garbage.
Additional planned features include saving shortcuts to custom messages and message history. Providing a virtual keyboard to show characters from some code pages, as you can see in LFS, is very unlikely to happen.
This allows the hub app to be the only "heavy" part, as a single Godot executable (and its ~80MB) is necessary here; all Godot InSim apps can instead be distributed as "modules", as small .pck files, and run directly in GIS Hub.
GIS Hub provides the following features:
- Manage a single InSim connection to use with any number of modules (practical limit is 50)
- Manage modules (discover on startup, hot enable/disable), with active modules arranged as tabs in the GUI
- Save and load module configuration, including InSim settings and enabled modules, and give access to a per-module data folder
- Route packets from LFS to all modules and the other way around
- Mirror Godot InSim functions for sending packets, managing InSim buttons, etc. at the module level (wrapper functions)
- Callback functions for all InSim packets, ISP_TINY/ISP_SMALL packet subtypes, and Relay packets
- Inter-module communication with the ability for a module to send arbitrary data, and subscribe to other modules to handle data they send
- Graphical interface for included modules (InSim settings and module manager, log module, etc.), and all modules can provide their own GUI
These 2 modules are considered "core": they are included in the GIS Hub app, and cannot be disabled. You can however disable logging through the Log module's options.
All other modules, including those distributed with GIS Hub, can be enabled or disabled at any time. Adding a module is as simple as dropping a .pck file in the "modules" folder next to the GIS Hub executable.
Modules can write config and data in their dedicated folder, located in the "user://modules" directory, which corresponds to:
- Windows: "%APPDATA%\Godot\app_userdata\GIS Hub\modules\<module name>"
- Linux: "~/.local/share/godot/app_userdata/GIS Hub/modules/<module name>"
Downloads and documentation:
GIS Hub is not released yet, but will likely be soon after Godot InSim 3.0, which I plan to release shortly after Godot 4.5 is available. You can still download it from the GitLab repository and use it or create modules. Do keep in mind that it may still be unstable at this time, and requires a beta version of Godot 4.5 to work with the latest version of Godot InSim.
A documentation website for module developers is in the works; the public API is also documented inside the Godot editor, and you can read the source code of both core and other modules for reference.
Provided modules:
GIS Hub: [Core] This module provides the main interface for InSim settings and module management.
Log: [Core] This module displays all InSim packet traffic, including timestamps, packet direction (and the sender module if relevant), and a human-readable version of the packet contents (which may omit some data, depending on the packet type). It also creates a log file with the full data for all packets, and allows loading such files back into its GUI for easier reading.
Log options include color management for log files (none, ANSI, BBCode), whether to log files to screen and/or file, and whether to include NLP/MCI packets.
Teleporter: This module provides the "teleport" command to display a simple InSim button GUI allowing to choose a teleport destination. Such destinations can be included in a "track.txt" file according to the format in the provided examples, and files should be named according to the track they are intended for (e.g. "BL1.txt", "SO4R.txt"), or only the first 2 letters for open configs (e.g. "WE.txt" instead of "WE1X.txt").
The "teleport" command can be typed either as "/i teleport" or using the InSim connection's prefix ("!teleport", "@teleport", or any other prefix character).
Messager: This module provides a simple text entry GUI allowing you to type messages directly in UTF8, without having to go through the multiple LFS character pages. You can also easily change text color on the fly without having to retype text, and you can also mention someone using the list of connected players, just like you would in the game.
Do note that LFS has poor support for UTF8, despite the addition of code pages for multiple languages, so many characters are not supported and will produce garbage.
Additional planned features include saving shortcuts to custom messages and message history. Providing a virtual keyboard to show characters from some code pages, as you can see in LFS, is very unlikely to happen.
Last edited by Bokujishin, .
Add an InSim packet for vehicle dimensions and wheel positions
As far as I know, there are currently 2 ways to retrieve information about a vehicle's dimensions:
Since the origin of a vehicle varies from vehicle to vehicle, it would be really useful if a new packet could be added to retrieve this data, which could be cached after being computed (if needed) when a player/AI leaves the pits, so it can be retrieved easily.
Assuming the vehicle origin is what the IS_MCI packet gives us, I propose the following format:
Total length/width/height represents the dimensions of the vehicle's bounding box, which could be based either on LOD1 or LOD3 (LOD3 makes sense on the physics side, but may be a bit rough, especially for some mods that have a bad LOD3).
Offset is measured from the vehicle origin to the center of the bounding box.
This packet would help generalize access to vehicle dimensions and wheel positions, without having to manually create a CAR_info.bin file (which assumes knowing what vehicles will be in the race/session), and can also help with the new AI control packets, as it gives us a way to measure distance to other vehicles, as well as determine where our own vehicle's wheels are.
Wheel damage would be either ignored entirely, or the wheel positions could be updated shortly after a car takes damage.
This packet could be requested by sending a corresponding SMALL_DIM packet with the PLID.
- Pressing O in the garage to generate the corresponding CAR_info.bin file
- For mods, directly reading the mod file (which requires decoding it)
Since the origin of a vehicle varies from vehicle to vehicle, it would be really useful if a new packet could be added to retrieve this data, which could be cached after being computed (if needed) when a player/AI leaves the pits, so it can be retrieved easily.
Assuming the vehicle origin is what the IS_MCI packet gives us, I propose the following format:
struct IS_DIM // vehicle DIMensions
{
byte Size; // 76
byte Type; // ISP_DIM
byte ReqI; // 0
byte PLID; // player's unique ID
float Length; // total length in metres
float Width; // total width in metres
float Height; // total height in metres
Vec/tor Offset; // offset from vehicle origin to box centre, local space (ints or floats in metres)
Vec/tor Wheels[4] // Offset to each contact patch center, local space (ints or floats in metres)
}Total length/width/height represents the dimensions of the vehicle's bounding box, which could be based either on LOD1 or LOD3 (LOD3 makes sense on the physics side, but may be a bit rough, especially for some mods that have a bad LOD3).
Offset is measured from the vehicle origin to the center of the bounding box.
This packet would help generalize access to vehicle dimensions and wheel positions, without having to manually create a CAR_info.bin file (which assumes knowing what vehicles will be in the race/session), and can also help with the new AI control packets, as it gives us a way to measure distance to other vehicles, as well as determine where our own vehicle's wheels are.
Wheel damage would be either ignored entirely, or the wheel positions could be updated shortly after a car takes damage.
This packet could be requested by sending a corresponding SMALL_DIM packet with the PLID.
Last edited by Bokujishin, .
While I believe using the starter shouldn't be difficult to add, clutch is probably more of an issue, as we need to consider why the AI cooked it in the first place; in my experience, this mainly happens if they get stuck for some time, e.g. after a crash or spin, and they struggle to move again (or try to go forward, then reverse, multiple times, especially with some cars).
I think there's a bigger underlying problem here: AI is at its best when it's driving along its line, and is not really good at doing anything off line (at least now it's able to go 2-wide into corners), and also does very little to avoid obstacles on its path at low speeds (if you don't move from the front of the grid at race start, chances are you will have a train of AI cars "stuck" behind you). Its starting behavior is also quite clearly flawed as it is likely based on a timer of some sort to determine when to abort driving away and try to reverse instead, thereby putting stress on the clutch.
Also, I believe Scawen said he wouldn't really touch the AI code again until the new tyre physics are done, which makes sense when trying to get them to drive close to the limit, but not as much sense from a purely behavioral perspective; ultimately, we don't know how AI decision making and navigational behavior is done, we can only guess some parts (such as the racing line likely being followed by a PID controller, with a separate line for the pitlane, given the sometimes rough transition between the 2).
I think there's a bigger underlying problem here: AI is at its best when it's driving along its line, and is not really good at doing anything off line (at least now it's able to go 2-wide into corners), and also does very little to avoid obstacles on its path at low speeds (if you don't move from the front of the grid at race start, chances are you will have a train of AI cars "stuck" behind you). Its starting behavior is also quite clearly flawed as it is likely based on a timer of some sort to determine when to abort driving away and try to reverse instead, thereby putting stress on the clutch.
Also, I believe Scawen said he wouldn't really touch the AI code again until the new tyre physics are done, which makes sense when trying to get them to drive close to the limit, but not as much sense from a purely behavioral perspective; ultimately, we don't know how AI decision making and navigational behavior is done, we can only guess some parts (such as the racing line likely being followed by a PID controller, with a separate line for the pitlane, given the sometimes rough transition between the 2).
Some news about GIS Hub development: as it is based on Godot InSim, I am planning to release version 1.0 soon after Godot Insim 3.0, which itself has to wait until Godot 4.5 is out. In the meantime, I've been adding more core features, and the hub can now do the following:
Module developers have access to all Godot InSim features, with a few changes to adapt to modules, and have access to a number of virtual functions to implement module configuration or behavior on specific events.
Developers can clone the GIS Hub repository or download the source code, open it in Godot, and develop in their own module subfolder. Module export is as easy as modifying or duplicating the provided export template, selecting only resources in your module folder, and hitting the Export PCK button.
A big advantage of using GIS Hub modules instead of standalone Godot InSim apps is the export file size: by exporting only the .pck file, your app will typically be a few kB to a few MB at most, instead of a baseline of ~80 MB because of the Godot executable.
I'm also currently working on a dedicated website (similar to the one for Godot InSim), with documentation and guides for module development, including what I view as best practices. Another useful source of documentation is the source code of core modules and other optional modules included with GIS Hub.
- Manage a single InSim connection to use with any number of modules
- Manage modules (discover on startup, hot enable/disable), with active modules arranged as tabs in the GUI
- Save and load module configuration, including InSim settings and enabled modules, and give access to a per-module data folder
- Route packets from LFS to all modules and the other way around
- Mirror Godot InSim functions for sending packets, managing InSim buttons, etc. at the module level (wrapper functions)
- Callback functions for all packets and ISP_TINY/ISP_SMALL packet subtypes
- Inter-module communication with the ability for a module to send arbitrary data, and subscribe to other modules to handle data they send
- Graphical interface for included modules (InSim settings and module manager, log module, etc.), and all modules can provide their own GUI
Module developers have access to all Godot InSim features, with a few changes to adapt to modules, and have access to a number of virtual functions to implement module configuration or behavior on specific events.
Developers can clone the GIS Hub repository or download the source code, open it in Godot, and develop in their own module subfolder. Module export is as easy as modifying or duplicating the provided export template, selecting only resources in your module folder, and hitting the Export PCK button.
A big advantage of using GIS Hub modules instead of standalone Godot InSim apps is the export file size: by exporting only the .pck file, your app will typically be a few kB to a few MB at most, instead of a baseline of ~80 MB because of the Godot executable.
I'm also currently working on a dedicated website (similar to the one for Godot InSim), with documentation and guides for module development, including what I view as best practices. Another useful source of documentation is the source code of core modules and other optional modules included with GIS Hub.
A big thank you to Flame CZE for his help with the interior textures: he brought the dashboard to life (and adjusted the vents too), and textured the center panel (carbon part with the switches); I took this opportunity to get going with some more textures (reusing the dashboard texture for the seat, steering wheel, and foam blocks), and added labels/logos to various parts of the dashboard (AC controls, the blue knob thingy (radiator cooler), wheel and center panel button labels.
See attached screenshots for a before/after comparison.
See attached screenshots for a before/after comparison.
Last edited by Bokujishin, .
Yes it does - the Karobus (106198) reports category 12, and the Prototype 2 (8A8457) reports category 13.
An offset with each successive teleport may or may not work, as it all depends on whether a car has moved after teleporting: if you allow 5 offset locations, 5 people teleport but don't move, you have the same issue for the 6th teleport (but less likely, of course); a better solution for this would be to check whether a vehicle is within a safe distance of the teleport target, and prevent teleport until the area is clear, which should be doable with an InSim circle and the IS_UCO packet.
(but of course, if you expect multiple people to teleport to the same location in a short time, you may still need multiple target locations close to one another)
Also, instead of storing locations in code, you should consider reading a text file containing those locations instead, so you don't have to modify the code every time you want to add, remove, or change a target.
As for AI coding, do keep in mind that you should not just trust the code AI gives you: you should be able to understand it, so you can find issues that will inevitably arise (code not actually following your prompt, or using the wanted API in a wrong way or based on outdated "knowledge"); therefore you should probably learn the Lapper API, or at least the features the code uses.
But to try and answer your question: create an array of variables tracking the current count of teleports to each location, increment the variable each time a vehicle is teleported to the corresponding target, and reset when it goes over 5; then use that variable for the teleport itself, and add the offset multiplied by the 2-3 meters you want to the coordinate you want to offset. You may also want to use the teleport target's heading to automatically offset both X and Y with cos/sin, so that cars spawn next to each other.
(but of course, if you expect multiple people to teleport to the same location in a short time, you may still need multiple target locations close to one another)
Also, instead of storing locations in code, you should consider reading a text file containing those locations instead, so you don't have to modify the code every time you want to add, remove, or change a target.
As for AI coding, do keep in mind that you should not just trust the code AI gives you: you should be able to understand it, so you can find issues that will inevitably arise (code not actually following your prompt, or using the wanted API in a wrong way or based on outdated "knowledge"); therefore you should probably learn the Lapper API, or at least the features the code uses.
But to try and answer your question: create an array of variables tracking the current count of teleports to each location, increment the variable each time a vehicle is teleported to the corresponding target, and reset when it goes over 5; then use that variable for the teleport itself, and add the offset multiplied by the 2-3 meters you want to the coordinate you want to offset. You may also want to use the teleport target's heading to automatically offset both X and Y with cos/sin, so that cars spawn next to each other.
I do plan to make the stock version at some point, yes, but I can't say when that will happen as I'm busy with other projects. Here is the current state of the car (only the dashboard and a tiny bit of the center panel are done for the interior).
Of course, but I think what I said is still technically correct: the transponders give you a single car's timing, but not its position (position is only accurate if all cars have their transponder at the same distance from the front-most point). So for close finishes, you need to check photo-finish style instead of transponder style. I guess you could define a close finish as any sub-0.5s finish or when there is any kind of overlap between 2 cars.
FIA regulations vary from series to series, but they always include some tolerance (for LMGT3, which has one of the most varied car shapes in its category, the front transponder must be located 1800mm +/-500m from the front of the car, so you can have up to a full meter between 2 cars).
Interesting to see BTCC uses the entire bodywork for starting position; F1 in general is not the best series to represent motorsport, with all their specific rules that basically nobody else uses, however FIA does use the contact patch for the starting position for all series, and it seems common sense to use bodywork for photo finishes. I had a quick look at IMSA regulations, which also state that a car crosses the finish line when its timing device triggers, "and more precisely, at the instant the leading-most edge of its bodywork passes over that line (photo finish)".
Those transponders also seem to be what dictates when a car enters or leaves the pit lane.
Computation wise, it's quite common to have mesh dimensions for all objects in the world, because of culling optimizations; you only need to get those dimensions once, and maybe update them after getting damage to the car, so it's not something you need to do every frame at all. Using LOD3 would not be recommended as it can be offset from LOD1 (plus some mods don't have proper LODs).
Good point about drag races and photos finishes in general, which may be complicated further with possible damage to the cars 
(but otherwise, I do believe that bodywork is used as reference for photo finishes).
I found the more generic FIA International Sporting Code, which states in article 8.6.1.a that "for a standing start, [an automobile] must be stationary at its allocated grid box with no part of the contact patch of its front tyres outside of the lines (front and sides) at the time of the Start signal", so this part is consistent across all series.
Going back to drag races, maybe specifically for Autocross drag races (and I believe there is a drag strip in the Fairfield Test Centre as well?), you could use the forward-most vertex position of the vehicle's LOD1? I don't know if you ever compute a bounding box for vehicles in the game, in any of the LODs, but I would assume you do for culling purposes?
In real life, I believe accurate timing is generally done with transponders, and only if you get identical times to the millisecond would you need to use a camera fast enough to determine who crossed the line first. The transponders, however, are not necessarily in the exact same location for all cars (there are multiple regulated locations for F1, the Clio Cup has its transponder next to the key on the steering column, but different cars in a same category may have various locations - the important part here is that the timing itself is consistent for a single car, whether you measure at the front, middle or back of the car, and only the finish gets impacted by the different locations).
(but otherwise, I do believe that bodywork is used as reference for photo finishes).I found the more generic FIA International Sporting Code, which states in article 8.6.1.a that "for a standing start, [an automobile] must be stationary at its allocated grid box with no part of the contact patch of its front tyres outside of the lines (front and sides) at the time of the Start signal", so this part is consistent across all series.
Going back to drag races, maybe specifically for Autocross drag races (and I believe there is a drag strip in the Fairfield Test Centre as well?), you could use the forward-most vertex position of the vehicle's LOD1? I don't know if you ever compute a bounding box for vehicles in the game, in any of the LODs, but I would assume you do for culling purposes?
In real life, I believe accurate timing is generally done with transponders, and only if you get identical times to the millisecond would you need to use a camera fast enough to determine who crossed the line first. The transponders, however, are not necessarily in the exact same location for all cars (there are multiple regulated locations for F1, the Clio Cup has its transponder next to the key on the steering column, but different cars in a same category may have various locations - the important part here is that the timing itself is consistent for a single car, whether you measure at the front, middle or back of the car, and only the finish gets impacted by the different locations).
From the FIA F1 sporting regulations, article 48.1.c (incorrect starting location): "Any part of the contact patch of its front tyres outside of the lines (front and sides) at the time of the Start signal."
The yellow line is only used as a reference (typically for F1 and other open wheelers), which is why it sits behind the white line, to allow some margin for error.
I would suggest placing the front tyres on top of the yellow line (and giving the layout start positions the same offset to the white line for consistency).
For what it's worth, I've been experimenting with an InSim GUI to guide drivers into their boxes after a formation lap, using IS_MCI packets for the spawn position as the target (which I have to adjust a bit to account for heading deviation and the fact the the CompCar position is not at the front tyres), and the principle works well enough to be useful, but I do have to adjust the forward offset depending on the track and layout (placing layout start positions hidden below the ground when there are proper grid boxes, which is often not the case, but I noticed in the screenshots of the updated tracks that more configurations will have 40 proper boxes).
Since I like to add new ideas to most of my suggestions (sorry about that), having the option to change the start position's look to the F1-style grid box would be great.
The yellow line is only used as a reference (typically for F1 and other open wheelers), which is why it sits behind the white line, to allow some margin for error.
I would suggest placing the front tyres on top of the yellow line (and giving the layout start positions the same offset to the white line for consistency).
For what it's worth, I've been experimenting with an InSim GUI to guide drivers into their boxes after a formation lap, using IS_MCI packets for the spawn position as the target (which I have to adjust a bit to account for heading deviation and the fact the the CompCar position is not at the front tyres), and the principle works well enough to be useful, but I do have to adjust the forward offset depending on the track and layout (placing layout start positions hidden below the ground when there are proper grid boxes, which is often not the case, but I noticed in the screenshots of the updated tracks that more configurations will have 40 proper boxes).
Since I like to add new ideas to most of my suggestions (sorry about that
), having the option to change the start position's look to the F1-style grid box would be great.Improve start position of vehicles
Currently, it is not entirely clear to me what logic is used to place vehicles on the grid; it looks like a vehicle's reference point is used, but making mods with ridiculous dimensions can also affect the position somewhat, so I'll keep it mostly to official cars here, with the same logic applying for all vehicles anyway.
Even within official cars, with the variety of vehicles, there are large discrepancies on the grid boxes: some cars have their front wheels close to the markings, some are further back, some are way beyond the line... and even with cars from the same class, like GTR, we have differences.
My suggestion to solve this is to use the front wheels of a vehicle to determine its position, which I believe should only be an offset along the forward vector of the vehicle, based on data available in the car_info.bin file (on the public side, I assume that data is readily available internally).
I'm not asking for a consistent match within 1cm for all cars, but if the front wheels could be somewhere on the yellow line of the F1-style grid boxes, that would be great
On that note, layout start positions do not have that yellow line (and, as an aside, they're also not as wide), but more importantly, they have a completely different offset to their visual markings, compared to Blackwood's markings.
In the second image, I even placed the grid box further back, aiming for the yellow line, and it still appears way forward of the official grid box - I think both the official and the layout grid boxes should use the white line as their reference point, or the yellow line (and equivalent distance for the layout grid box), instead of a generic size which clearly cannot fit all vehicles.
Even within official cars, with the variety of vehicles, there are large discrepancies on the grid boxes: some cars have their front wheels close to the markings, some are further back, some are way beyond the line... and even with cars from the same class, like GTR, we have differences.
My suggestion to solve this is to use the front wheels of a vehicle to determine its position, which I believe should only be an offset along the forward vector of the vehicle, based on data available in the car_info.bin file (on the public side, I assume that data is readily available internally).
I'm not asking for a consistent match within 1cm for all cars, but if the front wheels could be somewhere on the yellow line of the F1-style grid boxes, that would be great
On that note, layout start positions do not have that yellow line (and, as an aside, they're also not as wide), but more importantly, they have a completely different offset to their visual markings, compared to Blackwood's markings.
In the second image, I even placed the grid box further back, aiming for the yellow line, and it still appears way forward of the official grid box - I think both the official and the layout grid boxes should use the white line as their reference point, or the yellow line (and equivalent distance for the layout grid box), instead of a generic size which clearly cannot fit all vehicles.
I've been working on a website to include the class reference documentation, guides/tutorials, and the demos as well. Feel free to have a read if you're interested; I recommend the Getting started with InSim tutorial if you want to have a first look at how to use GodotInSim.
Do note however that the documentation is for the very latest state of the project, which I plan to release as version 3.0 - this is not released yet, and will probably come soon after Godot 4.5 is released, as I make use of a feature that was added in 4.5.
Do note however that the documentation is for the very latest state of the project, which I plan to release as version 3.0 - this is not released yet, and will probably come soon after Godot 4.5 is released, as I make use of a feature that was added in 4.5.
InSim and OutGauge additions to existing packets
While I'm working to improve Godot InSim and thinking about current and future projects, I find myself wanting to add a few things in current packets, namely IS_MCI (or rather the contained CompCar) and OutGaugePacket:
I would like CompCar to include pitch and roll, in addition to heading, for 2 reasons: it would allow detecting upside-down cars (or cars on their side, face-planted, whatever), and it would allow a faithful 3D representation of all vehicles in space, instead of the current XYZ position + heading only, which means we cannot know if cars are following the bankings or slopes of the track. This could also help for automating track limits detection, since we need complete car orientation to accurately determine where the wheels are, and IS_MCI is the go-to packet to fetch data about every car.
For OutGauge, I would like to see the steering input added, with the actual steering wheel angle, not the angle at the front wheels (which is what OutSim gives us). The reasoning for this is to allow showing a virtual steering wheel as an overlay, but could also be used as telemetry in addition to OutSim (knowing how much each wheel is turning is good data, but so is the steering wheel input itself).
Additionally, for consistence, I think OutGauge should also include handbrake input - this may be redundant with OutSim, but since the 2 do not work in the same conditions, and we already have throttle, brake and clutch in OutGauge, I think it would make sense to include it.
There is currently no spare room in the CompCar struct, so adding a short for both pitch and roll would bring its size from 28 bytes to 32 bytes; my proposed additions to OutGauge would add a float for each value, bringing the total size from 96 to 104 bytes (including the optional ID).
I would like CompCar to include pitch and roll, in addition to heading, for 2 reasons: it would allow detecting upside-down cars (or cars on their side, face-planted, whatever), and it would allow a faithful 3D representation of all vehicles in space, instead of the current XYZ position + heading only, which means we cannot know if cars are following the bankings or slopes of the track. This could also help for automating track limits detection, since we need complete car orientation to accurately determine where the wheels are, and IS_MCI is the go-to packet to fetch data about every car.
For OutGauge, I would like to see the steering input added, with the actual steering wheel angle, not the angle at the front wheels (which is what OutSim gives us). The reasoning for this is to allow showing a virtual steering wheel as an overlay, but could also be used as telemetry in addition to OutSim (knowing how much each wheel is turning is good data, but so is the steering wheel input itself).
Additionally, for consistence, I think OutGauge should also include handbrake input - this may be redundant with OutSim, but since the 2 do not work in the same conditions, and we already have throttle, brake and clutch in OutGauge, I think it would make sense to include it.
There is currently no spare room in the CompCar struct, so adding a short for both pitch and roll would bring its size from 28 bytes to 32 bytes; my proposed additions to OutGauge would add a float for each value, bringing the total size from 96 to 104 bytes (including the optional ID).
If your non-InSim version involves reading game memory or some kind of image detection (or anything external to the normal use of the game), then yes it would be considered a cheat (even some InSim usage can also be considered cheating, depending on the situation). From InSim though, it is perfectly possible to do (within the limits stated before, that is having at least one other car that does start on the green light, and accepting that your forgot-to-shift-up customers will start after said car(s)), you can have a variable set on race start (using the IS_RST packet), which allows you to disable the auto-shift once it has triggered.
Well, I would say AI are pretty reliable when it comes to starting driving at the green lights so my point still stands - and it actually removes the risk of a single player jump-starting and causing everyone else to do so as well (which could actually be avoided by checking for 2 or 3 cars instead of a single one).
so my point still stands - and it actually removes the risk of a single player jump-starting and causing everyone else to do so as well (which could actually be avoided by checking for 2 or 3 cars instead of a single one).If there are other cars in the race that you know will actually start, you can use InSim's IS_CSC packet, which is sent when a car starts moving; you could then have your app send the command to shift up with either /press or using the IS_SCH packet to send the key corresponding to shift up (but you should check they are in neutral before doing that, which you can do using OutGauge or OutSim).
This assumes your customers are actually pressing the right pedal at least, even if they forget to shift up with this at least, they would start moving shortly after any car does - which means someone who jump starts will cause everyone else to do so as well, if they're not holding the clutch.
This assumes your customers are actually pressing the right pedal at least, even if they forget to shift up
with this at least, they would start moving shortly after any car does - which means someone who jump starts will cause everyone else to do so as well, if they're not holding the clutch.I've never had an issue with wheels there either, but your question reminds me of something (this is regarding tyre physics, sorry for derailing a bit): I assume this is related to raycasting possibly finding a gap between the physical objects, which could cause a wheel to sink into the ground (as happens in some other places, or sometimes between 2 concrete objects) - is the future tyre physics (not the retro model for the coming update) also based on what seems to be a single raycast, despite the contact patch simulation?
It would be really nice to see an improvement in this area, and maybe allowing for a secondary contact patch (for wheel to wheel contact for instance, or hopefully better kerb physics, as right now, the wheel will jump up or down a kerb (or tramway rail in SO) with no impact on the car's speed. The one situation where the contact patch shifts is with the speed humps, but you can see the contact patch jump instantly from vertical to ~30 degrees). Hopefully this is something that can become possible down the road, with the multithreading helping performance.
It would be really nice to see an improvement in this area, and maybe allowing for a secondary contact patch (for wheel to wheel contact for instance, or hopefully better kerb physics, as right now, the wheel will jump up or down a kerb (or tramway rail in SO) with no impact on the car's speed. The one situation where the contact patch shifts is with the speed humps, but you can see the contact patch jump instantly from vertical to ~30 degrees). Hopefully this is something that can become possible down the road, with the multithreading helping performance.
I have a very simple way to reproduce this, as this happens in many locations in Layout Square, typically along the seams of all road components (the road itself, cobblestones, etc.); there are actually several thousands of such invalid locations.
I'll edit this post in a few minutes with some examples and ranges of coordinates. Note that, of course, placing objects at those invalid locations, but "floating" does work (but you have to place them slightly off before as "floating" is off when placing objects).
Edit with some examples:
Any point at X=-4.75 and Y above -980 and up to -20 inclusive.
Any point at X=-4.75 and Y above 20 and up to 500 inclusive (this one is only invalid halfway along the road).
Same Y coordinates but X=+/-8.00, +/-6.75, +/-6.5, +/-4.5, +/-2.25, 0.00.
The same occurs along all 4 roads around the (0, 0) point, and probably on most roads.
I'll edit this post in a few minutes with some examples and ranges of coordinates. Note that, of course, placing objects at those invalid locations, but "floating" does work (but you have to place them slightly off before as "floating" is off when placing objects).
Edit with some examples:
Any point at X=-4.75 and Y above -980 and up to -20 inclusive.
Any point at X=-4.75 and Y above 20 and up to 500 inclusive (this one is only invalid halfway along the road).
Same Y coordinates but X=+/-8.00, +/-6.75, +/-6.5, +/-4.5, +/-2.25, 0.00.
The same occurs along all 4 roads around the (0, 0) point, and probably on most roads.
Last edited by Bokujishin, .
You can be certain someone will quickly find a way to look at the file with a hex editor to compare a locked/non-locked version of the same mod to know how this works, unfortunately such security is weak at best. In a way however, it reminds me of concerns about code reverse-engineering: people typically want their source code to be obfuscated in their release binaries, so people cannot (easily) just grab the code and do whatever with it (this is a topic that comes about here and there in the Godot community for instance) - the goal of encryption/obfuscation is not to make it bulletproof, but rather to deter "script kiddies" from having easy access, leaving only the more experimented and willing to invest time to worry about.
In general, having some security is better than none, especially in a legal setting, so you can say "my resource was protected and they stole it" - and in that sense, allowing OBJ export nulls that argument, because any mod can be loaded into the editor.
But then again, having the ability to export to OBJ would be useful, so it's a difficult topic
In general, having some security is better than none, especially in a legal setting, so you can say "my resource was protected and they stole it" - and in that sense, allowing OBJ export nulls that argument, because any mod can be loaded into the editor.
But then again, having the ability to export to OBJ would be useful, so it's a difficult topic
The fact that the current PID is nicely tune (I do agree it is) is actually what I was thinking has room for improvement: as you said, the set speed is reached quite quickly - too quickly for smooth driving actually, especially in braking - and controlling acceleration instead of speed directly would allow for more flexible driving. Of course, changing the current coefficients depending on the situation might also work, but has more room for mistuning.
My suggestion was based off my experience working on a drone simulator a few years ago, which has stabilized flight modes, one of which allows controlling speed directly: by moving the stick, you control forward/lateral speed, with their own PIDs, which then gets fed to the angular speed PIDs, which then feed into the pitch and roll PIDs.
My suggestion was based off my experience working on a drone simulator a few years ago, which has stabilized flight modes, one of which allows controlling speed directly: by moving the stick, you control forward/lateral speed, with their own PIDs, which then gets fed to the angular speed PIDs, which then feed into the pitch and roll PIDs.
I like the creative use of objects in the layout to overcome some of the current limitations especially distance markers for the bus stops; hopefully the big update will help in this regard.
As we discussed already for the PID, I think you could improve it by feeding the output of the speed PID to a throttle PID and a brake PID to allow smoother braking, but this is already looking pretty good. And then maybe state machine/behavior tree and things like that to control the overall behavior of the AI? Definitely a big project
especially distance markers for the bus stops; hopefully the big update will help in this regard.As we discussed already for the PID, I think you could improve it by feeding the output of the speed PID to a throttle PID and a brake PID to allow smoother braking, but this is already looking pretty good. And then maybe state machine/behavior tree and things like that to control the overall behavior of the AI? Definitely a big project
I added some demos to GodotInSim, so people can see how to use it (and Godot in general, as many of those demos also use Godot's UI system or rendering capabilities):
The demos are available on the GitLab repository (I migrated the repo from GitHub).
- Live Telemetry
- Traffic Lights
- Teleporter
- Layout Viewer
- InSim Packet Logging
- PTH Viewer
The demos are available on the GitLab repository (I migrated the repo from GitHub).
I cleaned up my PTH and SMX parsers, took this opportunity to create an SMX file for Layout Square (still WIP, I have the 4x4 km area but the ends are not 1:1 with LFS), and GodotInSim now has camera utility functions to convert a camera from Godot to LFS and the other way around; it's easy then to synchronize a camera between the two, and since this allows me to overlay Godot on top of LFS, I went ahead and modeled the layout editor objects (procedurally, because why not...).
All objects now have a 3D mesh in GodotInSim (except marshals), and you can easily have it load an SMX environment, load a layout, and synchronize the layout's state with LFS. This also enables editing a layout directly from GodotInSim, but there are currently no editor-like tools for that (whether I make some remains to be determined).
Also, one obvious caveat: some SMX files are outdated (Blackwood, especially the car park and industrial area) or missing entirely (Rockingham, and Layout Square for which I made my own replacement). It is also quite likely that South City and Kyoto will become outdated when their overhauled versions are released.
As a bonus related to my Layout Square SMX, I now have a working GLTF to SMX converter included (which, granted is quite limited in purpose, but if someone were to update Blackwood or create a mesh for Rockingham...).
All objects now have a 3D mesh in GodotInSim (except marshals), and you can easily have it load an SMX environment, load a layout, and synchronize the layout's state with LFS. This also enables editing a layout directly from GodotInSim, but there are currently no editor-like tools for that (whether I make some remains to be determined).
Also, one obvious caveat: some SMX files are outdated (Blackwood, especially the car park and industrial area) or missing entirely (Rockingham, and Layout Square for which I made my own replacement). It is also quite likely that South City and Kyoto will become outdated when their overhauled versions are released.
As a bonus related to my Layout Square SMX, I now have a working GLTF to SMX converter included (which, granted is quite limited in purpose, but if someone were to update Blackwood or create a mesh for Rockingham...).
Last edited by Bokujishin, .
FGED GREDG RDFGDR GSFDG