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.

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.

Last edited by Bokujishin, Thu 1 May 2025, 17:42.

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

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.

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

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

• Live Telemetry
  
• Traffic Lights
  
• Teleporter
  
• Layout Viewer
  
• InSim Packet Logging
  
• PTH Viewer
  

I will probably add at least an InSimRelay demo later, but other than that it should give a pretty good overview.
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...).

Last edited by Bokujishin, Mon 14 Apr 2025, 07:28.

Some of those commands are either already available, or the same effect can be obtained through the GUI:

• Penalties like drive-through can be applied to AI and players alike: /p_dt AI 1, /p_30 AI 1, etc.
  
• Instead of the proposed /dnf to spectate an AI, you can use /spec.
  
• Pit strategy: we cannot force an AI to pit, but we can adjust its pits settings by switching view to that AI, and modifying values in the F12 pit instructions (I don't think the /pitins commands work for them, though).
  

I agree that an arbitrary time penalty would be useful, and InSim packets can already hold information about penalties (see IS_RES).

For racing lines, rather than a few specific lines, I think it would be better if AI could have a better understanding of the concept of attack/defense, and didn't try so hard to stay on its default line; if PTH files are used at all, those could also use some updates to include the entire width of the track (currently some parts of the various tracks are not considered in the "driving limits" despite being within track limits, especially in turns like chicanes). Being able to feed a custom PTH and have AI compute trajectories from it would be great.

Rolling start could be nice as well, but AI currently doesn't seem to understand anything other than "drive as fast as you can" and "drive somewhat slower and return to pits". The next best thing would be using InSim with custom AI control via IS_AIC packets and IS_OCO to turn the lights green; I'm not sure we can resume standard AI control after that, though.

Coming back to this, I know there is no "race started" packet (no, I'm not talking about IS_RST, but actual start on green light) because it could be used to cheat starts, but how about adding such a packet, only sending it 1-5 seconds after the start, with the time info? This way InSim applications could adjust and still have timing data.

Alternatively, I guess we can use IS_CSC packets to trigger the race start manually when multiple cars start moving. For hotlaps it's a bit different, we would need to check the PTH nodes and start timing when the car reaches the finish line node - won't be accurate, but I guess we can do that until the first split.

At this time, to give AI a specific vehicle, setup and color, we need to enable the "AI use player setup" and "AI use player colours" options, then select the car (XXX/mod) we want, with the appropriate setup/color, and add the AI.

Some of those steps can be automated (/car UF1 /setup my_setup /colour my_color /ai AI 1), but having the above-mentioned options enabled is required. However, selecting a mod this way is not possible as there is no corresponding command.

I would like to see new commands that can set all of those without requiring the use of those options, and without having to choose a car for ourselves just for the AI to select it too. Something akin to the /aiskill command which only affects new AI, so maybe /aicar, /aisetup, /aicolour.

With that said, there are also 2 other issues with the current system:

• Default setups and colors cannot be selected via /setup and /colour (default setups are "not found" and default colors have no names); maybe having those work with /setup 0 or /colour 1 could be a thing? (but would require forbidding setups/color names with a single digit)
  
• Mods are not available for selection (that is true for players as well, not just AI), greatly limiting possibilities, especially with the new custom AI control in the 0.7F5 series of test patches (you can't spawn local AI with different cars from yours if you are already driving, and can't assign mods to them).
  

GodotInSim version 2 is now available on GitHub.

I am introducing a few breaking changes (such as InSimPacket.create() for sendable packets instead of forcing initialization in InSimPacket.new()), but also more features to LFSText, more file formats (lyt, set, car_info.bin), and Player/Connection/LFSState classes that keep track of PLID/UCID/IS_STA changes, with GodotInSim automatically sending requests where needed. New helper functions for sending messages were also added to simplify the use of IS_MST, IS_MSX, IS_MSL and IS_MTC packets.

Those changes will make my life easier for the GIS Hub mentioned in my previous post, but also allows me to replace my ad-hoc, partial .set and car_info.bin parsing for the setup validation tool with full parsing of those files.

And since I'm mentioning GIS Hub again, quick update: the plan to use a TCP server to decouple the main InSim connection and the modules is going to the bin, as it brings more pain than is necessary, and actually has little to no benefit (modules crashing still means functionality is lost, so if you need to keep critical functionality, it's easier to just have another instance with different modules enabled). Instead, one GIS Hub instance manages one InSim connection, and all modules in that instance share this connection - same result, except that if you want to separate functionality, you have to launch another instance (and use a second InSim "slot").
Progress on the hub app itself is slow a I've been working on GodotInSim itself, and can now use some of the new features for this. I still need to make a proper module management system, as right now every module found gets loaded, no questions asked.



(Grid Maker was a simple test to place start positions for each of the 32 cars on the grid, and extend that to 40 (in a straight line, although following the PTH nodes should be possible))
(Race Director is a test and doesn't do much yet, but should give a shiny GUI to control lights (main lights, pit exit lights, additional groups of lights by sector), start/end safety car/VSC/red flag, give penalties to drivers, and monitor car contacts, object hits, and HLVC reports)

We all live for speed, whether it be the speed of the fastest vehicle there is, or the speed of a 1kW lawnmower

When we want to strip the name from an IS_MSO message, we can use TextStart, and this works fine... as long as the sender's name only contains latin characters. If I use Japanese characters in my name, for instance (and I know this is pretty common for teams and people to use Japanese katakana to stylize text, e.g. ﾁSﾏ for FSR), then TextStart will have a greater value than it should.

Here's an example using "Cyk R", "Cyk ﾏ" (half-width "ma") and "Cyk マ" (full-width "ma") as a nickname and sending a message containing only "test":

buffer[+TextStart] is just me cutting the TextStart first bytes and converting again, for reference, while substr(+TextStart) is how I assume TextStart is supposed to be used, by removing the TextStart first characters from the string.

A single Japanese character caused an offset of 2 characters in TextStart, maybe because ^J is ignored? Also worth noting that full-width Japanese characters cause an additional offset in TextStart, as seen in the 3rd test.

I think this means any codepage change in the player's name will cause TextStart to report erroneous values, and full-width Japanese characters (at the very least) also throw TextStart off. A name like 日本人じゃないけど will cut 11 characters from the message.

With that said, it is possible to use a regular expression to fulfill the same purpose without relying on TextStart, that's what the custom regex line shows in the above tests.

Last edited by Bokujishin, Fri 28 Mar 2025, 11:10. Reason : Swapped buffer/substr for 3rd test

Multiple commands can be sent in a single message (e.g. /laps=10 /cars=UF1 /wind=1), however, starting a message with /i or /o will result in any following slash character (if preceded by a space) to be interpreted as a command.

Examples:

• /i Testing /i messages
  
  Sends 2 IS_III messages, containing "Testing" and "messages".
  
  
• /o Hidden message triggering /i IS_III
  
  Sends an IS_MSO (MSO_O) "Hidden message triggering" and an IS_III "IS_III".
  
  
• /o Sending a message and some command: /laps 2
  
  Sends an IS_MSO (MSO_O) "Sending a message and some command:" and changes lap count.
  
  
• /o Disable SC/VSC
  
  Sends IS_MSO "Disable SC/VSC"
  
  
• /o Disable SC / VSC
  
  Sends IS_MSO "Disable SC" and throws an "Unknown command" error for "/ VSC"
  

I believe that /i and /o messages should be excluded from multi-command parsing, at the very least if they're the first command in the message, since those messages are supposed to be parsed by an InSim application anyway.

While it is true it could be used to gain an advantage (adjusting brake balance in real time to optimize braking while minimizing lockups), as you say OutSim already allows for such cheating potential (but there's also non-OutSim cheating existing already with clutch macros and such).

However, I think it is also true that completely disabling brake balance updates for as long as some key/button press happens is wrong too, at the very least those updates should happen every second or so, instead of resetting the timer indefinitely. Also, the dashboard display (and F11 text) does update correctly, so it just feels wrong that the brake balance can stay at its previous value, potentially for several seconds before being properly updated.

On the other hand, it could be said that using OutSim to take advantage of the data could allow for some kind of ESP simulation - you won't get per-wheel authority, but you could adjust brake balance, brake strength and steering to get a somewhat decent ESP simulation.

In my case, for the brake pressure limiter, real time brake balance updates are a requirement, but it is of course a very specific need - still, one that would be really nice to bring the mod that bit closer to its real life counterpart.

Last edited by Bokujishin, Thu 20 Mar 2025, 15:46.

My testing has revealed that the brake balance is only updated one in-game second after the last brake balance change input, and that one-second timer resets on every subsequent input before the change takes effect. This means that repeated changes will only be applied after waiting a full second without touching the brake balance.
I did the testing on mouse/keyboard, so I haven't checked whether keeping a wheel button pressed prevents updates, but at the very least, keyboard echo "presses" keep resetting the timer.

Now why is this a problem? In relatively normal scenarios, it is not - unless you're adjusting your brake balance into the braking zone and/or during trail braking. However, I have a different, specific use case: I'm using InSim to try and simulate a brake pressure limiter as found on the Clio Cup (for my Laurent Coil Cup mod). This limiter caps the pressure in the rear brakes to an adjustable 10-40 bar, while pressure in the front brakes can reach 100 bar.
To simulate this, I have to adjust the brake balance based on brake pedal input, and I have to make those adjustments quickly, so the brake torque in the rear wheels is properly capped. However, with the way brake balance updates currently work, this cannot work at all, as the "best case scenario" would be 100% brake input, which would only update the brake balance one second later, with any change in braking input disabling brake balance updates altogether. This basically means my limiter, which is supposed to help prevent rear wheels from locking up, actually forces them to lock up (since brake balance is 50/50 when brakes are not applied).

Here are reproduction steps for Scawen or anyone interested in checking brake balance behavior:

• Choose the XFR, as it's easier than some other cars to see the effect without spinning out.
  
• Make a setup with minimum brake strength, and set brake balance to 95%.
  
• Accelerate close to top speed (LA1 works best for this).
  
• Press and hold the left arrow key, so brake balance goes all the way down to 5%.
  
• Very important: keep pressing the left arrow key!
  
• Start braking: only the front wheels are braking.
  
• Release the left arrow key: after one second (2, 4 or 8 if you slow time down), only the rear wheels are braking.
  

You can also check the attached replay. As soon as I shift to 6th gear, I start decreasing brake balance to 5% (replays don't show this properly), I then start braking some time before crossing the road, and release the left arrow key as I cross it; exactly one second later, brake balance shifts to the rear wheels. The rest of the replay show a couple more abrupt changes, though there's no visual cue for those.

With all that said, unless it creates a problem of some sort, I would like to see brake balance changes apply immediately, as soon as the button is pressed, to allow for both my own InSim experiment to work, and people who do change brake bias mid-corner.

Shadows for dynamic lights are definitely possible without ray/path tracing, using cubemap or dual paraboloid shadowing, which is basically shadow mapping for omni/spot lights (spotlights being cheaper than omni lights). However, after re-watching the night time video from the South City progress report from December 2019, headlights were not casting shadows, not sure what the plan is going forward.

Oh, yeah, those example images do look like the AgX colors are off, it kind of looks like a white balance issue, as even pure white appears pink-orange in the red/green/blue/yellow lights example. Certainly not the usual kind of results other comparisons show, from what I've seen.

I haven't looked into tonemappers in-depth, just enough to know the differences as a user, but I don't remember AgX being purple (it tends to look like uncorrected log film out of the box, so really desaturated images, and you should then color correct and adjust contrast and such) - I can say however that a good, properly adjusted, AgX tonemapped image can look much better than other tonemappers as it basically removes hue-shift for high-saturation, high-illumination scenarios and is smoother overall in its color range.

But I will happily take the current implementation for a first release, like you're planning to do for the dashboard illumination, as it already looks much nicer than the current public version

Here is Godot's implementation for reference (Vulkan/OpenGL based): https://github.com/godotengine/godot/pull/87260
There are also a few more pull requests related to AgX adjustments made later.
You can also find some nice comparisons made in Blender, typically between sRGB, Filmic and AgX.

Thanks for the night version, really nice too!
You mentioned the sky not being pitch black because of the date, and while I'm not sure of the difference between France and the UK, I was still expecting something darker, but more to the point - I think there's a bit too much ambient light outside, I believe the buildings and even the road should look much darker even with the sky's current brightness and street lights.

In the tunnel itself, this may be more subjective of an opinion, but in my experience, French tunnels at least are much darker than this (if you look at the following picture, you should adjust exposure to at least -3 to get something that's more true to life (except the image itself has no usable dynamic range at that exposure value)):


With that said, it will probably turn out to be necessary to expose user settings for auto-exposure.

It looks better already with the center weighting, but I'm also curious about slightly slower transitions as Flame mentioned.
Also, I'm now wondering about triple screen (or other multiple screen setups): is the center weighting stretched over all screens, or just the center screen?

It would be wonderful if the licensing allows for it to be included in LFS, I sure am hoping to see interest from Scawen/Eric. More real life tracks can only improve the LFS experience.

With that said, even if the data were to be made available to them right now, I assume we're looking at several years down the line for Eric to be able to make it into a proper LFS track (since he already has to update existing tracks environments, and we don't know about possible plans for new cars) - unless a mod track editor is made available, but that too would require a lot of work before it could be released.

Proper rain driving (with actual wet line, even without puddles and such) would also be probably impossible on layouts, as the game would need to know where cars are actually driving to "get the rubber in" (or at least it would be much more difficult to have that on concrete parts), but don't get me wrong, I'd love to have rain in LFS, just later down the line.
Simply lowering overall grip wouldn't be very interesting, even if it would at least allow people to risk not using wet tyres (sorry michal). And a dynamic track system (temperature varying with time of day weather, and cars driving on it, and bonus points for dirt/debris/marbles) would very likely be needed before rain is even considered.

Alright, time to announce a new project with GodotInSim: GIS Hub (as in GodotInSim Hub).

This is an application, built on GodotInSim of course, that aims to become a small ecosystem, an InSim manager if you will; you get a GUI with tabs, where each tab corresponds to an InSim module, and therefore each module can provide its own user interface based on Godot Control nodes, as well as its own logic, based on a packet subscription system: modules initialize by telling the hub which packets they want to handle, and optionally which packets they want to ignore. They can also request notifications for packets sent by other modules, as well as the list of active modules.

As a bonus, all modules share the same InSim connection, so it can be interesting to make modules more specialized instead of having a very broad scope, without risking going over the maximum 8 connections LFS supports.

The idea here is to allow multiple people (or myself ) to work on smaller-scale projects, and potentially use functionality from other modules where it makes sense (although I hope this won't make dependencies too big of an issue).

To allow for a single InSim connection, I start a separate instance of the app, create a TCP server on it (default port 29990), and connect the hub to it. The server connects to InSim and relays packets to and from the hub, which then dispatches them to the modules.

Since each module only needs to implement a few GISModule functions, but is completely free otherwise, you can even manage your own InSim connection if you want to bypass the server, while still being able to monitor other modules. OutSim and OutGauge, as well as InSimRelay, must be managed at the module level.

As a very quick example, here is a simple log module, which writes the contents of packets it receives, packets sent by other modules, and formats messages in a nicer way instead of the raw data: (yes, the messages are just tests and sent by the log module itself)


The InSim-managing server also includes a log, but writes it to a file instead, which means that even if the hub crashes because of a module error, packets keep being logged by the InSim connection, and the hub can reconnect to the server when restarted.

I am planning to make a few "core" modules, that would always be active, but other modules would be discovered at runtime and enabled or disabled dynamically by the user. Currently planned core modules include Hub functionality (general settings, InSim setup) and Player Management (UCID and PLID lists - this might be included in the Hub module instead), I am open to suggestions for additional core features (something that the vast majority of InSim apps could use). I will also try to convert my own projects to modules and distribute them along with this app.

Speaking of which: modules need to be exported as a Godot pck file (you need the Godot Editor for this), and placed in the modules folder next to the executable. The pck should be contained in a folder of the same name (modules/my_module/my_module.pck), to avoid conflicts in the filesystem after importing multiple modules.

Security: Modules have access to all Godot functionality, including potentially dangerous functions, like deleting files or simply executing any kind of code - you should only download pck files from trusted sources (ideally directly from the author's online code repository like GitHub or GitLab), and not from random people (that would be like launching .exe files random people send you).

GIS Hub features:

• Modular InSim application with a TCP server managing packet input/output to/from LFS
  
• Very basic crash protection for the InSim server, running in a separate process from the hub (does not prevent loss of functionality from the modules)
  
• Allows for cohabitation of many independent modules while "consuming" only one InSim connection
  
• Full InSim, OutSim, OutGauge and InSimRelay support on a per-module level
  
• Module communication: modules can request the list of active modules, as well as monitor packets sent by other modules
  

Planned core module features:

• (WIP) GIS Hub options, InSim setup
  
• (Planned) UCID and PLID management
  
• (Other) Open to more suggestions (for actual core features)
  

Planned modules:

• (Done) Packet logs
  
• (Planned) Message helper (write or copy/paste Unicode characters, change selected text's color, send as user or local message)
  
• (WIP) Telemetry
  
• (WIP) Race Stats
  
• (WIP) Lap Delta (a certain someone has been persistently asking for this since I showed a proof of concept last summer , even though other apps already do this)
  
• (Maybe) Setup Validation Tool (not sure it warrants a module as it does not actually use InSim (it would if setups could be sent via InSim), but why not)
  

I may also investigate the possibility of separating tabs into their own windows, so you can see multiple modules at the same time (e.g. minimap + telemetry + race stats).

I will probably repeat some of this, and include more details about actually creating modules, in a dedicated thread and in a link to the GitLab repository I'm hosting this on, once I have improved basic functionality and tested it properly.

Last edited by Bokujishin, Tue 11 Mar 2025, 16:49.

Eric mentioned "2 other tracks" in the Kyoto progress report thread that won't be included in the update, he most likely meant Bancroft and Fairfield.