That'll be the missing equals sign - you do need it after command line commands, even though you don't need it in script files.
By the way, don't forget you can use the log command now to create a separate log file for each instance. Just add /log=XXX.txt somewhere after the /mp= command.
That might come in helpful next time you get the black screen issue, specially if it doesn't recover. We still haven't seen the recovery take place on your system yet. And if it does happen, success or fail, I'd like to see a log file. I did start three LFS guests connected to a host on one computer with an AI driving around, then installed a new graphics driver while they were all connected, and they all recovered successfully.
I can't really work on InSim improvements right now as I really need to get some shader updates finished that I am already in the middle of doing.
As you know, I like the things you do with InSim and layouts so I'd like to support them. I think the idea of reporting the line id makes some sense but also there is something a bit incomplete / temporary / not quite right about it. For reasons like (1) the same id can be used in different places, and (2) users can often navigate by key presses instead of clicking a button.
So maybe it would be better to understand what problem it is you are trying to solve and maybe there is a better / more reliable solution. But take your time as I have the shader updates to work on at the moment. I actually have a note on my to do list, to look at some of the things you have requested before. Maybe it would be good to get your requests into one place, perhaps in an email so I can refer to that during a test patch stage.
This current update was really to try and make LFS reliable and easier to set up for SimulatorRental.com as it seems a cool setup that he has, but LFS going to a black screen wasn't a good advert for LFS!
I believe it is important for me to update the protocol between LFS and the master server to make it harder to crack.
At the moment I am in the middle of updating the shaders to allow Eric to update the graphics in more ways. He is already doing various updates using some new shaders but asked me to add some more to give him more flexibility. I'm looking forward to getting to the point where we can release the updated tracks, and Eric can then continue with new tracks.
It's not just as simple as "adding a shader". Internal changes must be made to allow selection of the options that use those shaders, and data needs to be added to the vertices of objects and so on. It's actually quite complicated and at times confusing, adding these new things without breaking the old things. Restructuring is required.
So at this point, I can't stop that to work on network security.
Just to explain, so I hope it's clear... I want to work on network security, but it's also important to make sure Eric has the tools he wants to work with, and then I'll be free to work on other important things. There are many important things to work on. One of them is network security. Others include graphical and physical updates.
I'll close this thread because, as people have pointed out, it includes adverts for cracked communities. I might delete the thread in a while but I'll let people read my comments first. If I simply delete the thread now, I will be adding fuel to the fire of people saying things like "LFS devs just delete threads and pretend cracking doesn't exist". Unfortunately certain members find it hard to understand why I don't spend every minute of my working life trying to defeat crackers. I do need to update Live for Speed in many different ways, so that people do continue to use it in the future.
Let's all try to stay positive. I don't really understand the spreading of negativity and repetitive sarcastic comments. This is a game, a form of entertainment. It's supposed to be fun so, some members here, please try to avoid negative comments, specially when you have made the same point many times before.
As mentioned, I didn't like the pointless restrictions on the use of command line commands. Commands may now be used more freely, for example to override settings that were stored in cfg.txt without the need to have some arbitrary command before them.
I think the restrictions now make sense. They are listed in the updated docs\Commands.txt
The other main improvement is that the /mp command can now be used on the command line.
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.