I asked Eric but he doesn't want to show South City screenshots yet.
He's been working on it, changing all the road surfaces and building some ways through that were blocked off before. It's not just the roads but barriers, fences, walls, etc. And many buildings will be updated.
You can assign the text /vr reset to the wheel button, to replicate F8.
And assign the command /press space to map the space key to a button.
Let me know if that's not clear.
I won't get the VR headset out for a test right now, but I think you are saying that when the text box is visible, the cross hairs are also visible and the space key can then perform one of two functions. Either adding a space character to the text, or performing a 'click' if the cross hairs are over a button, which happens unexpectedly while typing unless you are careful about where you are looking. That does sound quite annoying.
I will try to remember this, I wonder if maybe there could be some kind of solution, without needing to reassign the space bar.
We've written to the hoster and the domain register. I think it was the hoster simply ignored us and the register told us they would only respond to a letter from a lawyer.
Basically they just want money from the people who pay them, and have no care or concern if their services are being used for criminal purposes. It's the same story with that scam we recently noticed. Their hoster has not replied to repeated mails. They just aren't interested, they prefer to keep the customer unless somehow forced.
To do anything that would have any effect would be a lot of time, effort and money, without any guarantee of success. Even if shut down, the criminals would simply set up again with a new name. They would have to be locked up but seriously, that isn't going to happen. No-one really gives a shit if some game developers are losing some money due to pirates.
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.