Hmm, what to do? (fine in my Firefox too)
Images have max-width: 137px.
(137+10+1) * 7 + 1 = 1037 and the whole width is 1040. So 3 spare pixels according to my calculation!
Images have max-width: 137px.
(137+10+1) * 7 + 1 = 1037 and the whole width is 1040. So 3 spare pixels according to my calculation!
Rounds with sessions on different days now do appear on multiple days in the calendar (as a single entry).
EDIT: Moved posts about the text wrap issue to a bug report thread.
EDIT: Moved posts about the text wrap issue to a bug report thread.
Last edited by Scawen, .
I've made the code for the in-game list match the code on the season details page, so now LFS entry screen does show the host online.
Why it is in lower case and cannot be changed, I have no idea (remember I had no part in writing this system). Maybe at some point in the process the lower case version was entered and is somehow stuck that way. Maybe I'll find out some time but I'll get on with the other changes first.
Yes, I've been thinking that too.
Changes I want to do, related to feedback:
- Make multi day events appear on multiple days (but not showing each session, you can click to look at the event page for details.
- Have the current week at the top by default. Probably allow click forward or back 4 weeks at a time. Possibly allow month-based view as well though less important.
- Calendar as the default for leagues section, which I think should be renamed "Events" (unless someone has a better idea - to me "Leagues" at the top is a bit obscure as a way to find out what's on).
Changes I want to do, related to feedback:
- Make multi day events appear on multiple days (but not showing each session, you can click to look at the event page for details.
- Have the current week at the top by default. Probably allow click forward or back 4 weeks at a time. Possibly allow month-based view as well though less important.
- Calendar as the default for leagues section, which I think should be renamed "Events" (unless someone has a better idea - to me "Leagues" at the top is a bit obscure as a way to find out what's on).
Added a stream start time hover text to the stream logos.
It should be in your local time zone. Please could someone, who is not in GMT time zone, check if the hover text stream start time matches the stream start time shown in your LFS entry screen? EDIT: Thanks for the replies, I am sure it is OK now.
It should be in your local time zone. Please could someone, who is not in GMT time zone, check if the hover text stream start time matches the stream start time shown in your LFS entry screen? EDIT: Thanks for the replies, I am sure it is OK now.
Last edited by Scawen, .
I'm trying to think how to do that.
At first I thought of auto-scrolling using a # in the url but think that might not look too good.
Now I'm wondering if it could operate in two different modes: weekly or monthly.
- Weekly mode could be the default start with the current week and have e.g. 3 extra weeks below.
- Monthly mode could be an option to show traditional calendar style as now.
Maybe someone has a better idea.
At first I thought of auto-scrolling using a # in the url but think that might not look too good.
Now I'm wondering if it could operate in two different modes: weekly or monthly.
- Weekly mode could be the default start with the current week and have e.g. 3 extra weeks below.
- Monthly mode could be an option to show traditional calendar style as now.
Maybe someone has a better idea.
I've done a bit of holiday work on the calendar, with a bit of help with html from my son Leo (who isn't actually an expert but knows more than me how it works).
Here is the updated calendar: https://www.lfs.net/leagues/calendar
Compare with old calendar: https://www.lfs.net/leagues/calendarOLD.php
Based on changed planned in Victor's post here: https://www.lfs.net/forum/post/1995602#post1995602
Developed from the original calendar, with inspiration from Mandula's one-week calendars and the in-game events feed.
Here is the updated calendar: https://www.lfs.net/leagues/calendar
Compare with old calendar: https://www.lfs.net/leagues/calendarOLD.php
Based on changed planned in Victor's post here: https://www.lfs.net/forum/post/1995602#post1995602
Developed from the original calendar, with inspiration from Mandula's one-week calendars and the in-game events feed.
Yes, they are blended to avoid sharp transitions. I use a spherical distance from view point rather than Z, so the transition doesn't move if you rotate the view without moving.
We don't use PCF. Softening or antialiasing is done using MSAA which is possible with ESM.
We don't use PCF. Softening or antialiasing is done using MSAA which is possible with ESM.
Well... that is to do with the way shadow mapping is done. It's all a big trick, of course, and the resulting image has shadow sharpness varying in a different way from reality. As you say, in reality the sharpness of a sun shadow decreases with the distance between caster and receiver. But the method of shadow mapping results in shadows being sharper when they are nearer to the viewer.
If you are interested enough for a long read, there is a really good article on the Microsoft website which goes through the whole method, issues and solutions. It's relevant to ours to about half way down the page.
https://learn.microsoft.com/en-us/windows/win32/dxtecharts/cascaded-shadow-maps
Our shadow maps are "cascaded shadow maps" using an implementation of "exponential shadow maps" or ESM rather than VSM described at the end of that article.
If you are interested enough for a long read, there is a really good article on the Microsoft website which goes through the whole method, issues and solutions. It's relevant to ours to about half way down the page.
https://learn.microsoft.com/en-us/windows/win32/dxtecharts/cascaded-shadow-maps
Our shadow maps are "cascaded shadow maps" using an implementation of "exponential shadow maps" or ESM rather than VSM described at the end of that article.
I haven't checked here yet but I've been looking on the internet and apparently thing may be affected by a "Steering Sensitivity" setting in the Logitech software.
https://steamcommunity.com/app/227300/discussions/0/1639787494950318456/
EDIT: Also you may be able to check if the non-linearity comes from the wheel/driver software by looking at the raw output values at the bottom right of the Options - Controls screen. Those are the raw input values that LFS receives from the software.
https://steamcommunity.com/app/227300/discussions/0/1639787494950318456/
EDIT: Also you may be able to check if the non-linearity comes from the wheel/driver software by looking at the raw output values at the bottom right of the Options - Controls screen. Those are the raw input values that LFS receives from the software.
Last edited by Scawen, .
Before I start up the other computer (with G29) to check, can I ask you to check with the official GTR cars?
They have 540 degrees of lock. You can see that in "Steering" (section of the Garage/Pits screen) some text:
Car's steering wheel turns 540 degrees (lock to lock)
I guess you see this same info text with your testing car, but please check to confirm that.
I suggest testing with an official car, or a specific mod that we all have access to, so we can compare results.
They have 540 degrees of lock. You can see that in "Steering" (section of the Garage/Pits screen) some text:
Car's steering wheel turns 540 degrees (lock to lock)
I guess you see this same info text with your testing car, but please check to confirm that.
I suggest testing with an official car, or a specific mod that we all have access to, so we can compare results.
I wrote something about that in 2021, but you replied there so I'm not sure what issue there is now.
https://www.lfs.net/forum/post/1977600#post1977600
It actually isn't very complicated. Wheel turn compensation (which is recommended to be set to max) does two different things depending on if the game controller wheel turns more or less than the in-game car wheel.
1) Game controller wheel can turn more than the simulated car steering wheel:
Perfect match is possible.
Game controller wheel stops turning (a 'stop force' is applied) when simulated car steering wheel reaches limits.
2) Game controller wheel can not turn as much as the simulated car steering wheel:
Perfect match is not possible.
Non-linear approach is implemented.
Steering wheel turn amount matches in the middle, but simulated car wheel turns more as you increase the steering angle.
NOTE: This relies on the "Wheel turn" setting in Options - Controls matching your controller wheel turn degrees. E.g. if your game controller turns 900 degrees, then "Wheel turn" must be set to 900.
EDIT: If I am missing something, or some bug has crept in, I would obviously like to know about it. But when I have checked in the past, it's all working as it should.
https://www.lfs.net/forum/post/1977600#post1977600
It actually isn't very complicated. Wheel turn compensation (which is recommended to be set to max) does two different things depending on if the game controller wheel turns more or less than the in-game car wheel.
1) Game controller wheel can turn more than the simulated car steering wheel:
Perfect match is possible.
Game controller wheel stops turning (a 'stop force' is applied) when simulated car steering wheel reaches limits.
2) Game controller wheel can not turn as much as the simulated car steering wheel:
Perfect match is not possible.
Non-linear approach is implemented.
Steering wheel turn amount matches in the middle, but simulated car wheel turns more as you increase the steering angle.
NOTE: This relies on the "Wheel turn" setting in Options - Controls matching your controller wheel turn degrees. E.g. if your game controller turns 900 degrees, then "Wheel turn" must be set to 900.
EDIT: If I am missing something, or some bug has crept in, I would obviously like to know about it. But when I have checked in the past, it's all working as it should.
Last edited by Scawen, .
A viewer is now built in to LFS, which works with all default vehicles and mods too.
You can save your skin jpg to data\skins and click the "Viewer" button near bottom left of the garage screen after creating "New colours" with the new skin. In viewer mode you will find features similar to the old CMX viewer, including a reload button.
You can save your skin jpg to data\skins and click the "Viewer" button near bottom left of the garage screen after creating "New colours" with the new skin. In viewer mode you will find features similar to the old CMX viewer, including a reload button.
I think you need to click "other controllers" then don't select one of them.
As soon as you select one of them, that is the only one it will use. If you don't select one, then axes and buttons from all of them will be available.
As soon as you select one of them, that is the only one it will use. If you don't select one, then axes and buttons from all of them will be available.
It may be you are selecting one of the devices, listed at top right of the controller options.
This has confused quite a few people. You should not select one of the devices, but instead allow all to be active.
This has confused quite a few people. You should not select one of the devices, but instead allow all to be active.
The trs files in the data\knw folder.
Here is the complete set of tracks that have changed significantly.
New versions:
https://www.lfs.net/file_lfs.php?name=SO_new_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_new_3072.zip
https://www.lfs.net/file_lfs.php?name=AU_new_2560.zip
https://www.lfs.net/file_lfs.php?name=AS_new_2560.zip
Old versions:
https://www.lfs.net/file_lfs.php?name=SO_old_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_old_3072.zip
https://www.lfs.net/file_lfs.php?name=AU_old_2560.zip
https://www.lfs.net/file_lfs.php?name=AS_old_2560.zip
Other tracks (BL/FE/WE/RO/LA) have not changed significantly. Changes are mostly fixes, details and textures updated for the new lighting and shadow system, so I have not generated 2D bitmaps for them.
New Westhill included for comparison with new Kyoto:
https://www.lfs.net/file_lfs.php?name=WE_new_3072.zip
Here's a zip with the old SO and KY generated as 3072.
I think they are the current public ones, but without any ambient lighting.
I didn't include the old WE as it hasn't changed significantly, other than textures and details.
EDIT: Changed to two separate zips.
https://www.lfs.net/file_lfs.php?name=SO_old_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_old_3072.zip
Last edited by Scawen, .
Here are some zips with 2D top down views of updated South City and Kyoto Ring in 3072x3072 png.
EDIT: for comparison I've also generated Westhill in the same format.
https://www.lfs.net/file_lfs.php?name=SO_new_3072.zip
https://www.lfs.net/file_lfs.php?name=KY_new_3072.zip
https://www.lfs.net/file_lfs.php?name=WE_new_3072.zip
Note: some of the newly filled in areas of South City are not actually driveable. There are so many new driveable areas but to get the job finished there has to be some scenery which is not updated to full detail level.
Last edited by Scawen, .
I hope it's OK to post these route images, with the disclaimer that any configuration could be be revised or removed.
Last edited by Scawen, .
Graphics Progress Report: Kyoto updates
Hello Racers,
Eric has spent most of this year working on the Kyoto Ring environment and has expanded the driveable areas in a similar way to the Westhill track. In open configurations, you can drive around all the access roads and a new high speed karting track has been added.
To read about our progress and see some pictures of the Kyoto updates, visit the Kyoto Progress Report page.
- LFS Developers
Eric has spent most of this year working on the Kyoto Ring environment and has expanded the driveable areas in a similar way to the Westhill track. In open configurations, you can drive around all the access roads and a new high speed karting track has been added.
To read about our progress and see some pictures of the Kyoto updates, visit the Kyoto Progress Report page.
- LFS Developers
Thanks. Based on your description and the log file and the thread you linked to, I think I can see what's going wrong.
As you say, the screen resolution is 1:1 but the strange thing on your headset is this is not matched by the projection.
E.g. for left eye: GetProjectionMatrix: Left -1.635 Right 0.833 Top -1.118 Bottom 1.122
This gives X/Y of (1.635 + 0.833) / (1.118 + 1.122) = 2.468 / 2.24 = 1.102
Those values are tangents of FOV in each direction so can be safely added before the division. The problem is the result is 1.102, not 1.
For comparison with my Vive DVT, I get this result:
Resolution per eye: 1512 x 1680 giving aspect ratio 0.9
Left eye: GetProjectionMatrix: Left -1.391 Right 1.254 Top -1.473 Bottom 1.466
This gives X/Y of (1.391 + 1.254) / (1.473 + 1.466) = 2.645 / 2.939 = 0.89997
So that is basically a perfect match for the resolution aspect ratio.
So I suppose at this point that the Vive Pro 2 either has non-square pixels or uses anamorphic lenses.
I'm not sure of the solution yet, it seems that LFS will need to scale the image vertically or horizontally. I'll need to look into the code and see how it is worked out and where to insert the correction.
I'm guessing that it wouldn't be anamorphic lenses, more likely non-square pixels but it's a long time since I have encountered that. I'm thinking of Mode 13h from MS-DOS days in late 80s / early 90s.
As you say, the screen resolution is 1:1 but the strange thing on your headset is this is not matched by the projection.
E.g. for left eye: GetProjectionMatrix: Left -1.635 Right 0.833 Top -1.118 Bottom 1.122
This gives X/Y of (1.635 + 0.833) / (1.118 + 1.122) = 2.468 / 2.24 = 1.102
Those values are tangents of FOV in each direction so can be safely added before the division. The problem is the result is 1.102, not 1.
For comparison with my Vive DVT, I get this result:
Resolution per eye: 1512 x 1680 giving aspect ratio 0.9
Left eye: GetProjectionMatrix: Left -1.391 Right 1.254 Top -1.473 Bottom 1.466
This gives X/Y of (1.391 + 1.254) / (1.473 + 1.466) = 2.645 / 2.939 = 0.89997
So that is basically a perfect match for the resolution aspect ratio.
So I suppose at this point that the Vive Pro 2 either has non-square pixels or uses anamorphic lenses.
I'm not sure of the solution yet, it seems that LFS will need to scale the image vertically or horizontally. I'll need to look into the code and see how it is worked out and where to insert the correction.
I'm guessing that it wouldn't be anamorphic lenses, more likely non-square pixels but it's a long time since I have encountered that. I'm thinking of Mode 13h from MS-DOS days in late 80s / early 90s.
The aspect ratio and all other relevant info should be obtained through the interface. Maybe you could post the contents of openvr.log and we'll see if there are any clues in there?
Could you give a more detailed explanation of the skewing issue? Is it only apparent when your head is doing the roll, or does it remain visible while you hold your head in a rolled position?
Could you give a more detailed explanation of the skewing issue? Is it only apparent when your head is doing the roll, or does it remain visible while you hold your head in a rolled position?
I can't see any glitches on our performance graph, and a network test now shows very little packet loss, so I wonder if the problem has been resolved?
The graph looks clean from around 18:00 UTC on Saturday (7 December).
The graph looks clean from around 18:00 UTC on Saturday (7 December).
I've restarted the server so it should be up and running again.
I think there is still a high level of packet loss so that means our provider is responsible. It looks as if the change they made some months ago, that improved the service, is no longer effective. For some reason this changed in the past few days, so I will raise a ticket with our provider.
I think there is still a high level of packet loss so that means our provider is responsible. It looks as if the change they made some months ago, that improved the service, is no longer effective. For some reason this changed in the past few days, so I will raise a ticket with our provider.
FGED GREDG RDFGDR GSFDG