1) The Rift software does not allow more than one headset, or at least didn't in the past. I don't know if the SteamVR allows more than one Vive to be attached.
2) I believe the processing and graphics card requirements are too high in any case. Smoothness is VR is too important and there are large textures in use. The game is rendered onto a very large render target texture every frame before the distortion operation takes place.
I expect you can run extra non-VR instances of LFS on a computer that is running one instance of LFS in VR, but they might affect the smoothness in VR.
About the next update (R7) I took this opportunity to sort out the command line system, which had some pointless restrictions that were designed for a very early stage of development.
1) There is no longer such an error as "info parameter before start parameter". Now it just makes sure that completely incompatible commands are not used together, and makes sure any "exclusive command" (like /host or /join) come before any "ordinary commands" (like /pass or /log or /insim). So all old command lines will still work but it will be more flexible.
2) I have coded the /mp command to be available on the command line, just like the /join command already was. So you will no longer need to used the autoexec.lfs file for an automatic connection.
Yes, that happens the first time you load a sky in this intermediate version. A missing dds file causes that error message. The correct png file is then converted to a dds file and you don't get the message next time. It's a bit misleading, in fact it was already on my list. Although it wouldn't happen in the official release as the correct files would be in place.
Thanks, yes that is a bit of a pointless restriction in this case. I've made a note to look at that. In the meantime, it will work on the host, because that one does have a "start parameter" i.e. /host.
I can now install new Nvidia graphics drivers while LFS is running and it recovers. The new driver installation obviously forces the driver to restart. LFS notices that and tries to recover from that error by reinitialising D3D then reloading all textures, rebuilding meshes and so on. It will try that 10 times over about 20 seconds and if it does not succeed then it will exit.
The recovery, if successful, can take a couple of seconds up to maybe 10 to 20 seconds depending on which track is loaded and how fast your computer is. About the time it takes to load a new track.
NOTE: The recovery system is for D3D9Ex (Windows Vista and later).
Information about the recovery process is logged in deb.log.
OK, I think I now understand why it continues to hang on a black screen after a driver error.
LFS is, in effect, noticing the error then waiting for it to be magically fixed before doing its own reset. I thought I was coding it to wait until it was ready to reset but it seems that is not the case.
I can now reproduce D3DERR_DEVICEREMOVED by installing new graphics drivers while LFS is running. If I can get it to recover from that and a few other errors then hopefully it will be good to go.
Current plan is to try and reset after any of these errors:
Thanks for the report. Pleased the updates were helpful. If you (or anyone) gets a black screen from a driver crash / restart, I'd like to see the deb.log in case I can get any info from it.
Where did you see the message "unable to install or load something" - was that in the deb.log file or a windows dialog?
All LFS patches can be patched into your existing version, a new full version is never needed (unless something is wrong with your installation like corrupted or deleted files). I should probably change the install instructions to say version 0.6R or later must already be installed.
R5 is only a small change in LFS.exe. It will avoid you needing to press SHIFT+F11 twice - the LFS instances will appear on their correct screen when they start. Good to hear the wheel and headphones stayed with the correct instances!
OK, I don't know if you have gone already but it would be best to get 0.6R5 I've just posted above.
It now starts on the correct monitor that you exited on (if using the borderless window mode).
With previous versions, if you pressed SHIFT+F11 to go to full screen borderless window mode, it would go to the nearest monitor (closest match to the current LFS window). But if you exited in that state, then when you restarted it would always go to the default monitor.
With 0.6R5 it does successfully restart on the same monitor if you previously exited LFS in full screen borderless window (SHIFT+F11) mode.
OK, pleased you got it working and I hope it goes well at this morning's event.
Does it seem to remember the correct audio device and steering wheel?
One thing, if a recovery event takes place, as mentioned there will be a yellow message on screen "Recovered from D3D device error" and also the same message is written in the deb.log file in case you weren't looking at the screen at the time.
I'd be interested to know if that happens for real as I've only done these artificial tests where a key press made LFS pretend there was an error.
OK, here is the test patch. I don't recommend it for everyone, as some lighting has been removed from some of the objects in the more recently updated tracks (WE / BL / RO).
Please backup your version R LFS.exe so you can return to that version at any time.
EDIT : UPDATED TO R7 ON 24 OCTOBER
When you first run this test patch there will be a hang of around
40 seconds while the old .raw files are converted to .png files.
Due to various updates, the rendered lighting has been removed from
modelled objects in the game. This can only be fixed by supplying
freshly rendered tracks but this is just a small test patch.
A FULL version of LFS 0.6R must already be installed
To install the PATCH :
1) Move or save the patch into your main LFS folder
2) Double click the patch to extract it to that folder
3) When you see "Confirm File Replace" select "Yes to All"
4) Now you can start LFS in the normal way
NOTE : You can see if the patch is correctly installed when you run
the program (LFS.exe). At the bottom of the entry screen : 0.6R5
Changes from 0.6R to 0.6R5 :
PNG files are now used in the few cases where RAW files were used
Removed option to view sky in 16-bit colour
Sky now uses DDS (compressed) textures
Improved processing of command line to be more flexible
New command /settings=X.txt - uses X.txt instead of cfg.txt
Command /settings must be the first on command line or in file
Command /mp (join local host) can now be used on the command line
Live for Speed can now recover from a graphics driver error
LFS starting in borderless window mode now goes to the same monitor
Textures are no longer reloaded when changing weather (avoids hang)
New option "Display LFS logo in game" (not optional in demo mode)
English file is no longer saved when LFS starts (can be deleted)
New commands to skip F8 menu /vr reset_headset and /vr use_relative
This seems to be going well, so I hope to be able to upload a test in a few hours.
Answers to some of your questions:
/host=hostname does work in the command line. There is no equivalent in the cfg.txt file.
So for the host you could use something like:
LFS.exe /settings=cfg_host.txt /host=hostname
The /mp=IP# command does not work as a command line option. Maybe you can do auto join using the autoexec.lfs script. I think you won't need to rename it for each instance, you could have a static one.
So your guests would use:
LFS.exe /setttings=cfg_guest1.txt (etc)
And there would be a static autoexec.lfs in the scripts folder with one command /mp=x.x.x.x
Yes I think this should save time. I'm really interested to know if the audio and controller devices really are recognised, and always the same one when you restart with the correct cfg file.
Also there may be another benefit. As the window position is also stored within the cfg file. Maybe it's possible the LFS instance will go to the correct monitor as well? We'll see.
BUT... for your test you might like to wait a little, because I am trying something that I hope will do away with any file renaming at all. The driver name and setup is also stored in the cfg.txt so it really is the key. This morning I am trying to implement a new command for the command line /settings=cfg_1.txt so that instead of using cfg.txt it would use cfg_1.txt (or whatever name you choose).
So then you will be able to start your LFS instances with a shortcut (or command in batch file) like this:
And that will load the cfg_1.txt when starting up. Also any settings you change while LFS is running would also be saved in cfg_1.txt, ready to be used the next time you start that instance.
Well that post above is all about trying to get your starting up sequence a lot quicker.
On the subject of recovering from a driver crash, so you could avoid going through a startup sequence, I have come along a long way with that today. I can make LFS pretend there has been a driver crash and it does a full reinitialisation of D3D9, loading all the textures and rebuilding meshes and so on, getting past the black screen stage and back to where you were, although your car has probably hit a wall by then if you were driving.
I haven't done all the necessary testing yet and what happens if it's full screen, etc. It seems to work in a window at least. I'll carry on in the morning.
I'm pleased with that so far but not fully confident, because I don't know a way to create a real driver crash (or restart the Nvidia driver). Without a way to reproduce the real thing it's a bit hard to say that it works.
OK, that is understandable and yes it's nice to avoid multiple installations.
Right, this seems to be along the right lines, but I think I can see a problem here.
First, and this may not be a problem, I can't think easily why you need both a /cfg=x.txt file and an autoexec.lfs file for each LFS instance.
As in, you are renaming a particular file to autoexec.lfs and you are also starting LFS with a command line with /cfg=C:\LFS_MAIN\Player_3.txt (etc).
I guess you may have a good reason for that, and I would be interested to know.
Second, and I do think this is a problem, there is no mention of cfg.txt - the actual config file that saves most LFS settings, including the audio and controller GUID. When I started to read that you were using a bat file to rename files, I thought that you would be renaming cfg.txt. But I see no mention of it in your bat file, and so I can't see any way that your controller and audio device could be remembered.
So let's say, to set it up (once only) you plug in all your wheels then you start LFS_1 - set up the audio and controller for it. Exit LFS and make a backup of that cfg.txt file (to cfg_1.txt or whatever). Now do the same for LFS_2 - save a cfg_2.txt for it. These cfg_x.txt files will need to be renamed in your bat file so they are in place (as plain old "cfg.txt") when each LFS instance starts up.
I'm not sure I'm explaining myself very well, but I'm talking about a renaming like you do for the autoexec.lfs file but do it for the normal cfg.txt file as well (and maybe you don't need the autoexec.lfs file as well).
OK, I'm hoping that you can avoid this by making sure the correct cfg.txt file is used, as that is where the GUIDs are stored (Speaker GUID and Control GUID near the top of the file).
From what I can read online, the GUID should be unique to that device on that computer. So it shouldn't matter which order the USB cables are and so on.
It is of course vital is that each instance of LFS has its own cfg.txt. Are your LFS instances saved in their own folders? If not then I am sure it will not work.
My understanding is that if the wheels are plugged in and available, then when an instance of LFS starts, that instance should use the same wheel it used the previous time and it should not matter which order the wheels were plugged in or which socket they are in.
I'm not sure what happens if LFS starts up and the wheel it looks for is not available. I guess it may be important for WHEEL_1 to be plugged in before LFS_1 is started, so that LFS_1 can successfully connect to WHEEL_1.
Well, I don't really need advice on prioritisation.
I'd like very much to work on the tyre physics, because of all the possibilities it will open up, but currently I am working on the graphical updates, more shaders for Eric to use.
In fact, LFS does need graphical updates as it gets the most criticism in that area, unfairly at times. Comments along the lines of "LFS is from 2002 and hasn't had a single update since then, therefore it has shit graphics". Typical comment from someone who doesn't even have a look to see how far it has come. But in truth there is quite a lot of modernisation that needs to be done, and I'm doing the things that allow Eric to make some significant improvements.
As I've pointed out before, most people have one thing they think is most important. That may be graphics, physics, autocross objects, changing weather, network security, etc. And it seems many of these people find it totally incredible that I am not devoting all my time to their own favourite issue. In fact, all these things need to be worked on and they are all challenging. Luckily I enjoy working on them so we'll get there eventually.
It's not really good advice to ask me not to prevent a crash issue that is badly affecting someone, when it might only take a day or two to fix. So as I said, I'll have a look into it.
I think the driver crashes are the fault of the driver writers / graphics card manufacturer, not MS/D3D9. Although I do believe that LFS making the card busy makes it more likely to happen, it shouldn't be possible for one program to make the driver crash.
About the device memory, I thought that problem was solved, since LFS now stores the speaker GUID and the controller GUID in the cfg.txt and that was coded with your system in mind. So LFS should start up any time with the same speakers and wheel that you previously selected.
Sorry to hear that doesn't seem to help. You are saying the ID of each device keeps changing? Maybe you can avoid restarting the computer after a driver crash, then the devices will keep their ID numbers and LFS instances should start up using their previous devices?
Anyway as setting up / restarting LFS is a problem then some sort of LFS automatic recovery would help, even if your customers crash their cars on track during the recovery, at least you could just restart the race.
I'll have a look and see if I can do something. It has been on my list for a long time.
I see that black screen issue when the display driver crashes. LFS doesn't know how to recover from it. It would be possible to program LFS to restart D3D9 and recover. I'm not certain but I think it would need to reload all the textures at that point and by then the virtual car would have crashed anyway.
When the display driver crashes, it always seems that all running programs are affected. I don't believe that LFS is really the cause of this. Even if there is a bug in LFS, the display driver should not crash. LFS is going through D3D which in turn is sending instructions to the display driver, so I believe these crashes are caused by a bug in the drivers.
I have noticed in the past when upgrading drivers, they crashed far more frequently, so I have sometimes gone back to older drivers. Maybe you could try installing an older driver that was known to be stable.
I'm not sure how many times I will need to repeat that I do intend to encrypt the master server protocol to improve security. Maybe if I say it 100 times, you will believe me? I expect not - you'll only believe it when you see it. Well, that is fine, but you don't need to keep making negative comments about how the devs don't seem to care about piracy and so on.
In that case, the devs don't care about physics. The devs don't care about graphics. The devs don't care about tracks. The devs don't care about cars. Yes, we do, and we are working on them, but it takes time. I'd be grateful if you could learn a little patience, and understand that YOUR priority does not rank about everyone else's priorities.
Each time one person goes on about their own personal priority, we can't just stop everything else we are working on, just to try and shut you up. Please, be a bit more mature and have some PATIENCE!
Personally, I hope that we don't help cracked players. In my opinion, we should not do so. But that is only true if it is clear that they are a cracker.
We do have a problem where sometimes a cracker asks a question and does receive help. I believe this is because the person who gives the help doesn't want to launch a full scale police investigation every time a Demo racer asks a question. They would rather just point to the answer, not start delving in to the person's race history and trying to draw conclusions from the often incomplete evidence.
I sometimes wonder if maybe Demo racers should not be allowed to ask questions on the programming section. But we do allow InSim in the Demo, so it is not really unreasonable that a Demo racer can ask for programming help.
I deleted your post from the main forum section as it was not a general interest comment and was already receiving argumentative comments.
Well... it does need graphical updates to stay vaguely up to date. If you take a look at the really old versions of LFS, you'll see it has come along a great deal over the years and there wouldn't be anyone at all online any more if it looked now how it did back then.
That is important, and it's important for me to try and make sure the 3D system can allow Eric to create the effects he wants to. Or at least some of the effects. I'm always behind what he would really like it to be.
I had a relaxed month in August due to the school holidays and had a nice time here with the family. I'm back on getting some updated shaders finished so that Eric will be able to use them. We'll be able to release a patch with some fixes and graphical updates on Blackwood, Rockingham and Westhill.
Then what I really want to do is get the tyre physics finished so we can release the needed updates and then hopefully get onto supporting some elements of user created content. I can't be any more specific on that as there are no fixed plans.