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...
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.
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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.