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, .
Some of those commands are either already available, or the same effect can be obtained through the GUI:
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.
- 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).
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.
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.
Add commands to set AI setup, color, and vehicle/mod
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:
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)
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
FGED GREDG RDFGDR GSFDG