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!

The could not load message was in the deb.log after the lost D3D message.
I forget exactly what it said....

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:

D3DERR_DEVICELOST
D3DERR_DEVICEHUNG
D3DERR_DEVICEREMOVED
D3DERR_OUTOFVIDEOMEMORY
D3DERR_DEVICENOTRESET
D3DERR_DRIVERINTERNALERROR

I think the D3D error was Device Lost, not 100% seeing these is altering my memory. IT had 4 entries, one for each display. Maybe have been device removed.

However AFTER that there was something that was close to "cannot load texture"

If it does try to recover how long will it take?
I think I waited at least long enough for LFS to load a track change, but since I was in a hurry to get the guy racing again, it may not have been as long as I thought.

Also, during the event someone wanted to see another track, so I randomly clicked on one, I think South city?? And the host program crashed, with errors similar to cannot load texture as well...

Maybe patch messed up my texture files?

OK I think that is now sorted.

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.

0.6R6 : https://www.lfs.net/forum/post/1929543#post1929543

Tested LFS tracks, Textures mostly seem to work error seems to be with the sky background on some tracks.... yet it still loads one.

/log creates a "start parameter before..." error.

I tried .txt and .log

Quote from SimulatorRental.com :

Tested LFS tracks, Textures mostly seem to work error seems to be with the sky background on some tracks.... yet it still loads one.

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.

Quote from SimulatorRental.com :

/log creates a "start parameter before..." error.

I tried .txt and .log

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.

So you can have LFS.exe /host=name /log=host.txt

@SimulatorRental.com

That made me wonder what "device lost" actually is about..

https://msdn.microsoft.com/en-us/library/windows/desktop/bb174714%28v=vs.85%29.aspx

So, it has something to do with fullscreen/windowed mode and/or alt-tab if I understand it correctly. (Or, " Devices can also be lost due to a power management event, ")

Quote from msdn :

By design, the full set of scenarios that can cause a device to become lost is not specified.

100% Rain on the forecast resulted in me not going to the trailer to do any more testing.

Next event, is on the 25th, if it does not rain, or if they give me an indoor spot. I may not get to do any more testing (with the monitors & wheels) until then. Next event after that is on the 27th.


SEMI OFF TOPIC:
Video Devices had me thinking about how well VR would work in multi instance. Is there any obvious reason 4 Vive Helmets would not work with LFS on the same PC?

Quote from SimulatorRental.com :

SEMI OFF TOPIC:
Video Devices had me thinking about how well VR would work in multi instance. Is there any obvious reason 4 Vive Helmets would not work with LFS on the same PC?

I think other than the processing power required for VR, the physical limitations would be the biggest hurdle - each headset would require an HDMI output, in addition to 2-3 USB3 ports (based on Oculus' setup - I haven't yet seen a Vive).

Quote from SimulatorRental.com :

SEMI OFF TOPIC:
Video Devices had me thinking about how well VR would work in multi instance. Is there any obvious reason 4 Vive Helmets would not work with LFS on the same PC?

In addition to Shirtkicker's comment:

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.

I should be able to release R7 this afternoon.

OFF-TOPIC:

When you use the /track command in game DCon reports: "Can't change track during race". Would it make sense to lift this limitation for open configurations? In case of an open configuration changing to another open configuration with /track would make track rotation a breeze. You can already achieve this with autocross InSim checkpoints so I'm probably nitpicking

OK, R7 is now available.

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.

0.6R7: https://www.lfs.net/forum/post/1929543#post1929543

Quote from sicotange :

OFF-TOPIC:

When you use the /track command in game DCon reports: "Can't change track during race". Would it make sense to lift this limitation for open configurations? In case of an open configuration changing to another open configuration with /track would make track rotation a breeze. You can already achieve this with autocross InSim checkpoints so I'm probably nitpicking

That is interesting. It makes me think that any configs should be selectable, not only open ones, but then of course the cars would probably be off the side of the current path, causing a reset.

But yes, as you suggest, it could work with open configs. I'm not sure if there are any issues in the code that would make it tricky to implement. Doesn't sound impossible though...

Better and better each version...

Just wish I could go test things, been 24/7 rain, will likely be tomorrow as well, which is killing the events I was going to do.

In a few weeks I will be able to test as soon as the file is available, as I will be removing the monitors & wheels from the trailer and bringing them inside, so they don't freeze over winter.

Quote :

That is interesting. It makes me think that any configs should be selectable, not only open ones, but then of course the cars would probably be off the side of the current path, causing a reset.

But yes, as you suggest, it could work with open configs. I'm not sure if there are any issues in the code that would make it tricky to implement. Doesn't sound impossible though...

Obviously it should reset the race but an impromptu /restart causes the same kind of inconvenience for the players racing in my opinion. It might be confusing though, unless there is an /rcm message to inform the players the track has changed resulting in race reset (I'm in favour of informing players via InSim instead of a default LFS message).

Concerning InSim, if it's an appropriate patch round to implement InSim improvements. Is it tricky/time-consuming to make LFS report the line id (as per: https://www.lfs.net/lfs_transl ... n_viewer.php?lang=English) of a LFS button clicked? We already have IS_BTN for InSim buttons, the same for LFS buttons would be great (or overkill?).

Hi Sicotange,

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!

And a BIG help it was.

It sucked when a guy gave me $50.00 (instead of the $5.00 I was charging) and it went right to black screen lol... luckily they were a little wasted, and did not mind so much waiting for me to reboot.

Never mind my issue, I forgot to re-copy the new .exe lol... I even made a .bat to do it for patch updates. Sigh...

EDIT: OK, you removed the bug report. Here's my test result anyway. Seems OK.
-----
I just started a host on my local computer then made a guest join it using the following command line:

/mp=192.168.0.4 63392

It also works with 127.0.0.1

You do need the port there and you need the equals sign /mp=

Nope, fixing exe file did not fix it, still getting invalid parameter.

I have

/MP 192.168.1.101 63392


the = was missing.

Working...
Always the little things.

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.

Working on main computer, but currently trying to see what I mucked up to get a "/cfg must be at end of line" error, on the second pc.

The command line is pretty much a copy paste of what is on the other PC.
Yet it works on one not on the other.


I added in the /log works on main pc...

I think I figured it out, old content in 2nd pc bat file....
Yep,

Really thought I deleted that a long time ago lol.