TextStart in IS_MSO is unreliable for non-latin characters
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.
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":
full message: ^7Cyk R ^7: ^8test
to utf16(?): ^7Cyk R ^7^c ^8test
TextStart = 14
buffer[+TextStart]: R ^7: ^8test
substr(+TextStart): test
custom regex: test
full message: ^7Cyk ﾏ ^7: ^8test
to utf16(?): ^7Cyk ^JÏ ^7^c ^8test
TextStart = 16
buffer[+TextStart]: Ï ^7: ^8test
substr(+TextStart): st
custom regex: test
full message: ^7Cyk マ ^7: ^8test
to utf16(?): ^7Cyk ^J荽 ^7^c ^8test
TextStart = 17
buffer[+TextStart]: } ^7: ^8test
substr(+TextStart): t
custom regex: 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.
\^7%s \^7: \^8 # Replace %s with player name
(?<!\\)\^ # Use this to escape non-escaped carets ^ in the player's name
Last edited by Bokujishin, .
Reason : Swapped buffer/substr for 3rd test
Multi-command parsing cuts /o and /i messages
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:
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"
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.
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, .
Allow more responsive brake balance changes
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:
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.
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.
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.
(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.
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?
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.
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.
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:
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.
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
- (WIP) GIS Hub options, InSim setup
- (Planned) UCID and PLID management
- (Other) Open to more suggestions (for actual core features)
- (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 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, .
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.
Great read, and interesting trick with the alpha for proper auto-exposure. I do wonder though, how does it react to viewing almost exclusively the interior of a vehicle? (especially in VR if you look down and/or to the passenger side, as that could make the whole picture alpha-less). Did you maybe try weighing scenery vs sky/interior instead of masking them out entirely?
Another thing that caught my eye is the speed of auto-exposure in the video (really nice to watch by the way, I like the whiteout at the end of the tunnel): it seems a bit too reactive at times, e.g. when driving in and out of the shadows before entering the tunnel, leading to some "blinking" of the sky; the dash also unfortunately becomes illegible, and I assume night driving will result in similar (or worse) lighting scenarios.
Still on the subject of lighting, I'm wondering what tonemapping you are using, and whether a different approach would help with the dynamic range (a popular tonemapper in games being ACES, but I would also like to suggest AgX, as it tends to look more realistic (the Godot Engine made a slightly simplified implementation that is more suited to games than the full version).
Feel free to use us as bug hunters when you can get a test patch out, I'm sure some of us would be more than willing to help beyond just enjoying the shiny update (although many would likely just complain about the crashes instead).
Another thing that caught my eye is the speed of auto-exposure in the video (really nice to watch by the way, I like the whiteout at the end of the tunnel): it seems a bit too reactive at times, e.g. when driving in and out of the shadows before entering the tunnel, leading to some "blinking" of the sky; the dash also unfortunately becomes illegible, and I assume night driving will result in similar (or worse) lighting scenarios.
Still on the subject of lighting, I'm wondering what tonemapping you are using, and whether a different approach would help with the dynamic range (a popular tonemapper in games being ACES, but I would also like to suggest AgX, as it tends to look more realistic (the Godot Engine made a slightly simplified implementation that is more suited to games than the full version).
Feel free to use us as bug hunters when you can get a test patch out
, I'm sure some of us would be more than willing to help beyond just enjoying the shiny update (although many would likely just complain about the crashes instead).
Last edited by Bokujishin, .
Update layout format for increased resolution and data capacity
The current file format for layouts has mostly stayed the same over the years, with some more recent additions (concrete objects) managing to include their data without changing the format.
I would like to propose updating that format to a new version, in order to give more freedom to layout makers, and maybe also make the format more future-proof. For reference, the current format is documented publicly on the LYT format page.
In the current format, after the 12-byte header, we find object blocks, 8 bytes each. I propose the following 16-byte object block instead:
Compared to the current format, we have the following changes:
I mentioned increased resolution for X, Y, Z, and heading, so let's get into that:
What could the increased flags size allow? Well I will let everyone give their suggestions, but at the very least it could allow storing values per byte, instead of trying to stuff some data on 2 bits, other data on 5 bits, and all of that depending on the object type.
We could also go for variable-size object blocks, by adding a size byte to the object header, thus storing only useful data about each object, at a small fixed cost. This could be used to make customizable signs with a text field, for instance.
Edit: Fixed value for Z steps, it would be about 1mm, not 1cm.
I would like to propose updating that format to a new version, in order to give more freedom to layout makers, and maybe also make the format more future-proof. For reference, the current format is documented publicly on the LYT format page.
In the current format, after the 12-byte header, we find object blocks, 8 bytes each. I propose the following 16-byte object block instead:
num unit offset description
--- ---- ------ -----------
1 byte 0 object type
1 int 1 X
1 int 5 Y
1 short 9 Zshort
1 short 11 heading
1 word 13 flags
1 byte 15 index
Compared to the current format, we have the following changes:
- Increased resolution for X, Y, Z coordinates, as well as heading
- Introduction of object type, which would basically replace the current index byte
- Doubled flags size, to fit more data
- Repurposing index to serve as index numbers for objects that need those (InSim circles, InSim checkpoints could use those too)
I mentioned increased resolution for X, Y, Z, and heading, so let's get into that:
- Currently, with shorts for X and Y, we have 16 discrete values per meter, or 6.25cm steps; ints would provide 65,536 values per meter, or about 0.015mm - no more trouble placing objects just the way we want.
- Z uses a byte, which translates to 4 values per meter, or 25cm steps; a short would allow for 1,024 values per meter, or just below 1mm steps.
- Same story for heading, a byte translates to 256 values for 360 degrees, or about 1.4 degree per step, while using a short would allow roughly 0.005-degree steps.
What could the increased flags size allow? Well I will let everyone give their suggestions, but at the very least it could allow storing values per byte, instead of trying to stuff some data on 2 bits, other data on 5 bits, and all of that depending on the object type.
We could also go for variable-size object blocks, by adding a size byte to the object header, thus storing only useful data about each object, at a small fixed cost. This could be used to make customizable signs with a text field, for instance.
Edit: Fixed value for Z steps, it would be about 1mm, not 1cm.
Last edited by Bokujishin, .
While I generally agree with the idea, it would probably also help to have stand-in logos for those as well, since I think otherwise everyone goes for their own ideas - for the Laurent Coil Cup, I made Laurent as an anagram from Renault, and made a logo fitting the rhombus based on the L and T in LaurenT, but that's just one of many possibilities.
The mod being for your private use does not enable you to circumvent the rules, as publishing a mod, even if you are the only one able to drive it, still means that the game has to allow downloading the mod - that's where rules are meant to apply. If someone makes a mod containing prohibited content (the content itself or the source of the content), that's illegal, whether you're the only one driving or not.
If you want to make mods *really* for your own private use, you can use the "test in LFS" function - single player only, not online, but there you can do whatever you want.
If you want to be the only one able to drive your mod online, you must follow the rules.
If you want to make mods *really* for your own private use, you can use the "test in LFS" function - single player only, not online, but there you can do whatever you want.
If you want to be the only one able to drive your mod online, you must follow the rules.
How are the setup limits determined for mods? I tried changing the class of my Laurent Coil Cup mod from touring car to GT, hoping to allow more ARB, but it did not change anything (same when creating a new GT vehicle and giving it the same physics). The Clio's rear ARB is quite stiff because of the way the axle is made, and it can be made even stiffer for the Cup version - if my calculations are not wrong, at least, I would need to try 180 N/mm for the stiffest option, with a base stiffness of 110 N/mm; however, I cannot go past 130, so I can't try it out (currently going with 80 and 130 as a result).
Any possibility to go past that? Other mods (GT3 cars like the Protech 92 for instance) can go up to 330 N/mm, is it related to the engine?
Any possibility to go past that? Other mods (GT3 cars like the Protech 92 for instance) can go up to 330 N/mm, is it related to the engine?
Couldn't this be prevented by adding a good amount of damping in the end stop force? I have to admit I don't know how it's done in other software, but in LFS, reaching the end stop makes the wheel bounce sometimes pretty hard, and if the FFB tries to turn the wheel past the stop, the wheel will keep bouncing until you move it away (this can happen when stopped, typically in grass or gravel, with damaged suspension or maybe just on slopes, or when you spin the car and the wheel travels the whole range, especially on cars that have smaller wheel rotation).
Out of the game, the soft limit on my wheel (1080 degrees, configurable as with all direct drives) feels much better, it stops the wheel (maybe not as firmly as LFS does), but the force then feels like it wants the wheel to stay around the stop, instead of trying to push it away completely - I assume LFS applies a force directly proportional to how far the wheel is over the limit? Maybe a PID would help here?
Anyway that's probably slightly off topic here, but maybe food for thoughts later on.
Out of the game, the soft limit on my wheel (1080 degrees, configurable as with all direct drives) feels much better, it stops the wheel (maybe not as firmly as LFS does), but the force then feels like it wants the wheel to stay around the stop, instead of trying to push it away completely - I assume LFS applies a force directly proportional to how far the wheel is over the limit? Maybe a PID would help here?
Anyway that's probably slightly off topic here, but maybe food for thoughts later on.
FWIW, I experimented with using s_plate_alp for driver name and number decals - it's hacky at best, and I have only tried a single number/name combination, so I expect other values to break in one way or another.
You can see the explanation in this post about my Coil Cup mod, screenshots attached here as well.
Edit: Alternatively, having access to a transparent user texture would be nice, although I assume it would be a mess to have that in addition to skins.
You can see the explanation in this post about my Coil Cup mod, screenshots attached here as well.
Edit: Alternatively, having access to a transparent user texture would be nice, although I assume it would be a mess to have that in addition to skins.
Last edited by Bokujishin, .
I've been experimenting with driver name and number as window decals - unfortunately, the game does not allow adding those properly, so I made a hacky workaround using the s_plate_alp texture instead (which by the way, does not seem to allow specifying cutouts smaller than the texture? it stays locked at 128x32 for some reason, after I set it once, and won't change anymore even after restarting the editor).
This thing can only work if people use XX YYY as their license plate, where XX is a two-digit number, YYY is the driver's trigram, and adjusting relative positions with spaces (multiple spaces are needed to prevent unwanted bits from appearing).
I *may* keep this as a separate configuration (and will probably replace the "no window paint" version with this), but I would definitely prefer having a proper solution to this (user-configurable car number, driver name, possibly driver flag, available either in s_plate (and s_plate_alp) or a new special texture - bonus points for multi-driver, or at least having the texture change on driver swaps).
This thing can only work if people use XX YYY as their license plate, where XX is a two-digit number, YYY is the driver's trigram, and adjusting relative positions with spaces (multiple spaces are needed to prevent unwanted bits from appearing).
I *may* keep this as a separate configuration (and will probably replace the "no window paint" version with this), but I would definitely prefer having a proper solution to this (user-configurable car number, driver name, possibly driver flag, available either in s_plate (and s_plate_alp) or a new special texture - bonus points for multi-driver, or at least having the texture change on driver swaps).
Hey, thanks for the feedback! Regarding 1st gear, while I do agree it feels a bit too long, especially on race start, I am following the official specs of the real gearbox (reverse gear is even slightly longer...). You have to play with the clutch to get a good launch, but it tends to heat it up quite a bit.
Center of mass I recently moved up again a little bit as I had made it likely too low, although to be honest I do not know how high it should be - what I can say is I have not managed to roll the car on a flat straight, even with abrupt steering and playing with the brakes. However, it does indeed roll somewhat easily when going on kerbs. My main references for that behavior would be from videos of Jardier's Clio Cup season, there are 2 instances of a car flipping after being hit and turned almost 90 degrees by another car, even on a flat surface (Paul Ricard, but there's another instance at Eau Rouge, Spa), and Jardier himself had to ease the steering to avoid rolling after riding a kerb at Paul Ricard.
Also, another reason for higher CoM is to help the car go 3-wheel, but even as it is now it won't lift the rear as much as the real car.
I unfortunately have no proper reference for the turbo (what pressure I should put in LFS or how much it lags), I kept default settings here, I'll have another look at official documents to see if I can find something useful.
As for the sound, I must admit it's not really to my liking (not close enough to the real sound), I agree it could be a bit louder, I just hope it won't cause clipping if I do that.
Center of mass I recently moved up again a little bit as I had made it likely too low, although to be honest I do not know how high it should be - what I can say is I have not managed to roll the car on a flat straight, even with abrupt steering and playing with the brakes. However, it does indeed roll somewhat easily when going on kerbs. My main references for that behavior would be from videos of Jardier's Clio Cup season, there are 2 instances of a car flipping after being hit and turned almost 90 degrees by another car, even on a flat surface (Paul Ricard, but there's another instance at Eau Rouge, Spa), and Jardier himself had to ease the steering to avoid rolling after riding a kerb at Paul Ricard.
Also, another reason for higher CoM is to help the car go 3-wheel, but even as it is now it won't lift the rear as much as the real car.
I unfortunately have no proper reference for the turbo (what pressure I should put in LFS or how much it lags), I kept default settings here, I'll have another look at official documents to see if I can find something useful.
As for the sound, I must admit it's not really to my liking (not close enough to the real sound), I agree it could be a bit louder, I just hope it won't cause clipping if I do that.
Sorry but I will not add ABS to this car, as the Clio Cup does not have it - braking is challenging indeed, as the differential has low preload and almost no coast locking, so if you have trouble there, I would suggest lowering the brake strength and trying to move the brake balance instead. Or you can adjust the differential itself, but I chose values that try to approach the real car's behavior (you can definitely see them lock up in real life).
LAURENT COIL CUP
Vehicle mod: LAURENT COIL CUP
Details page: https://www.lfs.net/files/vehmods/DBF12E
SHORT DESCRIPTION:
COVER SCREENSHOT:
Details page: https://www.lfs.net/files/vehmods/DBF12E
SHORT DESCRIPTION:
COVER SCREENSHOT:
Thank you, it means a lot coming from you, as you make very high quality models yourself and especially very high quality textures plus all the tips you post as well.
Texturing is somewhat of my nemesis, I've never really had the knack for it, and that's probably why I tend to rely more on geometry, so I'll see how it goes - thank you for the advice! One thing that would definitely help with faking details with textures is normal mapping (it would be especially nice for grilles to make them less flat, but leather, alcantara and other materials would benefit as well, but I'll see what variable shine can do - I assume it's a specular map?).
Today I've also sent an update for review, the mod will be available to all since I have now fixed most issues and added more things in LOD1, and LOD2 has been overhauled (with 5.5k triangles, we'll see how this one goes). It remains WIP though as I still need to model the steering column, interior door panels, touch up on the dashboard, and detail the rear half of the interior.
After that, I plan to reorganize the model a bit (layers, subobjects, cutouts) in hopes of allowing for easier work on variants of the car - Cup is one thing, but RX and Rally5 versions are very close, then there's the road version, and I would also like to make the Rally3 version, so if I can keep a single model for all of those, that will help. All versions would be separate mods rather than configurations, though, as even RX and Rally5 have different masses and weight distributions, in addition to a slightly less powerful engine, and there's also the copilot for rally versions.
Bonus screenshots: finally started working on tail lights this is how they look in the updated mod, still WIP but already better than what I had before.
plus all the tips you post as well.Texturing is somewhat of my nemesis, I've never really had the knack for it, and that's probably why I tend to rely more on geometry, so I'll see how it goes - thank you for the advice! One thing that would definitely help with faking details with textures is normal mapping (it would be especially nice for grilles to make them less flat, but leather, alcantara and other materials would benefit as well, but I'll see what variable shine can do - I assume it's a specular map?).
Today I've also sent an update for review, the mod will be available to all since I have now fixed most issues and added more things in LOD1, and LOD2 has been overhauled (with 5.5k triangles, we'll see how this one goes). It remains WIP though as I still need to model the steering column, interior door panels, touch up on the dashboard, and detail the rear half of the interior.
After that, I plan to reorganize the model a bit (layers, subobjects, cutouts) in hopes of allowing for easier work on variants of the car - Cup is one thing, but RX and Rally5 versions are very close, then there's the road version, and I would also like to make the Rally3 version, so if I can keep a single model for all of those, that will help. All versions would be separate mods rather than configurations, though, as even RX and Rally5 have different masses and weight distributions, in addition to a slightly less powerful engine, and there's also the copilot for rally versions.
Bonus screenshots: finally started working on tail lights
this is how they look in the updated mod, still WIP but already better than what I had before.
Last edited by Bokujishin, .
FGED GREDG RDFGDR GSFDG