What changed a few weeks ago? Did you install a new graphics driver at that time? Can you try reverting to an older graphics driver? Nothing changed in LFS, so it sounds to me like a fault in the graphics driver or D3D.
Your thread title says "D3D device error" but you didn't include that in your report. If LFS gives this message it suggests that the instance of Direct3D 9 reported an error and had to be restarted. Could there be a problem with the D3D9 support, which is not used by most games now?
EDIT: It's possible there could be a clue in the deb.log file after the hang, a message including a D3DERR_xxx value.
Something like:
D3D device error : D3DERR_xxx
Maybe the missing part in place of 'xxx' can give us a clue.
Your thread title says "D3D device error" but you didn't include that in your report. If LFS gives this message it suggests that the instance of Direct3D 9 reported an error and had to be restarted. Could there be a problem with the D3D9 support, which is not used by most games now?
EDIT: It's possible there could be a clue in the deb.log file after the hang, a message including a D3DERR_xxx value.
Something like:
D3D device error : D3DERR_xxx
Maybe the missing part in place of 'xxx' can give us a clue.
Last edited by Scawen, .
Yes I think that should be possible, the two screen assumption could be avoided if the primary monitor rectangle matches the desktop rectangle. I've made a note about it.
Hi, LFS has taken a guess that you have a two screen setup.
You can correct this, in the Options - View screen.
There is an option "Multiple screen layout" where you will see it is set to 1 left screen.
You can set that to zero and then it will work as a single wide screen.
You can correct this, in the Options - View screen.
There is an option "Multiple screen layout" where you will see it is set to 1 left screen.
You can set that to zero and then it will work as a single wide screen.
While I am sure your suggestions are sensible, I am not working on the vehicle editor as part of this release. the idea is to get the new version released, so I then have time to work on other things including vehicle editor improvements. Please feel free to post vehicle editor suggestions in the correct forum section: https://www.lfs.net/forum/532
The current plan is to avoid delaying the release for clouds. I love clouds and will miss them in the early versions of new LFS. But it's a big job with many technical difficulties and that's why there will be no clouds at first, although I do want to allow completely overcast (i.e. the whole sky is a cloud).
It's a tricky issue at the moment and that is one thing lacking in the vehicle system at the moment. We really need some way to separate the parts of the dashboard that are illuminated by the environment (in traditional dashboards that are not just a computer screen) and the other parts that are self-illuminated like lights and the modern screens. I'm sure that in real life these modern screens must adjust their brightness a great deal depending on the lighting conditions, to be visible in the day but not completely blinding in the night. In some way, all our dashboards in LFS are self-illuminated like the modern computer screens, so I think they will have to start out light-sensitive and self-adjusting, even if that is unrealistic. Awaiting the more proper dashboard support mentioned above. I've probably not explained myself very well.
It's a completely new system with D3D11 graphics, dynamic lighting, 1000Hz physics, multithreading, dynamic echo rendering. It's not a thing you could release half of.
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
end of EDIT ]
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
end of EDIT ]
Last edited by Scawen, .
There is no plan to release track editor in the near future. It's kind of a long term dream of something that may or may not happen. It would probably be a year or two or more of work like the vehicle mods. It's difficult to even imagine how it could work and the tracks would be distributed. It can't work like the vehicle mods. Anyway, I say this not to start a discussion about the track editor, that I cannot get involved in at this time, but to make sure people don't have false hopes. I simply added a few more features to help Eric use the track editor, as I have been doing for the last 25 years or so.
That message is probably because last time you started LFS, the headset was not connected. We need to see the openvr.log after a successful entry to VR.
In LFS there are only two options, OpenVR and Oculus Rift. I believe OpenVR is the only choice for most headsets, but all the Meta ones can use "Oculus Rift" which I should probably rename. But I'll need to know if it does work on Meta headsets... or maybe the whole option should be deleted.
To select Oculus, start LFS in the normal way (not VR) and then:
Options - View
At top of screen is a 3D button.
Click that button and you can select Oculus Rift.
It would be good to know if that works. If not, then try OpenVR again and you can paste that log result, I'll have a look and see if there are any clues in there.
In LFS there are only two options, OpenVR and Oculus Rift. I believe OpenVR is the only choice for most headsets, but all the Meta ones can use "Oculus Rift" which I should probably rename. But I'll need to know if it does work on Meta headsets... or maybe the whole option should be deleted.
To select Oculus, start LFS in the normal way (not VR) and then:
Options - View
At top of screen is a 3D button.
Click that button and you can select Oculus Rift.
It would be good to know if that works. If not, then try OpenVR again and you can paste that log result, I'll have a look and see if there are any clues in there.
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.7F6
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.7F6
Please read the list of changes below.
0.7F6 is COMPATIBLE with 0.7F
- You CAN connect online with 0.7F
- You CAN play single player replays from 0.7F
You should back up or rename your LFS.exe from version F so you can revert to it if necessary.
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!
- Rename your old LFS.exe
- Copy the LFS.exe from this patch zip into your LFS folder
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.7F6 (ZIP)
https://www.lfs.net/file_lfs.p ... e=LFS_PATCH_7F_TO_7F6.zip (1.1 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.7F6
Please read the list of changes below.
0.7F6 is COMPATIBLE with 0.7F
- You CAN connect online with 0.7F
- You CAN play single player replays from 0.7F
You should back up or rename your LFS.exe from version F so you can revert to it if necessary.
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!
- Rename your old LFS.exe
- Copy the LFS.exe from this patch zip into your LFS folder
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.7F6 (ZIP)
https://www.lfs.net/file_lfs.p ... e=LFS_PATCH_7F_TO_7F6.zip (1.1 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.
FGED GREDG RDFGDR GSFDG