Yeah I've been looking around, it's pretty hard to unpick as there are a lot of functions calling others and conditional interactions between javascript and php.
It's too complicated for me now as long past my bed time. Trying to figure out other people's code isn't my favourite task. Maybe I can unpick this stuff a bit tomorrow.
But can I ask one question, is that session variable correct for you? I mean... do you see the calendar on the correct day, i.e. moving into the next day as the "current day" before UTC is actually at that day? Just wondering if my offset is zero because that is sort of in my session already, so it's not "tricked" by me changing the Windows time zone.
It's too complicated for me now as long past my bed time. Trying to figure out other people's code isn't my favourite task. Maybe I can unpick this stuff a bit tomorrow.
But can I ask one question, is that session variable correct for you? I mean... do you see the calendar on the correct day, i.e. moving into the next day as the "current day" before UTC is actually at that day? Just wondering if my offset is zero because that is sort of in my session already, so it's not "tricked" by me changing the Windows time zone.
I see... or I think I understand what you are saying but I still don't really understand why it worked fine on my computer. 
For further confusion, and answering your question, I was able to manually adjust the time using a value called LFS::$session->vars['timeOffset'] which I understand to be a time zone offset.
But I'm not really sure what's happening now, as it seems sometimes that offset is set to zero, even though I have set a different time zone in Windows. It comes from a $_GET['t'] value at some point.
That offset being zero seems to be why my calendar still shows me in Thursday when my timezone is actually UTC+1 at the moment.
For further confusion, and answering your question, I was able to manually adjust the time using a value called LFS::$session->vars['timeOffset'] which I understand to be a time zone offset.
But I'm not really sure what's happening now, as it seems sometimes that offset is set to zero, even though I have set a different time zone in Windows. It comes from a $_GET['t'] value at some point.
That offset being zero seems to be why my calendar still shows me in Thursday when my timezone is actually UTC+1 at the moment.
OK, I've changed it to follow the convention.
But I don't see the harm in initialising with the already converted time, it seems to me that it just avoids a 1 frame glitch when you reload the page.
When initialising with the UTC text, it is at first visible at UTC then a split second later changes to the local time for the selected timezone.
EDIT: I've found that it still thinks I am in Thursday, even though I set my timezone to UTC + 1 and that is really Friday now... looking into it...
But I don't see the harm in initialising with the already converted time, it seems to me that it just avoids a 1 frame glitch when you reload the page.
When initialising with the UTC text, it is at first visible at UTC then a split second later changes to the local time for the selected timezone.
EDIT: I've found that it still thinks I am in Thursday, even though I set my timezone to UTC + 1 and that is really Friday now... looking into it...
Last edited by Scawen, .
Nice detective work there! I've reinstated the original code now without the "bold" and fixed the same issue in another few places.
Maybe your browser has a bug with data-format="time" ?
Instead of relying on that time tag I've now coded it manually instead, so I think it should work for you now.
Instead of relying on that time tag I've now coded it manually instead, so I think it should work for you now.
Oh, that is strange. It looks fine to me in Firefox if I go to UTC+1 timezone (the UTC hover text is an hour off from the visible text). I did have to refresh the page after changing time zone but then it looked correct.
It uses an html <time> element which in my browser shows local time normally but UTC time when hovering. It's the same with these forum post times (Today: 21:15) etc.
It uses an html <time> element which in my browser shows local time normally but UTC time when hovering. It's the same with these forum post times (Today: 21:15) etc.
I hope all the time zone stuff works properly, it's always confusing to implement and made my day's task a lot harder. Especially when we are dealing with things displayed near day and month boundaries, and must be placed and displayed in the correct day slot, and the viewer can be in any time zone, at any time, and select any month or week to view.
I'd obviously like to know if there are any errors with time zones.
A simple test is if someone could compare the in-game event browser with the website calendar and make sure it looks correct. Hovering over the event time should show the UTC time, in case that is useful.
One test I should do is set my timezone to somewhere far from UTC and confirm that some events fall into a different day or month on the calendar because of the time zone of the observer. But I'm a bit tired now, probably will test tomorrow.
I don't plan to do any more on this stuff for now except for any fixes. Really it was some holiday work but has gone on 4 extra days and we all know what I really have to work on now.
I hope the calendar and league section improvements are helpful.
I'd obviously like to know if there are any errors with time zones.
A simple test is if someone could compare the in-game event browser with the website calendar and make sure it looks correct. Hovering over the event time should show the UTC time, in case that is useful.
One test I should do is set my timezone to somewhere far from UTC and confirm that some events fall into a different day or month on the calendar because of the time zone of the observer. But I'm a bit tired now, probably will test tomorrow.
I don't plan to do any more on this stuff for now except for any fixes. Really it was some holiday work but has gone on 4 extra days and we all know what I really have to work on now.
I hope the calendar and league section improvements are helpful.
I've now made the calendar default to a weekly view, in which only one week is shown and you can click back and forward through the weeks.
That's more useful when you want to find out what's on this week. You can also switch to monthly view as before.
https://www.lfs.net/leagues/calendar
That's more useful when you want to find out what's on this week. You can also switch to monthly view as before.
https://www.lfs.net/leagues/calendar
Thanks, the in-game entry screen only showed events whose first round was less than 36 hours ago. This allowed for 24 hour races and two-day events, but not three-day events.
I've increased that limit to 3 days instead of 36 hours, so the second part of your multi day round of one of your concurrent series now appears in the in-game calendar.
EDIT: Also added the option to delete a round. At the bottom of 'edit round' page (like deleting a season).
I've increased that limit to 3 days instead of 36 hours, so the second part of your multi day round of one of your concurrent series now appears in the in-game calendar.
EDIT: Also added the option to delete a round. At the bottom of 'edit round' page (like deleting a season).
Last edited by Scawen, .
One more question, on cleaning up the website...
Does anyone still use IRC?
I could remove the section from this page: https://www.lfs.net/links
Does anyone still use IRC?
I could remove the section from this page: https://www.lfs.net/links
Some updates:
Main page of website:
Removed text "Discover the realism of racing simulation..."
Updated events today on main page (using new calendar info)
Leagues:
FIX: Stream start time was not stored when first adding a round
Stream start time is now shown on round and season pages
Calendar:
Changed section name to Events rather than Leagues
Default page in Events section is now Calendar
Limited height of images (for taller aspect ratio images)
Replaced (some) links in description text with [link] to reduce length
Still to do:
Make calendar show current week as the top line by default
EDIT: Is it true that there is no way to DELETE a round of a series?
Main page of website:
Removed text "Discover the realism of racing simulation..."
Updated events today on main page (using new calendar info)
Leagues:
FIX: Stream start time was not stored when first adding a round
Stream start time is now shown on round and season pages
Calendar:
Changed section name to Events rather than Leagues
Default page in Events section is now Calendar
Limited height of images (for taller aspect ratio images)
Replaced (some) links in description text with [link] to reduce length
Still to do:
Make calendar show current week as the top line by default
EDIT: Is it true that there is no way to DELETE a round of a series?
Last edited by Scawen, .
I've solved the problem now by replacing words starting with 'http' or 'www.' with '[link]'
It's not actually a link but if they click it they will end up on the round's page so maybe this is OK at least for now. Though I realise they might write a link without any http or www.
It's not actually a link but if they click it they will end up on the round's page so maybe this is OK at least for now. Though I realise they might write a link without any http or www.
I've added: style="overflow-wrap: break-word" to the description text.
Does it help?
Does it help?
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, .
FGED GREDG RDFGDR GSFDG