Technical progress report, March 2025
Hello Racers,
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
There is no option to remove the crosshair. It should only be visible in menus anyway so should not affect your driving.
That is the first time I have heard of a loss of position tracking in any VR headset. I'd be interested to see the contents of your openvr.log file that is created when you enter VR.
But that brings me to a question, if you have a Quest 3, why are you using OpenVR? Does it not work if you select the "Oculus Rift" option? I'd be very interested to know the answer. Maybe it does work, but you don't select "Oculus Rift" because it's really a Meta Quest?
That is the first time I have heard of a loss of position tracking in any VR headset. I'd be interested to see the contents of your openvr.log file that is created when you enter VR.
But that brings me to a question, if you have a Quest 3, why are you using OpenVR? Does it not work if you select the "Oculus Rift" option? I'd be very interested to know the answer. Maybe it does work, but you don't select "Oculus Rift" because it's really a Meta Quest?
I've reinstated the round templates, allowing the new style options.
The change is that practice/qualify/race can all be specified in minutes/hours/laps without restriction.
This required some extra data in the default round format (which is stored in a different way from actual rounds). That means the old default round storage format is invalid and old round templates do not appear.
Please try it and let me know if you think it is working OK.
rane_nbg, I understand your other requests, but as I'm not really good at adding web page input systems and changing Victor's code, it's not easy for me so I can't get into it at this time while I am on a big push to get to our release.
1) The car selection option I see is a pain. At least now you can leave it as "unspecified" due to a recent change.
2) The use of a full calendar for every session in a round seems annoying, I get it. I think it should be you specify the start time of the round, and the sessions should have time offsets from that start time. In that case, the offsets could be inlcuded in the default event format.
But right now I am battling my things to try to get to a release, so I can't take on this extra confusion in the web languages that I'm not really good at. I can do these things but, as you know, it's slow progress working in someone else's system, in strange languages.
The change is that practice/qualify/race can all be specified in minutes/hours/laps without restriction.
This required some extra data in the default round format (which is stored in a different way from actual rounds). That means the old default round storage format is invalid and old round templates do not appear.
Please try it and let me know if you think it is working OK.
rane_nbg, I understand your other requests, but as I'm not really good at adding web page input systems and changing Victor's code, it's not easy for me so I can't get into it at this time while I am on a big push to get to our release.
1) The car selection option I see is a pain. At least now you can leave it as "unspecified" due to a recent change.
2) The use of a full calendar for every session in a round seems annoying, I get it. I think it should be you specify the start time of the round, and the sessions should have time offsets from that start time. In that case, the offsets could be inlcuded in the default event format.
But right now I am battling my things to try to get to a release, so I can't take on this extra confusion in the web languages that I'm not really good at. I can do these things but, as you know, it's slow progress working in someone else's system, in strange languages.
What are the files named in the data\layout folder?
You can only load them from the appropriate track configuration.
E.g. BL3 or BL3X count as a different configuration.
You can only load them from the appropriate track configuration.
E.g. BL3 or BL3X count as a different configuration.
Hi,
I could have a look at this.
I removed it when I recently added the ability to show races in minutes (not only laps and hours). The event template system didn't support that as it uses a different type of storage.
I should probably add it back, as I see that the feature is used.
I could have a look at this.
I removed it when I recently added the ability to show races in minutes (not only laps and hours). The event template system didn't support that as it uses a different type of storage.
I should probably add it back, as I see that the feature is used.
Small changes yesterday:
1) Race duration can be specified in minutes (not only hours or laps)
2) Cars can be 'unspecified' (league admin is not forced to select a car)
1) Race duration can be specified in minutes (not only hours or laps)
2) Cars can be 'unspecified' (league admin is not forced to select a car)
Think this topic has gone on long enough. If Daniel wants to update LFS Lazy he can start a new thread.
Restate previous post with actual truth, because half truths, exaggerations and distortions are unhelpful and spread bad feeling, which is the intent of certain post authors.
An unauthorised version, hacked to work with layer versions of LFS, without permission of the author, was released to this forum without permission and the post was removed. We don't host links to pirate software.
I have tried to contact the developer of LFS Lazy on multiple occasions but have not been successful.
An unauthorised version, hacked to work with layer versions of LFS, without permission of the author, was released to this forum without permission and the post was removed. We don't host links to pirate software.
I have tried to contact the developer of LFS Lazy on multiple occasions but have not been successful.
Fix for Vive Pro 2
I wonder if anyone uses a Vive Pro 2?
vRenegade reported an issue here that caused the image to be skewed when your head is tilted.
I hope that is now fixed in test patch F6, which you can try here: https://www.lfs.net/forum/thread/110607
vRenegade reported an issue here that caused the image to be skewed when your head is tilted.
I hope that is now fixed in test patch F6, which you can try here: https://www.lfs.net/forum/thread/110607
Thanks for your patience!
I have finally done something about this, as I have been in the development version dealing with VR and projection matrices recently.
The new option is available for testing in the test patch forum, which I have left hidden for now to try and avoid distraction from people making random off-topic requests.
https://www.lfs.net/forum/thread/110607
I will be happy to know if the VR support is fixed when you are able to test it.
I have finally done something about this, as I have been in the development version dealing with VR and projection matrices recently.
The new option is available for testing in the test patch forum, which I have left hidden for now to try and avoid distraction from people making random off-topic requests.
https://www.lfs.net/forum/thread/110607
I will be happy to know if the VR support is fixed when you are able to test it.
Last edited by Scawen, .
Reason : typos
This thread is not really "General LFS Discussion".
It looks like Technical Assistance and we have a special section for that: https://www.lfs.net/forum/5
I will close this thread. If you ask in Technical Assistance, please provide more detail about what you are asking, so people can try to help you.
It looks like Technical Assistance and we have a special section for that: https://www.lfs.net/forum/5
I will close this thread. If you ask in Technical Assistance, please provide more detail about what you are asking, so people can try to help you.
Last edited by Scawen, .
The new option is available for testing in the test patch forum, which I have left hidden for now.
https://www.lfs.net/forum/thread/110607
The trouble with test patch threads is too many people get a strange idea in their head that it is a general off topic request thread. But I'm far too busy on the development version, and cannot be distracted. If I get off topic requests on that thread, I will close it.
I will be happy to hear about any problems with the new option, or the VR update.
https://www.lfs.net/forum/thread/110607
The trouble with test patch threads is too many people get a strange idea in their head that it is a general off topic request thread. But I'm far too busy on the development version, and cannot be distracted. If I get off topic requests on that thread, I will close it.
I will be happy to hear about any problems with the new option, or the VR update.
LFS Test Patch 0.7F15
WARNING: THIS IS A TEST
THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM
PLEASE TEST BEFORE YOU POST
PLEASE... NO OFF TOPIC FEATURE REQUESTS!
Hello Racers,
Here is a new test patch: 0.7F15
It contains support for a security update.
Most notably, you now use a generated "Unlock code" instead of the old "GAME password".
This patch is more informative about that and helpful if you have to type in the new code.
For more information, please see the thread in the main forum section: https://www.lfs.net/forum/thread/111994
Please read the list of changes below.
0.7F15 is COMPATIBLE with 0.7F
- You CAN connect online with 0.7F
- You CAN play single player replays from 0.7F
Changes in F15:
Clickable links to account details page in unlock error messages
More translations updated. Thank you translators!
Changes in F14:
More informative if unlock code needs to be set or is wrong
Also more helpful if license has been upgraded since the last unlock
- Info about license level and unlock code detected on entry screen
- Flashes the "Unlock" or "Licensed" button if attention is required
- An appropriate message and link is displayed on the unlock screen
- For license upgrade (when code is correct) the unlock button flashes
17 translations are now updated - thanks to all the translators
Changes in F13:
Improved support for the new "unlock code" (replacement for old GAME password)
- removed the EYE button - the unlock code is visible when you enter a new code
- error messages if there is any problem getting text from the clipboard
- 11 translations updated - thank you translators!
Changes in F12:
Improved support for the new "unlock code" (replacement for old GAME password)
- Correctly named field (for unlock code) in unlock screen
- EYE button beside the unlock code (see what you have entered)
- Informative message if your unlock code is not 20 characters
- Automatic exit from unlock screen after successful unlock message
Changes in F11:
Search button in mods screen now allows searching by Skin ID or the non-unique 4-character name
Changes in F10:
List of Hosts now has 30 lines and does not show the obsolete status text
Hover text with description when the mouse cursor is above a blob in the IP column
FIX: Stopped on "Join Specific Host" page after "Start New Host" (should immediately join)
Changes in F9:
Privacy update: Warning if you are joining a host that will log your IP address
- Your decision to trust that host is remembered, to avoid asking you again
- You can remove the "trusted" status by clicking the "trusted" button
- List of Hosts has a new IP column to indicate hosts that log your IP address
Stops on "Join Specific Host" after you click a join link on calendar or website
- You will need to click the "GO" button as if you had clicked in List of Hosts
Changes in F8:
Forces view mode is no longer applied to object mods (e.g. track mods)
FIX: Fuel and damage settings were always default on non-route configs
Changes in F7:
Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible
LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"
Changes in F6:
Force feedback:
Some steering wheels have a bug in their drivers, that cause them to seen as "First person controller" devices.
In this case, LFS does not know they are a steering wheel, so it does not enable the steering wheel bump stops.
There is a new option, in "Axes / FF" section to Enable steering wheel bump stops.
Do not use this if your controller is not a steering wheel.
VR:
It is possible for some VR headsets to have a FOV aspect ratio that is different from their pixel aspect ratio.
Until now, LFS did not deal with that case correctly, and this was apparent with the HTC Vive Pro 2.
Now, LFS uses the left, right, up, down FOV values more directly which should solve the problem.
Changes in F5:
InSim:
System to allow AI drivers to be directly controlled by a local InSim program.
Discussed here: https://www.lfs.net/forum/post/2114897#post2114897
AI drivers:
AI can now spawn in a config with an AI path even if knw has not been generated
FIX: AI now spawn in game with full fuel load if there is no path (or no knw)
FIX: Rare crash in AI code after another car spawned outside path
INSTALLATION:
Live for Speed LFS 0.7F must already be installed!
- Run the installer
NOTE: You can see if the patch is correctly installed when you run LFS.
Check the version number at the bottom of the entry screen.
DOWNLOAD:
IF YOU ALREADY HAVE 0.7F:
PATCH 0.7F TO 0.7F15 (installer)
https://www.lfs.net/file_lfs.p ... ATCH_7F_TO_7F15_setup.exe (1.7 MB)
THIS DOES NOT CONTAIN NEW TYRE PHYSICS OR THE NEW GRAPHICS SYSTEM
PLEASE TEST BEFORE YOU POST
PLEASE... NO OFF TOPIC FEATURE REQUESTS!
Hello Racers,
Here is a new test patch: 0.7F15
It contains support for a security update.
Most notably, you now use a generated "Unlock code" instead of the old "GAME password".
This patch is more informative about that and helpful if you have to type in the new code.
For more information, please see the thread in the main forum section: https://www.lfs.net/forum/thread/111994
Please read the list of changes below.
0.7F15 is COMPATIBLE with 0.7F
- You CAN connect online with 0.7F
- You CAN play single player replays from 0.7F
Changes in F15:
Clickable links to account details page in unlock error messages
More translations updated. Thank you translators!
Changes in F14:
More informative if unlock code needs to be set or is wrong
Also more helpful if license has been upgraded since the last unlock
- Info about license level and unlock code detected on entry screen
- Flashes the "Unlock" or "Licensed" button if attention is required
- An appropriate message and link is displayed on the unlock screen
- For license upgrade (when code is correct) the unlock button flashes
17 translations are now updated - thanks to all the translators
Changes in F13:
Improved support for the new "unlock code" (replacement for old GAME password)
- removed the EYE button - the unlock code is visible when you enter a new code
- error messages if there is any problem getting text from the clipboard
- 11 translations updated - thank you translators!
Changes in F12:
Improved support for the new "unlock code" (replacement for old GAME password)
- Correctly named field (for unlock code) in unlock screen
- EYE button beside the unlock code (see what you have entered)
- Informative message if your unlock code is not 20 characters
- Automatic exit from unlock screen after successful unlock message
Changes in F11:
Search button in mods screen now allows searching by Skin ID or the non-unique 4-character name
Changes in F10:
List of Hosts now has 30 lines and does not show the obsolete status text
Hover text with description when the mouse cursor is above a blob in the IP column
FIX: Stopped on "Join Specific Host" page after "Start New Host" (should immediately join)
Changes in F9:
Privacy update: Warning if you are joining a host that will log your IP address
- Your decision to trust that host is remembered, to avoid asking you again
- You can remove the "trusted" status by clicking the "trusted" button
- List of Hosts has a new IP column to indicate hosts that log your IP address
Stops on "Join Specific Host" after you click a join link on calendar or website
- You will need to click the "GO" button as if you had clicked in List of Hosts
Changes in F8:
Forces view mode is no longer applied to object mods (e.g. track mods)
FIX: Fuel and damage settings were always default on non-route configs
Changes in F7:
Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible
LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"
Changes in F6:
Force feedback:
Some steering wheels have a bug in their drivers, that cause them to seen as "First person controller" devices.
In this case, LFS does not know they are a steering wheel, so it does not enable the steering wheel bump stops.
There is a new option, in "Axes / FF" section to Enable steering wheel bump stops.
Do not use this if your controller is not a steering wheel.
VR:
It is possible for some VR headsets to have a FOV aspect ratio that is different from their pixel aspect ratio.
Until now, LFS did not deal with that case correctly, and this was apparent with the HTC Vive Pro 2.
Now, LFS uses the left, right, up, down FOV values more directly which should solve the problem.
Changes in F5:
InSim:
System to allow AI drivers to be directly controlled by a local InSim program.
Discussed here: https://www.lfs.net/forum/post/2114897#post2114897
AI drivers:
AI can now spawn in a config with an AI path even if knw has not been generated
FIX: AI now spawn in game with full fuel load if there is no path (or no knw)
FIX: Rare crash in AI code after another car spawned outside path
INSTALLATION:
Live for Speed LFS 0.7F must already be installed!
- Run the installer
NOTE: You can see if the patch is correctly installed when you run LFS.
Check the version number at the bottom of the entry screen.
DOWNLOAD:
IF YOU ALREADY HAVE 0.7F:
PATCH 0.7F TO 0.7F15 (installer)
https://www.lfs.net/file_lfs.p ... ATCH_7F_TO_7F15_setup.exe (1.7 MB)
Last edited by Scawen, .
No, it needs a warning when you select it, and I've done that now.
Apparently it's hard to believe what I'm saying, or I can't describe it well enough, so I've made a video.
This is what happens when you use the option with the wrong kind of device.
https://www.youtube.com/watch?v=JKxP4igYkRw
Apparently it's hard to believe what I'm saying, or I can't describe it well enough, so I've made a video.
This is what happens when you use the option with the wrong kind of device.
https://www.youtube.com/watch?v=JKxP4igYkRw
I hope to release a test patch this afternoon. In the development version I've been fixing various issues to get to the release and one thing was about Z buffers, according to a recent recommendation by Bokujishin which took me into the projection matrix. I had been doing other VR fixes recently, including something about lighting exposure, which I have recently updated for the regular monitor version too. I'll probably do a report about some of the updates, but haven't been in a mind to slow down.
Now with VR and projection matrix in my mind, I was reminded of a bug report by vRenegade and I've been looking at that.
So hopefully this afternoon I can release a VR fix and an option for user to override the controller device type.
Now with VR and projection matrix in my mind, I was reminded of a bug report by vRenegade and I've been looking at that.
So hopefully this afternoon I can release a VR fix and an option for user to override the controller device type.
The way I implemented it, it does.
Joystick is past right stop.
Receives strong left force.
Accelerates left for a while.
No longer past right point, but still has velocity.
In split second, exceeds left end stop.
Receives strong right force.
Accelerates right until no longer past left bump stop.
In split second, exceeds right end stop.
etc...
The problem is that to provide a strong enough force to be felt, the acceleration is quite fast, if you are not holding the joystick. And a joystick can move to extremes so fast that there is no time for the game to react before it's already off the other side.
If you have tried making a joystick move to specific locations, you may have experienced the same trouble I have, with wild oscillations being the usual result. Personally, I have not been motivated to try to solve such an issue. The simple method (plain force, available on all FF devices) worked well for a wheel so I simply limited it to a wheel.
But this is really off topic, I'm not going to start trying to control the motion of FF joysticks of unknown mass, force capabilities, etc.
About end stop forces, I think you sort of missed my point. I'm not saying that end stop forces are dangerous for wheels, but specifically that they could cause undesirable effects for joysticks, because of the way joysticks can flick so fast from one side to the other. That's why I enabled them for wheels but not joysticks.
But you touched on a more important point about impact forces in conjunction with direct drives, though that is a different subject.
Anyway, I've thought of a possible interface, to allow the user to override the reported device type, see attachment.
But you touched on a more important point about impact forces in conjunction with direct drives, though that is a different subject.
Anyway, I've thought of a possible interface, to allow the user to override the reported device type, see attachment.
There's the answer!
The 'bug' is in the game controller driver software which is reporting DI8DEVTYPE_1STPERSON instead of DI8DEVTYPE_DRIVING.
LFS only implements self-centering when it is a wheel. There are two types of force that are only applied if it is a wheel.
1) After car is reset, the force slowly builds to try to centre the wheel.
2) Wheel out of bounds (end bump stops)
I believe I have done this as a safety measure or to stop LFS smashing up FF devices / children / etc. I don't really know what a DI8DEVTYPE_1STPERSON is but suppose it's a joystick, then applying a large force could fling the joystick right over the other side, when it could then receive the opposite force that flings it the other way, and you can end up with a wild flailing joystick.
I have to be a bit careful with FF devices and decided that these forces should be OK if the controller is a wheel. Of course we have a problem if the wheel manufacturers can't specify the correct device type.
Now I've got a vague memory of some direct drive wheels being reported as DI8DEVTYPE_GAMEPAD - not sure if I'm remembering correctly but I guess that will cause the same problem.
EDIT: Actually it was the Simucube, which was also reported as a 1st person controller. I got this as part of a reply when I contacted them in 2021:
EDIT2: I find it a bit frustrating that DEVTYPE is not a reliable way to recognise the type of device, despite the name, and that manufacturers basically aren't bothered about that. At the moment it looks like we will have to have some kind of override option:
FF device is actually a wheel although it is not reported as one: YES / NO
I wonder if you can think of a good way to add this to the interface, clearly, without taking up too much space, and such that users are unlikely to select it if they don't have a wheel.
Last edited by Scawen, .
This is not a bug.
You should post in Technical assistance and please post in English, even if you use google translate that would be helpful.
You should post in Technical assistance and please post in English, even if you use google translate that would be helpful.
Google translate:
hello first of all I played this game about 1 year ago and deleted it now I reinstalled it and my old settings came back but I didn't want it and I can't change it
my problem is I don't want to use the car with the mouse and I can't change it I set the car to automatic and the car doesn't go when I press w
please help
hello first of all I played this game about 1 year ago and deleted it now I reinstalled it and my old settings came back but I didn't want it and I can't change it
my problem is I don't want to use the car with the mouse and I can't change it I set the car to automatic and the car doesn't go when I press w
please help
We learned about that from a technical support email yesterday. I've only come across this forum post now.
There was some kind of connection problem. The server was restarted and then the same issue came up a few hours later, was restarted again and seems to be OK for now (around 16 hours). We don't yet know why it happened. It has been running for 3 years without a fault.
Feel free to post here again if the fault comes up again. I should get the email notification.
There was some kind of connection problem. The server was restarted and then the same issue came up a few hours later, was restarted again and seems to be OK for now (around 16 hours). We don't yet know why it happened. It has been running for 3 years without a fault.
Feel free to post here again if the fault comes up again. I should get the email notification.
I don't know the cause, but it looks as if it might be related to code pages and language settings.
Do you rename the files in any other way than through the LFS menu? For example, have you copied and renamed them in Windows file manager?
How do they look in the data\misc folder?
Do you sometimes change language settings on your computer?
What is the "language for non-Unicode programs" on your computer?
Do you rename the files in any other way than through the LFS menu? For example, have you copied and renamed them in Windows file manager?
How do they look in the data\misc folder?
Do you sometimes change language settings on your computer?
What is the "language for non-Unicode programs" on your computer?
Last edited by Scawen, .
The failed upload attempts don't all add up, they are overwritten by the next attempt, so hopefully you don't need another slot. I can't add an extra slot as we don't have a system to do that and I can't get into coding an exception.
About the Cloudflare upload timeout, I guess you have tried the option to not include the png files, to reduce the size of the upload? I can't do anything about that at this time because for me it would be a big project to make a new upload system, and Victor isn't willing to do it.
About the Cloudflare upload timeout, I guess you have tried the option to not include the png files, to reduce the size of the upload? I can't do anything about that at this time because for me it would be a big project to make a new upload system, and Victor isn't willing to do it.
Have you checked your email?
FGED GREDG RDFGDR GSFDG