Here is the issue. This needs to be fixed before we can have a release.
As far as I can see the problem is located in DataFilesPage::writeConfig.
I can not follow the logic of this function. As far as I can see the launcher is reading all openmw.cfg through our regular configuration system (as used in OpenMW). Therefore it shouldn't even touch any other openmw.cfg file than the user one (not even read manually). And the file not being there is not an error.
Launcher openmw.cfg problem
Re: Launcher openmw.cfg problem
Well it's fixed and pull request sent, but let me explain the logic behind it.
The launcher does indeed use the configuration manager for reading. It occurred to me that local takes precedence over the user location, so the data= directory set in an non-installed version of the launcher would never been taken into account by openmw. I thought this wouldn't be an issue in Windows as I figured local and user would point to the same location on that platform, but the various people complaining have proven otherwise
The launcher does indeed use the configuration manager for reading. It occurred to me that local takes precedence over the user location, so the data= directory set in an non-installed version of the launcher would never been taken into account by openmw. I thought this wouldn't be an issue in Windows as I figured local and user would point to the same location on that platform, but the various people complaining have proven otherwise
Re: Launcher openmw.cfg problem
Never! User has always the highest priority (not counting the command line).It occurred to me that local takes precedence over the user location
Again, never! This can happen with local and global depending on the platform, but user is always separate.as I figured local and user would point to the same location on that platform
Re: Launcher openmw.cfg problem
Looked at your fix. Admittedly the whole Qt stuff seems pretty cryptic to me (guess I have to start reading the Qt API documentation at some point), but it looks like this function will still fail, if the cfg file does not exist.
Re: Launcher openmw.cfg problem
Nope, it will create the file if it's not there. It will only fail on permission problems, hence the error dialog code.
Edit:
Edit:
That's not how it works here, as soon as there is an openmw.cfg in the working directory of the launcher or openmw it will fail if the data= entry inside it is not valid.Zini wrote:Never! User has always the highest priority (not counting the command line).
Re: Launcher openmw.cfg problem
Okay, then I misread the code.Nope, it will create the file if it's not there. It will only fail on permission problems, hence the error dialog code.
And you have a data entry in a openmw.cfg file with higher priority? Because else the invalid entry will be used anyway.That's not how it works here, as soon as there is an openmw.cfg in the working directory of the launcher or openmw it will fail if the data= entry inside it is not valid.
Re: Launcher openmw.cfg problem
Hmm it seems the "?mw?Data Files" isn't working for me anymore, the priority is indeed as you state.Zini wrote:And you have a data entry in a openmw.cfg file with higher priority? Because else the invalid entry will be used anyway.
EDIT: K1ll cleared it up for me, the installation location is read from the wine registry now, and I just copied it there, it did work before (maybe we didn't read from the registry back then.)
Re: Launcher openmw.cfg problem
Could you guys maybe release a 0.12.1 or something with this bugfix? It would be nice not having issues with the launcher, if that is indeed what this fixes.
edit: from the look of things on github I may not need to wait much longer anyway, so never mind I suppose.
edit: from the look of things on github I may not need to wait much longer anyway, so never mind I suppose.
Re: Launcher openmw.cfg problem
Yep, already fixed, and 0.13.0 should be out in a couple of days.