Fortunately, that danger doesn't actually exist. The links on the page go to our real site. The scammers aren't trying to take over LFS user accounts. It looks like the only purpose of their fake forums is to produce conversations showing how happy people are with the car they got, and how a return was very easy when they had to send it back because their wife was expecting a different colour, etc.
There's no real reason to think an LFS user would stumble across that site. The three people that have contacted us about it were not LFS users, and only registered to tell us about the scam they came across, by searching for Pilling Motor Group.
EDIT: I don't know why they were searching for PMG in the first place...
There's no real reason to think an LFS user would stumble across that site. The three people that have contacted us about it were not LFS users, and only registered to tell us about the scam they came across, by searching for Pilling Motor Group.
EDIT: I don't know why they were searching for PMG in the first place...
Last edited by Scawen, .
I don't know why they chose our site as one of the identities to copy. But if you search for Pilling Motor Group in Google or DuckDuckGo, the fake version of our forum and another fake forum do come up in the results.
The main idea of my post isn't really to warn LFS members in particular, but more to make sure there is some information visible on the internet. We already asked their hoster to take down the site (with full description and analysis) but as usual with such requests, we have been ignored.
The main idea of my post isn't really to warn LFS members in particular, but more to make sure there is some information visible on the internet. We already asked their hoster to take down the site (with full description and analysis) but as usual with such requests, we have been ignored.
Last edited by Scawen, .
Scam: Pilling Motor Group
We have received reports of a scam using the name of Pilling Motor Group.
The scammers have set up fake websites including a fake version of our forum, with fake conversations between non-existent users to try to give an appearance of legitimacy to their fraudulent operation.
I want to make it clear that the fake version of our forum is in no way supported by us.
If you visit a website, they will know your IP address, so I do not think you should visit the website. But for your information, the fake forum is at liveforspeed.uk - a domain that we do not own.
There is a full write up about the scam on this blogspot page:
https://pmgltdscam.blogspot.com/2019/09/dealers-of-car-pilling-motor-group-ltd.html
As far as I can see, this is a scam set up to try to get money from people who think they are buying a car but it will never be delivered. Fake identities and a fake website have been set up, while using the name of a genuine company (a small garage) that actually exists but is in no way involved with this scam.
The scammers have set up fake websites including a fake version of our forum, with fake conversations between non-existent users to try to give an appearance of legitimacy to their fraudulent operation.
I want to make it clear that the fake version of our forum is in no way supported by us.
If you visit a website, they will know your IP address, so I do not think you should visit the website. But for your information, the fake forum is at liveforspeed.uk - a domain that we do not own.
There is a full write up about the scam on this blogspot page:
https://pmgltdscam.blogspot.com/2019/09/dealers-of-car-pilling-motor-group-ltd.html
As far as I can see, this is a scam set up to try to get money from people who think they are buying a car but it will never be delivered. Fake identities and a fake website have been set up, while using the name of a genuine company (a small garage) that actually exists but is in no way involved with this scam.
Last edited by Scawen, .
Yes, one thing really leads to another as you mentioned in your post in the February report. The blended skies had certain issues that were solved by these realtime skies whose code has kindly been made available on the internet with a permissive license. But it took a while to get them in and they resulted in a lot of changes to how the system works.
About bump mapping, Eric has asked for that a long time ago but I am not keen to develop it now, with the extra shaders and more data for every vertex, and increased data bandwidth and GPU usage for the pixel shaders. I'm very interested in trying to keep the frame rates high and see how it goes with the current version, that is already a lot heavier than the old. Also for me it doesn't seem totally straightforward to implement, when starting to think about helper functions for the normal maps and new material types to support the maps. There's too much in my mind already and I don't want to get bogged down so for now I really think the other things have a higher priority. In my mind the bump maps can be done after this release as I think Eric has made very good use of the current system with the updated tracks. Then various materials could be updated to take advantage of bump mapping.
It's a good question and I don't know the answer but I'll try to do something simple at first and see how it looks.
Yes there are still some holes, Kyoto is not yet finished. Eric was doing so many adjustments of corners and so on, he wanted a break to do something new so he has moved onto South City for now where he can get some more visible results in a shorter time.
Thank you!
July Progress Report
Hello Racers.
We know you would like to know what we have been working on, so we have prepared a new progress report.
It is a bit technical but may be interesting for some people. Anyway there are some nice pictures too.
Scawen
We know you would like to know what we have been working on, so we have prepared a new progress report.
It is a bit technical but may be interesting for some people. Anyway there are some nice pictures too.
Scawen
Thanks everyone for the feedback.
Yes, from the point of view of force feedback, no higher frame rate than 100 should make a difference.
Less than 100 fps will reduce the number of FF updates you get (because there is never more than one FF change per visual frame, which will be the case as long as LFS runs graphics and physics on the same thread) so going lower than 100 fps makes a difference that may be perceptible on the very high end wheels.
I didn't want to bother explaining how the old system worked, now that it has been deleted. But as people like to understand, here goes:
In the old system, there was some code that reduced the number of FF updates sent from LFS to the wheel drivers (to avoid overload which was a problem in the past, and may still be now, for some wheels) by making sure some number of frames had elapsed since the previous FF update. That number of frames depended on how different the current force was to the last force sent (more different, less frames needed to elapse). The relevant point is that it was related to a number of frames, so people discovered that having otherwise pointless frame rates like 1000 fps gave them more immediate force feedback. Now that code is gone, and you can set to allow 100 Hz FF updates, there is no need to use extremely high frame rates as you can't get higher then 100 Hz FF updates anyway.
Yes, from the point of view of force feedback, no higher frame rate than 100 should make a difference.
Less than 100 fps will reduce the number of FF updates you get (because there is never more than one FF change per visual frame, which will be the case as long as LFS runs graphics and physics on the same thread) so going lower than 100 fps makes a difference that may be perceptible on the very high end wheels.
I didn't want to bother explaining how the old system worked, now that it has been deleted. But as people like to understand, here goes:
In the old system, there was some code that reduced the number of FF updates sent from LFS to the wheel drivers (to avoid overload which was a problem in the past, and may still be now, for some wheels) by making sure some number of frames had elapsed since the previous FF update. That number of frames depended on how different the current force was to the last force sent (more different, less frames needed to elapse). The relevant point is that it was related to a number of frames, so people discovered that having otherwise pointless frame rates like 1000 fps gave them more immediate force feedback. Now that code is gone, and you can set to allow 100 Hz FF updates, there is no need to use extremely high frame rates as you can't get higher then 100 Hz FF updates anyway.
Last edited by Scawen, .
Direct Drive Wheels - New FF patch and information request
For racers who have a Direct Drive wheel, Test Patch U7 has some new settings that allow you to remove a notchy force feeling and receive force updates with the minimum delay. And there is no longer a reason to use frame rates above 100 fps.
For OSW wheels the recommended settings are:
FF Steps -> 10000 (for max resolution allowed by DirectInput)
FF Rate -> 100 Hz (allows FF updates to match LFS physics rate)
I am interested to know if these are the best settings for all direct drive wheels. And to allow for the possibility of automatic presets, it would be useful to know the exact name of your wheel as it appears in LFS (see attached screen shot).
Download: https://www.lfs.net/forum/thread/93185
The update does allow better settings for ordinary geared wheels too, but it is not recommended to go for the maximum. The default settings (Steps 400 Steps / Rate 50 Hz) may be all you need.
For OSW wheels the recommended settings are:
FF Steps -> 10000 (for max resolution allowed by DirectInput)
FF Rate -> 100 Hz (allows FF updates to match LFS physics rate)
I am interested to know if these are the best settings for all direct drive wheels. And to allow for the possibility of automatic presets, it would be useful to know the exact name of your wheel as it appears in LFS (see attached screen shot).
Download: https://www.lfs.net/forum/thread/93185
The update does allow better settings for ordinary geared wheels too, but it is not recommended to go for the maximum. The default settings (Steps 400 Steps / Rate 50 Hz) may be all you need.
As the Fanatec is direct drive, have you tried the new settings in the test patch?
For OSW wheels the recommended settings are:
FF Steps -> 10000 for max resolution allowed by DirectInput
FF Rate -> 100 Hz allows FF updates to match LFS physics rate
For OSW wheels the recommended settings are:
FF Steps -> 10000 for max resolution allowed by DirectInput
FF Rate -> 100 Hz allows FF updates to match LFS physics rate
Thanks for the feedback, I hoped the new (simpler, user controlled) filtering would be better with geared wheels too. I don't think you need the new settings up to max on geared wheels because they are a bit notchy anyway.
Thanks for the feedback, good to hear the patch solves the update problems.
For the OSW you should get Test Patch U7 and use the following settings:
Options - Controls screen:
Axes / FF tab:
FF Steps -> maximum
FF Rate -> maximum
For the OSW you should get Test Patch U7 and use the following settings:
Options - Controls screen:
Axes / FF tab:
FF Steps -> maximum
FF Rate -> maximum
I think so, yes, and I think that should feel a bit more direct and immediate than previous versions. But please do tell me if not, because it's hard to know and these default settings involve some guessing! It seemed fine on my G27 but I haven't tested on other wheels.
Which headset are you using?
For Open VR these files should be in your dll folder:
LFSOpenVR.dll
openvr_api.dll
For Open VR these files should be in your dll folder:
LFSOpenVR.dll
openvr_api.dll
The idea of the new settings is for high end, direct drive FF wheels you may wish to go for the maximum value of FF Steps and FF Rate. This will give you the maximum number of updates from LFS physics, at the maximum resolution allowed by DirectInput.
On lower end wheels (standard wheels with gears or belts) there will not be so much benefit in going for these high update rates and there may be a CPU cost and possibly lag if you go for the full unlimited rate. So I suggest you don't go higher than you need if the difference is not noticeable on your wheel.
About the connection between visual frame rates and force feedback:
In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).
On lower end wheels (standard wheels with gears or belts) there will not be so much benefit in going for these high update rates and there may be a CPU cost and possibly lag if you go for the full unlimited rate. So I suggest you don't go higher than you need if the difference is not noticeable on your wheel.
About the connection between visual frame rates and force feedback:
In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).
Test Patch U7:
Force Feedback:
New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)
VR:
Names over cars could fade differently in each eye in Pimax headset
Misc:
Gearshift debounce maximum setting restored to 200 ms (default 20)
More translations updated - thank you translators!
Download: https://www.lfs.net/forum/thread/93185
Force Feedback:
New settings are available under Axes / FF in Options - Controls
FF Steps maximum value is now 10000 (the maximum in DirectInput)
FF Rate is now controlled by a user setting (25 / 50 / 100 Hz)
VR:
Names over cars could fade differently in each eye in Pimax headset
Misc:
Gearshift debounce maximum setting restored to 200 ms (default 20)
More translations updated - thank you translators!
Download: https://www.lfs.net/forum/thread/93185
I think you could set it to 100 and then you'll get a 90 Hz output. It would always output the steering torque from the last physics update.
I'm planning to add these settings to the Axes / FF tab in Options - Controls so we can see the effect more quickly.
I'm planning to add these settings to the Axes / FF tab in Options - Controls so we can see the effect more quickly.
I can see why going to a very high frame rate can help get more force updates. The output is limited in a way that does depend on the frame rate. It's really old code and I'm not happy with how that works. Ideally there should be no advantage in going above 100 fps.
I think I need to make a change that allows the force output to be limited in a controllable way that does not depend on the frame rate (if the frame rate is 100 Hz or higher).
I'm thinking we need two settings.
1) FF Steps : from about 500 to 10000
2) FF Max Update Rate : from about 25 to 100 Hz
For a high end wheel like yours you would set both to the maximum and that would allow the best connection between LFS and DirectInput, if your frame rate was 100 Hz. In that case there could be an output after every physics update, if the force changed according to the available DirectInput resolution (0 to 10000).
For a lot of wheels the force outputs must be limited and I'm guessing that 500 steps and 25 Hz output may be enough, but I'll know more after I implement this.
I think I need to make a change that allows the force output to be limited in a controllable way that does not depend on the frame rate (if the frame rate is 100 Hz or higher).
I'm thinking we need two settings.
1) FF Steps : from about 500 to 10000
2) FF Max Update Rate : from about 25 to 100 Hz
For a high end wheel like yours you would set both to the maximum and that would allow the best connection between LFS and DirectInput, if your frame rate was 100 Hz. In that case there could be an output after every physics update, if the force changed according to the available DirectInput resolution (0 to 10000).
For a lot of wheels the force outputs must be limited and I'm guessing that 500 steps and 25 Hz output may be enough, but I'll know more after I implement this.
Did you download from our site? https://www.lfs.net/downloads
And which graphics card do you have?
I think it looks like a problem with the shaders. As if they are missing or not compatible with your graphics card.
And which graphics card do you have?
I think it looks like a problem with the shaders. As if they are missing or not compatible with your graphics card.
Thanks for pointing this out.
The input to DirectInput is a value from -10000 to 10000 so it makes sense to have a maximum value of 10000 for FF Steps.
I've now set that as the maximum and changed the default from 256 to 500, so that will be in U7.
Do you find 10000 works well?
The input to DirectInput is a value from -10000 to 10000 so it makes sense to have a maximum value of 10000 for FF Steps.
I've now set that as the maximum and changed the default from 256 to 500, so that will be in U7.
Do you find 10000 works well?
It's not your imagination!
Good find, thanks!
Good find, thanks!
Good to hear you are enjoying LFS in VR.
A Y offset should of course not be necessary and that's the first time I've heard of it. This must be something to do with your starting position for the Rift. When you first enter VR you normally click "OK" when you are in your seated position. The position issue you are reporting sounds as if you were sitting too far forward when you clicked "OK".
But with normal settings I would have thought you would notice that the next time you went into VR mode. Maybe you have set the option to "Store driving position" which prevents the position being reset each time you enter VR?
I can't remember exactly where the options are, but I think it is "Tracking setup" at the top right of View Options to do the setup again. The "Store driving position" is below the AA options and the default option is 'no'.
EDIT: Also you can do the seating position setup at any time with the command /vr reset which is assigned to F8 by default.
A Y offset should of course not be necessary and that's the first time I've heard of it. This must be something to do with your starting position for the Rift. When you first enter VR you normally click "OK" when you are in your seated position. The position issue you are reporting sounds as if you were sitting too far forward when you clicked "OK".
But with normal settings I would have thought you would notice that the next time you went into VR mode. Maybe you have set the option to "Store driving position" which prevents the position being reset each time you enter VR?
I can't remember exactly where the options are, but I think it is "Tracking setup" at the top right of View Options to do the setup again. The "Store driving position" is below the AA options and the default option is 'no'.
EDIT: Also you can do the seating position setup at any time with the command /vr reset which is assigned to F8 by default.
Last edited by Scawen, .
Thanks, I've added this to my test patch notes. To be clear, the stuck bug is not specifically related to open configs, but to the use of a custom pit stop point.
Thanks, banned SkyLine299
What is the problem you are having, can you describe what you are seeing, compared with what you should be seeing?
I remember those times! That was only for the DK1 though, I ordered a DK2 as soon as orders opened. I did use all the tricks like coding for 3D anaglyph glasses at the same time and there were a lot of people who could test on 3D TV. I also had a Vuzix VR which didn't really work but could view stereo static images for a few seconds before it overheated, so I could do a lot of debugging before asking community members to check the output with VR distortion.
FGED GREDG RDFGDR GSFDG