It may be a good time to consider this. Probably due to being busy on a lot of other things recently, I am not really aware of this issue. Can you explain why it is happening? Sorry for missing any previous explanations, but I'm listening now.
Please can you look at these possibilities, and tell me which one you think is more of a concern, and if there is another case I have not thought of?
1) Obviously it happens when a modified guest joins a non-modified host, and I have not regarded this as a big problem. I suppose in this case it would be nice if there was a more useful message to the guest, suggesting they join with an unmodified version of LFS?
2) And there is the other case when an unmodified guest (could be a new player) joins a modified host. In this case, the host should be private so this does not happen. It is of course very bad if modified hosts are publicly visible and I would have to do something about it.
It's not really easy to distinguish between these two cases but I could think a bit about it.
I guess it's because LFS and all other VR programs have an extra stage where they render to a large render target texture which is subsequently distorted onto the final output screen.
Many of these effects you can apply, using driver settings, only affect that final step which outputs to the screen. But the things they affect aren't done in that stage so there is no effect. For example you might be able to force antialiasing, and that would have absolutely no effect whatsoever, because it only affects edges, and there are no edges when the render target texture is distorted to the final screen. Supersamping and other things will also have no effect at all. You can't get any more detail into that render target texture after it has already been drawn.
The only way to affect the VR graphics is to affect the stage where the game is rendering to the render target texture.
If you want to try things in a easier was without the headset on, you could enable the post-processing shader as that goes through a similar process (rendering to a render target which is then transferred to the screen). First edit the post-processing shader to have no effect, then switch it on. Now, any effects you can successfully apply to that will also affect the VR mode version.
It is not normally a problem because when you have a VR headset on, the virtual keyboard always appears if there is a text dialog. The virtual keyboard key is really just to enable the virtual keyboard for other uses.
Yes, it's useful for anything that is not bound to a controller button, e.g. car reset or ignition, F9 to F12, clicking any assigned F keys and so on.
There is a separate 'T' assignment to open the chat dialog with a single button press.
I don't really have a suggestion at the moment, specially as the antialiasing to the render target texture is fixed at 4x. I have it on my VR notes to allow this to be an option, as in non-VR modes. I guess this might help. I know the problem you are talking about, most particularly on armco barriers because of the stripey appearance.
The existing bike simulation in LFS works by the user "setting the lean" with the mouse or wheel. The bike then does the necessary physical steering to get to that lean. So it's a physically simulated bike but obviously doesn't actually feel like being on a bike. It has a similarity with controlling a real bike because in real life we do get a bike round a corner by, through the bars, "setting the lean" appropriate for the current speed to achieve the required turn radius. There's quite a bit of work to be done on the LFS simulation and it's not a high priority yet but I would like to release it at some point even if it will never seem as convincing as car driving. Left / right / front / back body movement could be done using an analogue stick while another stick controls the lean angle. Body movement would not be necessary to ride but would be used to get the best lateral or longitudinal performance from the bike.
Yes, it is truly awful that the OVRServer_x64.exe is always running and connected to facebook servers, even while the Rift is not connected, and there is no way to exit from the software or stop it running when your computer starts.
Palmer Luckey has definitely made mistakes. Although I think he is a nice person at heart, it's not good that he has mocked people for trying to get their DK2 working which can be problematic due to bugs in the Oculus software.
It's an old discussion that always brings up arguments whenever it appears, but the main force to make a bike turn is applied through the bars. For example, to turn right, push on your right hand or pull on the left. This momentarily makes the wheel turn left. This has two effects that make the bike lean to the right. A gyroscopic effect that instantly causes a bit of lean to the right, and also the steering effect of the rubber on the ground aiming left also makes the bike lean to the right. Now, the leaning of the bike itself (to the right) applies a gyroscopic effect that makes the bars turn right.
So, quite strangely, but this is very easy to feel, when you push the bars left the bike leans right and the bars turn to the right. It's very easy to feel, just get on a bike, ride along, hold the bar with one hand. Do not move your body at all relative to the bike, and just push forward or backward gently with the hand that is on the bar.
This applied force can actually be quite hard on a medium to large motorbike. You can give it a serious push forward on the right bar to make the bike lean rapidly to the right, and another good push on the left to flick the bike back over to the left. This comes with experience though so please be careful. You can test it with a pedal bike but the force to apply is quite small.
The positioning of the body left and right in road racing is mainly to allow the centre of gravity to be further leaned without parts of the bike scraping on the ground. Also when the lean isn't quite so extreme, some lateral body movement can help to keep the centre of gravity above the contact point (which moves left and right if you have wide tyres). [EDIT: By "above" in the previous sentence I don't mean vertically above, but in the direction of the bike's vertical axis.] With considerable lean the bike is happier to sit at a given angle with the rider moved left or right a bit but this body movement is not the principle force that makes the bike lean in the first place.
The "one controller only" setup option and the "select audio device" are still here on my immediate list. I'm just having a less pressured two weeks, not rushing anything (and had other things to sort out). I'll report back if it's working or failing, hopefully this week. If it works OK I'll release a test patch with the updates.
As a test I've made a slight change to the first text at www.lfs.net so it doesn't show that picture including the Scirocco. I've tried to make the text a little more compact as well so the news item below is more likely to be seen.
Yes, we announced it but did not release it because we didn't like the way the car had to be set up. It showed up flaws in the tyre physics. I went into a massive push to sort out the tyre physics but it turned out more difficult the more I found out about it as the months went by. That time was also at the end of a period of many years of very hard work. We also moved house to a different part of the country after our children were born and work ended up slowing, except for vital updates.
Eventually I got into cross country cycling and stopped smoking which is good because I am healthier and will hopefully live longer. The VR support was a boost for us and now I'm well beyond stage 1 of my cycling hobby. I'm able to work a lot and still do a few rides each week. I've been trying to get this stage of VR development sorted so I can get back to the tyre physics which will allow more types of vehicle to be simulated.
EDIT: Removed the final part, the explanation is above. We made some decisions that weren't the best but I believe we are getting back on track. The new tyre physics will really help, along with new content.
That's because my email was being spammed by reported posts of demo users asking about how to set up cruise servers. A cruise server isn't much good without a layout. So I just copy and pasted this answer as a reply to some of the reported posts. There are a lot of reported posts and I can't spend a really long time on each one, if I want to get any actual work done.
Even before the patch I had on my notes to disable this warning if the actual ESC key is pressed. But it was too close to patch day, and I knew there would be a complication, because the assigned buttons do a fake key press. Do you think it would be fine if the warning only came up if an assigned controller button to ESC was pressed, and not the real key? It is extremely annoying when you are jumped out of that screen by mistakenly pressing the controller button assigned to ESC, so there is a good reason for this feature.
Your drivers are (falsely?) reporting the existence of at least one slider axis so it has the Slider 1 that, on some other Logitech wheels, is used for a clutch axis. It would be possible to specifically exclude this for that specific wheel. But it's not really a problem, I think. You can unassign that axis if it annoys you.
I don't know why you are seeing double vision effect. Normally when I have seen something like that, it was in a debug version or in some kind of view that caused the frame rate to go lower or half (e.g. in SHIFT+U mode, looking at the whole world). Is it any different if SteamVR is running or not running?
As Whiskey said, with Logitech wheels you need to refocus LFS once after plugging in the wheel, e.g. with ALT+TAB or by clicking on another window and back to LFS. Annoying but at least you don't need to restart LFS.
This should be fine now. It was fixed so when you are in the controls screen you see your own axes, not those of the viewed car.
Thanks, it seems quite clear now. It would be nice to stick with a single installation of LFS otherwise it's kind of wasteful.
So it looks like the basic things you need are:
1) Easy way to set up ONE wheel in an instance of LFS where there are actually several wheels connected to the computer. Basically selecting that device with a click or two after starting LFS and that could do a 'refresh' but ignore all the other controllers, not creating a massive list of axes and buttons.
2) A way to select the audio output device.
Those are the most important things. Then the next thing is:
3) A way for LFS to try to centre the wheel so it is ready at the start of a race or after a car reset.
After that there are refinements that would be nice but may be difficult and are not essential:
4) Some way to select a player or start up LFS with command line options that select the screen, wheel and speakers all in one.
For now I will just forget about number 4, assuming that you will be happy enough just being able to easily select the wheel device and audio device with the minimum amount of messing around after starting each instance of LFS. And I assume that you are happy enough with the screen setup, though I don't really know how you do that. Is it like one massive desktop, and you slide LFS across to the appropriate monitor then press SHIFT+F11?
The issue is unusual - using a single computer for multiple instances of LFS with their own input and output devices.
Each instance of LFS needs to be able to select its graphics and audio device and its force feedback input device.
OK, my first question is, do you have separate installations of Live for Speed on the single computer? A separate installation that is intended to connect to its required devices?
I understand this can be complicated / annoying to set up the first time, but it's not clear to me why you need to set it up again after a restart. Are the input devices not reported in the same order each time the computer starts? So that each instance of LFS can simply load its previously assigned axes and buttons?
Or is the problem that you don't know which ones will be plugged in, and it can be different every time?
I'll look into this audio device selection in the next few days. Hopefully will know more by Wednesday. I'm busy sorting out quite a few things at the moment.
Interesting, I agree a gently centering wheel would be useful.
Yes, it does seem to make sense that LFS could automatically connect the FF device to the device whose axis is selected for steering. Then there would be no need for the FF device option. I've added this to my notes. If anyone can think of a case where this would not work, please let me know.