I'm having trouble passing command line parameters to LFS that I'm sure worked before. For example, I want to force windowed mode using
LFS.exe /windowed=yes
but I'm getting an error
What I actually want to do is to use another cfg.txt file by passing
LFS.exe /cfg=mycfg.txt
This throws
I'm sure I was able to use parameters in the past, and commands.txt still leads me to believe that the above command should be valid. The only parameters I can get to work are /insim=xxx and others after using /host=Host Name, but nothing else works for a single session.
Have I missed something like start in single player mode, if so what is it please?
hmm, the /cfg command is not meant to load another cfg.txt. Instead it's used to load a setup.cfg file, like you do for the dedi. So with /cfg you load a file that contains the command line switches as listed in Commands.txt. Not the cfg.txt file with internal LFS settings.
Furthermore, I'm not sure why /windowed doesn't work. That sounds like an option that should work with the normal LFS client. I tried the /insim= and /hlvc options which do work though. So I think there is some confusion going on here and perhaps the commands.txt file need some better wording, or there indeed is a bug in the command line processing. But I'll point Scawen to this thread so he can have a look.
Nothing has changed, it just works the same way it always did.
/cfg=test.txt does work if the test.txt is valid.
There must be start parameter before any other parameters.
A start parameter is one of :
/cfg
/host
/join
/hlvc
/unlock
/insim
/player
Why can't it do other things? Probably because no-one ever asked for it. Most of the commands were added for starting a host or joining a host, so a start parameter was required. For example, the meaning of the /pass command depends on whether the start parameter was /join or /host. But later /insim and /player were allowed to be start parameters. Strangely enough, they allow LFS to read the other commands as if there had been a proper start parameter.
Maybe you could explain what it is you want to do, that you can't do at the moment. For example, is it just that you want to make two different shortcuts so you can start LFS in a window or fill screen? But I can't spend a lot of time thinking about it at the moment, because I'm on other things now.
I was probably just remembering it wrong then. I've lost my archive of older LFS revisions, so was unable to check back. Somehow, I mistakenly believed we had a little more control over the start parameters, and I'm probably confusing it with some other software. When I did resort to RTFM, I was left non the wiser, so perhaps the distinction between LFS cfg.txt and LFS (host) cfg.cfg could be clarified in the documentation?
/windowed= as a startup parameter would be most beneficial. Sometimes, other applications might need attention when we start LFS, and to be able to override the config would help here without flipping from the last stored window state in the config.
To be able to specify a /cfg= for a single session would allow us to make different shortcuts when different hardware is involved. In particular, I have a projector that is very picky about its resolution and refresh rate, so if I forget to change screen modes after I've used my desktop monitor, it causes problems when I start up next time with the projector connected. (hence the need for windowed mode) The same goes for controllers. A visit to options is required every time a different controller is used because this is the only place the settings are stored. The rest of the adjustments I need to make can be controlled via an InSim connection or autoexec.lfs of course, but display and controllers aren't included.
I suppose what I was expecting was, to be able to specify a profile at the command line/shortcut without needing to visit options every time.
There is a workaround and that involves a copy of the install so the different configs can be used. This is suboptimal and can cause synchronisation problems between installs. More ideally, (but doesn't work on XP) is to create a virtual install using symbolic links for everything but the config, logs and autoexec.lfs. This allows the linked LFS to have its own configuration all of its own. All of this could be much simpler though.
I can't find anything on /hlvc. What does this do? I tried it and got a server style window pop up briefly. There's some red warning text, but it disappears too quickly to be read. The log doesn't give anything away either.
It's a shame I hadn't spotted the documentation anomalies before the last round of patches. I understand that as things grow organically, documentation can get overlooked, but I think commands.txt needs a little more clarity, and better distinction made between host commands and general commands. It might be fair to say that many of us can interpret which is which, but when something doesn't go as expected, the docs -the first port of call- should be concise. This might be especially true for non English speakers where a literal translation can be even more misleading and contradictory.
I realise that the tyre physics and related works are now the focus of your attention, but could you please make a note to make some clarifications in the docs come the next round of patches?