Otherwise terrain textures cache has zero hits because it stores not normalized
paths. Due to implicit conversion it's possible to add entry with
addEntryToObjectCache passing a string that is converted into normalized path.
But then getRefFromObjectCache called with original value does not find this
entry because it's not converted and overloaded operators are used instead.
These warnings were always enabled, but we didn't see them due to https://gitlab.com/OpenMW/openmw/-/issues/7882.
I do not fully understand the cause of 7822 as I can't repro it in a minimal CMake project.
Some of these fixes are thought through.
Some are sensible best guesses.
Some are kind of a stab in the dark as I don't know whether there was a
possible bug the warning was telling me about that I've done nothing to
help by introducing a static_cast.
Nearly all of these warnings were about some kind of narrowing
conversion, so I'm not sure why they weren't firing with GCC and Clang,
which have -Wall -Wextra -pedantic set, which should imply -Wnarrowing,
and they can't have been affected by 7882.
There were also some warnings being triggered from Boost code.
The vast majority of library headers that do questionable things weren't
firing warnings off, but for some reason, /external:I wasn't putting
these Boost headers into external mode.
We need these warnings dealt with one way or another so we can switch
the default Windows CI from MSBuild (which doesn't do ccache) to Ninja
(which does).
I have the necessary magic for that on a branch, but the branch won't
build because of these warnings.
It turns out that it's possible for OSG plugins to be spread across multiple directories, and OSG doesn't account for this in osgDB::listAllAvailablePlugins(), even though it works when actually loading the plugin.
Instead, use code that's much more similar to how OSG actually loads plugin, and therefore less likely to miss anything.
Incidentally make things much simpler as we don't need awkwardness from working around osgDB::listAllAvailablePlugins()'s limitations.
That way, we don't have issues like the checker getting false positives when the right plugins are present for the wrong OSG version or build config, or false negatives when we've generated the wrong filenames.
The old code was legal, and the things it did worked in other places, so should have worked here, too.
Hopefully just rearranging stuff convinces what I assume to be a compiler bug to not happen.
This one's a biggie.
The basic idea's that GameSettings should know:
* what the interpreted value of a setting is, so it can actually be used.
* what the original value the user put in their config was, so it can be put back when the config's saved.
* which path it's processing the openmw.cfg from so relative paths can be resolved correctly.
* whether a setting's a user setting that can be modified, or from one of the other openmw.cfg files that can't necessarily be modified.
This had fairly wide-reaching implications.
The first is that paths are resolved properly in cases where they previously wouldn't have been.
Without this commit, if the launcher saw a relative path in an openmw.cfg, it'd be resolved relative to the process' working directory (which we always set to the binary directory for reasons I won't get into).
That's not what the engine does, so is bad.
It's also not something a user's likely to suspect.
This mess is no longer a problem as paths are resolved correctly when they're loaded instead of on demand when they're used by whatever uses them.
Another problem was that if paths used slugs like ?userconfig? would be written back to openmw.cfg with the slugs replaced, which defeats the object of using the slugs.
This is also fixed.
Tracking which settings are user settings and which are in a non-editable openmw.cfg allows the launcher to grey out rows so they can't be edited (which is sensible as they can't be edited on-disk) while still being aware of content files that are provided by non-user data directories etc.
This is done in a pretty straightforward way for the data directories and fallback-archives, as those bits of UI are basic, but it's more complicated for content files as that uses a nmodel/view approach and has a lot more moving parts.
Thankfully, I'd already implemented that when dealing with builtin.omwscripts, so it just needed wiring up.
One more thing of note is that I made the SettingValue struct storable as a QVariant so it could be attached to the UI widgets as userdata, and then I could just grab the original representation and use it instead of needing any complicated mapping from display value to on-disk value.
There's also handling for files declared as originating from a lower-priority openmw.cfg, e.g. anything in the local config or any intermediate ones, as they can't be disabled or reordered.
There's no way to mark such files yet, but the logic's the same as built-in files, so everything will be fine once that's set up.
Previously it was quasi-mandatory - lots of things would add it, e.g. when running openmw through the CS, but it could technically be disabled.
Now it's treated like the resources/vfs directory and implicitly added by the engine etc.
I thought I'd seen this class defined in one of the existing headers
with a different name, but I was muddling its forward declaration and a
different class being in a non-obvious header.
It doesn't work, the workaround isn't enough to make it work, I can't be bothered making a more powerful workaround, and it's impossible to *package* a MacOS build missing the plugins we need anyway, even if you can build and attempt to run it.
Also attempt to make an equivalent warning fire with MSVC, then have to fix other stuff because /WX wasn't working, then back out of enabling the warning because none of the ones I could find disliked the old code.
Knowing which are right required making the function non-static, so the shadow manager had to become a singleton as the results of passing it around to where it's needed were hellish.
I'm seeing a bunch of OpenGL errors when actually using this, so I'll investigate whether they're happening on master.
I'm hesitant to look into it too much, though, as I'm affected by https://gitlab.com/OpenMW/openmw/-/issues/7811, and also have the Windows setting enabled that turns driver timeouts into a BSOD so a kernel dump is collected that I can send to AMD.
To avoid showing users errors like:
recursive_directory_iterator::operator++: Access is denied.
And show something like this:
Failed to recursively iterate over "/home/elsid/.local/share/openmw/test_data"
when incrementing to the next item from
"/home/elsid/.local/share/openmw/test_data/permission_denied": Permission denied
Use binary search in sorted vector or normalized paths instead of linear search
in the original file struct. With number of files from 1k to 10k in vanilla
archives this gives some benefits.
It should be initialize for each created archive anyway. There is no good reason
to have additional complexity for lazy initialization. And it helps to catch
problems with specific directory when it's added to the VFS not when all are
added and index is built.
The crashcatcher.cpp is not linked on Android because it's not supported but the
function need to have some definition. Make it empty to avoid link failures.
Float values with more than 22 significant fraction bits may cause out of bounds
access in recastnavigation on triangles rasterization. Prevent passing such
values there.