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.
Recently I have been working on graphical updates, in the form of some more shaders that Eric can make good use of. There was quite a bit of restructuring to make it more consistent between the different types of objects and easier to add more in future.
So, looking at the list you quoted in the post above, that means number 2 has moved in front of number 1. This is to allow Eric to make some use of the new shaders in the updated Rockingham, Blackwood and Westhill tracks before they are released.
Nice pictures! And good to see you are wearing my favourite shirt!
The mountain biking looks fun. I would like to reassure you that I don't do that "downhill" mountain biking. Respect to those nutty guys but I just do the normal "XC" (cross country) mountain biking which is a lot less dangerous!
Please could we stop this attacking of demo users who ask a question?
For example, you could choose to just help them if you feel like it and they haven't said anything about licensed content. Or if you have your suspicions or even evidence, perhaps it might be possible to ask them politely if they have been using a crack?
The problem is there is too much speech that is sort of attacking or accusing and it comes across as unpleasant. These posts are being reported and it takes up our time, and sometimes I guess it puts people off coming here. Maybe a polite suggestion about getting a license could bring people into our community?
We have received a lot of reports of bad posting on this thread.
I really don't want to start banning people.
This is not about people from one area of the world, this is about a group of idiots attacking an LFS server where people are having fun.
There is no need to turn it into stupid suggestions and blanket statements that get people angry and cause further problems on this forum.
So I'm just going to close this thread and ask again, please do not write in this way. If you are going to post something, imagine saying it in real life. Would someone be likely to punch you in the face? If so, please don't submit the post.
Now I am forced to close this thread because the discussion has turned into 10 year olds in the playground sort of level.
We are trying to help tackle the problem so people can enjoy driving around online.
We are working on LFS but the rate of progress will always be slower than the developers or customers would like it to be. But we like working on it and many people enjoy the updates. So that's fun. There are plenty of other good things you can do too, with or without your computer.