Just for reference, as a real example, here's a diagram for the Monza circuit (from 2019):
https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Ftcn3vcy35nk31.jpg

You can spot those LED panels in the F1 pole lap video from last year:
https://www.youtube.com/watch?v=pr1kXumP3dk

From a very rough measurement, there's about 500m between panels 14 and 15 just before T11; on the other hand, panels 11 and 12 are only separated by about 150-180m.

This video also helps to spot the panels (2022):


Also, the LED panels don't actually stay on, they are either off or blinking (or displaying one of the other symbols/messages), every flag blinks at 2Hz, including the double yellows, which is the only flag using the diagonal/triangle shape.

Quote from Scawen :

Does anyone have any good information about how frequently the LED boards should be placed around the track?

This is from the FIM rather than the FIA, but the wording is similar to what I've seen in a few videos on this matter. In section 9.2, the general idea is that LED panels delimit each marshalling sector (with one panel at the start of each sector), the maximum distance between panels is 250m, and each sector should have line of sight to the previous and next sectors.

For some more details about the panels themselves, I found this FIA document, with Appendix 2 showing the standard messages in addition to the flags (but solid colors and "double-yellows" should be enough, with the standard flashing frequency being 2Hz rather than 1Hz as I suggested before).

Edit: Oh and to keep up with my usual "let's ask for one more thing" habit: if/when you do add the ability to control the LED panels, having them available as layout objects would be great (they're much more visible than standard lights, especially since relatively small light sources are a common problem in games, where they're barely or not visible at all despite being extremely bright, because of their sub-pixel size or when they cover few pixels, like tail lights and stop lights do already, since I doubt the graphics update will solve this despite the reworked emissive materials).

Last edited by Bokujishin, Wed 23 Jul 2025, 16:09.

We all know that text encoding in LFS is a bit peculiar, as it relies on the very old CP1252 code pages system from the 90s. Scawen himself is aware of this, and has said a few times (even back then in ~2005) that Unicode would probably be the way to go to support more languages. Now in 2025, LFS is still using code pages, and has even expanded their use to support more languages, such as Chinese, Japanese, and Korean, among others. I believe this happened because it was the easiest way to add support for those languages at the time; while Unicode should be the better solution, implementing it may require an enormous amount of work, and there are definitely other priorities right now.

Still, those code pages bring a few issues with them:

• Limited language support, as only the available code pages are supported, and I doubt there even exist enough code pages to support most languages.
  
• Limited character support: I don't think supporting emoji is a goal here, but there are still many unsupported Unicode characters (basically anything not in the code pages).
  
• InSim libraries have to implement a UTF-8 to LFS (and LFS to UTF-8) conversion, as the entire world uses Unicode today ("As of July 2025, UTF-8 is used by 98.7% of surveyed web sites.").
  
• For LFS itself, while they still work, they do represent a huge technical debt, where using UTF-8 should make things easier, but changing code pages to UTF-8 is becoming more and more difficult and time consuming.
  

From reading some older forum posts, I gathered that LFS implements its own font system, because at the time, it was difficult to find free fonts that supported enough characters - this should be a non-issue today, with fonts such as the Noto family supporting a vast amount of characters (possibly through the many Noto fonts dedicated to specific languages), and the general availability of free or even open-source fonts.

-----

Anyway, this is not another "please add Unicode support" thread (although I do want to see Unicode support ), I just made this thread as a recap of sorts of the current situation, and to add an interesting issue I found just yesterday while experimenting with InSim buttons to try and draw road signs.

Take a speed limit sign for example (Europe style): the sign is circular, with a white background, a red border, and black text stating the speed limit. We should be able to draw such a sign using 3 IS_BTN packets. LFS even supports the characters we want to use for that: ● for the background, ○ for the border, and digits for the text (for better control over border thickness, and due to general quality of large text rendering, I ended up using ● for the border as well, resizing the button appropriately). My understanding of InSim button z-order, through earlier testing, has been that buttons with a lower clickID are rendered first, and therefore buttons with a higher clickID appear on top. This is generally true... but not always!

Trying to render my speed limit sign, the text is nowhere to be seen, but if I add more text so it spills out of the sign, I can see it being rendered behind the sign, despite having a higher clickID (in the above example, the text reads "505050"). It would appear that characters from different code pages do not follow the clickID z-order, which becomes a headache when dealing with buttons. (for the record, in the above example, the border button has ID 0, the background button has ID 1, and the text button has ID 2)

Even better, this also applies to characters in a single button: in the following example, I created 2 buttons, same position, same size, with texts "^0●a" and "^7b", and here's what the result looks like:

We only have 2 buttons here, but the "b" character appears both in front and behind characters from the other button, simply because they're from different code pages!

It would be nice to get more info about the rendering logic, or whether this can be fixed for consistency, as it unfortunately makes it impossible to draw those signs, or any other kind of button combination that would rely on characters from different code pages (in this example, ● is converted to a Japanese code page character as [94, 74, 129, 156]).

Quote from Scawen :

I think they should be individually or globally controllable by setting a specific colour or two flashing colours via InSim and using an ID number in some InSim packet.

I guess a global usage would be good, to set all with one packet (e.g, red flag?) but individual would be useful too (blue, yellow flags?).

I'm guessing at this point that monochrome colour for the whole board is enough as it would be much easier to implement than any patterns/

I think this could work with an identifier specific to lights/LED boards, 241 or something, with identifier 255 used to control all of them, and 0 to some value to control individual ones - which controls which one can be subject to some debate, as it could be numbers along the layout (but that could depend on the layout itself), or fixed numbers that we would need to list manually to get the proper lights/boards for our current layout.

As for the monochrome vs 2-color boards, I suppose the current way those are made corresponds to a single light bulb, and as such they're monochrome - switching to 2 separate textures/emissive textures (don't know what you're using, both currently and in your dev version) separated diagonally would work akin to 2 light bulbs and could be very nice to have, but probably not the priority.

I would even say that, in my opinion, being able to set lights to a flashing state would be more important, but I'll let others give their opinions about that.

Quote from kristofferandersen :

I'm thinking this is related to network latency, as i haven't ran into this issue at all with my timers/states. As you already said, it'll immidiately revert due to the new packet arriving.

If that's network latency, I would expect InSim buttons (sent just after the corresponding IS_OCO packets) to also have some kind of issue, but they're mostly perfect there, so it's very likely there's something specific to lights or IS_OCO packets.

I would make a small video clip showing the issue, but I won't have access to my actual PC for a few days, so I'll try to do that later this week. I'll also take this opportunity to check whether layout lights have the same issue.

Penalties are currently limited to drive-through, 10s stop-and-go, 30s, and 45s. I think it would be desirable to be able to set lower time penalties, typically 5s and 10s, and allow them to stack.
It would also be nice if the duration of the stop and go could be adjusted, although I think this is less of a priority.

Additionally, having the ability to send IS_PEN packets would be really useful: right now, the only way to apply penalties is through the /p_dt, /p_sg, /p_30, and /p_45 commands; if instead we could send IS_PEN packets, we could not only choose the penalty type (and duration if custom times are added), but also set a penalty reason ("given by admin" being the only reason given for the /p_* commands), so we could have penalties given for speeding, and explicitly stating it as such.

Some other packets are already including the current penalty for a driver, such as IS_LAP, IS_SPX, IS_PIT; IS_RES also includes the penalty, which could then be the total penalty time obtained throughout the race. Sending IS_PEN packets could also be used to reapply penalties to a driver pitting or losing connection and rejoining.

On the technical side of things, ReqI could be used in IS_PEN to either set a penalty, or request a driver's current penalty (or maybe add a SMALL_PEN for that purpose). When a penalty is applied, InSim would send a reply IS_PEN just like it does already for penalties applied by the game.

OldPen would likely be zero, while NewPen would be the penalty to apply, and the Reason could also be set.
If NewPen can only have a limited amount of predefined values, I would suggest adding PENALTY_TIME, so we could set the penalty time in the current spare Sp3 byte. Maybe also PENALTY_REMOVE_TIME to remove a time penalty, as we would want to be able to handle that too, and have time penalties and DT/SG penalties at the same time.

Confirmation flags could add a new, generic CONF_PENALTY or CONF_PENALTY_TIME value, instead of (or in addition to) the current 30 and 45 seconds.

As a side note, time penalties are already implemented in some capacity, as hitting an object on an autocross layout adds a 2-second penalty, although autocross is a bit of a special case.

To my knowledge, there are currently 2 issues with IS_OCO packets and lights in general:

• Response timing to IS_OCO packets is erratic at best (sometimes the lights switch almost immediately, sometimes you have to wait much longer, to the point that flashing lights (changing state every 0.5s) may keep the commanded light on or off for more than a full second (likely because it does change state at some point, but immediately reverts because of the new packet)).
  
• We don't have enough working and controllable lights (pit entry/exit, track-side lights (or LED panels for Blackwood).
  

The first issue forces InSim developers to use "backup lights" for custom starts (which isn't too bad in itself, as having GUI/HUD lights is generally a good idea), because the real lights typically change state late and are not reliable for reaction time (I won't get into 5-red-lights style start lights here, although having those on all tracks would be good as well). The issue is easily noticeable when sending a message right after sending the IS_OCO packet.

The second issue, which hopefully is planned to be addressed in the future (the lights are there after all, so we could have them accessible to InSim with index values other than 240, or identifier values for index 240) would really help to make the track more alive (having green lights/LED panels during a safety car period feels wrong, after all, and being able to use the blue lights at pit exit (or a layout object with a blue light) would also help).

Now for the proposed changes:

• If possible, having lights react more quickly to IS_OCO packets would be appreciated, as I don't really understand why they wouldn't be updated as soon as the packets are received. By the way, the issue is only visible with host InSim apps, in local apps, the changes are immediate.
  
• Whether the above can be addressed or not, it would be nice to be able to set lights to a flashing state, so we don't have to repeatedly send on/off IS_OCO packets (a period of 1s (0.5s between state changes)) should work for most scenarios.
  
• Valid index values are currently 149 (with 150 and 151 already reserved for new layout objects) and 240; just like layout objects have 64 identifier values, having some of those for track-side lights seems like a good option for controlling them.
  

As an additional note to that last point, maybe more lights could be added on official tracks; I checked around Westhill, the National configuration has 2 of those, and International has 4. I don't know how those lights are supposed to be placed in real life, but there is no light at all between the point both configurations converge and the main lights at the finish line, I feel there should be at the very least one.

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:

• _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.
  

The following is a very basic module example, which sends a message upon InSim connecting (or enabling the module if InSim is already connected), and logs incoming messages to the screen, using a RichTextLabel:

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.
  

And finally, on the distribution and security side, I would recommend providing the source code on a public repository (GitHub, GitLab, etc.), and if possible distribute PCK files generated via CI, to ensure they are consistent with the source code. I will strive to do the same for GIS Hub itself and all modules I create.

Last edited by Bokujishin, Fri 11 Jul 2025, 07:24.

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:

• 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
  

For instance, the GIS Hub tab is itself a module, although it doesn't do much on the InSim side. The Log module, however, provides a visual display of all packet traffic, and includes the name of the module when a packet is sent (or defaults to "InSim" if Godot InSim sent the packet automatically).
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>"
  

As an example, the Teleporter module allows configuring the position of its InSim button interface, and saves it to its data folder (and will read it when enabled, of course). It also reads saved teleport destinations in txt files in the "spawn" subfolder, which means you can easily modify destinations without exiting the app, and even update the destinations for the current track by simply disabling and re-enabling the module (as destinations are updated when the track changes or the module is enabled).


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, Thu 31 Jul 2025, 18:03. Reason : Updated GitLab link

As far as I know, there are currently 2 ways to retrieve information about a vehicle's dimensions:

• Pressing O in the garage to generate the corresponding CAR_info.bin file
  
• For mods, directly reading the mod file (which requires decoding it)
  

However, the first point only gives us contact patch position (which is good), and the second one is clearly not intended to begin with, and doesn't work with official vehicles.

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.

Last edited by Bokujishin, Tue 8 Jul 2025, 05:28.

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).

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:

• 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
  

GIS Hub users just need to download the modules they want to use (in .pck format), put them in the modules folder, launch GIS Hub and enable the modules.

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.

Last edited by Bokujishin, Fri 20 Jun 2025, 17:58.

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.

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).

Quote from Flame CZE :

Well "only" the finish is quite important for close finishes. It would be unfair if a car would lose a race just because its virtual transponder was placed further back than for the others

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).

Quote from Racon :

F1 uses wheels for the grid position and bodywork for the splits/finish? If anyone was gonna do it, it would be F1 I guess - I've seen their idea of what constitutes overtaking

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).

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.

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.

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.

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).

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).

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.

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.