Setup logging after setting up paths but before settings loading to get proper
log records earlier.
Read configuration by navmeshtool and bulletobjecttool the same way editor and
engine do to properly handle --replace config and --config arguments.
Remove mode and autoSetupLogging arguments from setupLogging since they are no
longer used.
Use temp path to write crash logs because default paths might not be available
for portable setup.
openmw/apps/openmw/mwinput/controlswitch.hpp:32:49: error: ‘uint32_t’ has not been declared
32 | void readRecord(ESM::ESMReader& reader, uint32_t type);
| ^~~~~~~~
openmw/apps/esmtool/labels.hpp:63:25: error: ‘uint32_t’ was not declared in this scope
63 | std::string recordFlags(uint32_t flags);
| ^~~~~~~~
openmw/components/detournavigator/recastmesh.hpp:91:14: error: ‘uint8_t’ in namespace ‘std’ does not name a type; did you mean ‘wint_t’?
91 | std::uint8_t mLength;
| ^~~~~~~
| wint_t
openmw/components/platform/file.hpp:9:23: error: found ‘:’ in nested-name-specifier, expected ‘::’
9 | enum class Handle : intptr_t
| ^
| ::
openmw/components/settings/settings.hpp:63:21: error: ‘int64_t’ in namespace ‘std’ does not name a type
63 | static std::int64_t getInt64(std::string_view setting, std::string_view category);
| ^~~~~~~
openmw/components/esm/common.cpp:5:38: error: ‘uint32_t’ in namespace ‘std’ does not name a type; did you mean ‘wint_t’?
5 | std::string printName(const std::uint32_t typeId)
| ^~~~~~~~
| wint_t
If directory path is a symlink it should be showed and written to config files
as is. Between launcher runs the resulting canonical path may be different so
the resolved path becomes outdated.
Skipping the simulation, switching off collisions, and other approaches were not correct as they either broke some mods, or some core mechanics of the engine such as teleportation or waterwalking. As it turns out, the way to go is to simply do _nothing_ (modulo some gymnastics to account for the 1 frame difference in case of async).
Scripted movement and the unstucking logic tends to collide. Early out of unstuck in case the actor doesn't attempt to move. This means there is no AI package for NPC, which are the case for some boats and striders, or the player is content with their position.
std::shared_mutex in combination with std::condition_variable_any may
lead to a situation when notify_all does not wake up all waiting threads
on Windows. Use separate std::mutex and std::condition_variable to
notify about new job. Encapsulate all workers synchronization logic into
a separate type.
Limit max bullet supported threads by BT_MAX_THREAD_COUNT - 1
See merge request OpenMW/openmw!2797
(cherry picked from commit 31ae1cd339)
949b9191 Limit max bullet supported threads by BT_MAX_THREAD_COUNT - 1
Round result of std::fmod(hours, 24) to the nearest float below 24 on double to
float conversion when it is not. Add special type and conversion function along
with tests to be used in all places where such conversion happens.
To avoid producing hours equal to 24 due to double to float precision loss.
With it on, which was always the case before this setting was added,
vanilla content and poorly-made mods will look acceptable, but well-made
mods will have alpha-tested meshes appear to grow and potentially gain a
weird outline as they get further away.
With it off, which replicates the 0.46 behaviour, well-made mods will
look really good, but vanilla content and poorly-made mods will have
alpha-tested meshes shrink as they get further away.
It's been bugging me that this was forced on since 0.47 released, and
I'd hoped to figure out a solution for automatic detection at some point
before 0.48 branched off, but I didn't, so now this is what we're
getting to have Tamriel Rebuilt look right.
Add missing content=builtin.omwscripts if openmw is started via openmw-cs
Closes#7056
See merge request OpenMW/openmw!2496
(cherry picked from commit c2b495a187)
6025943f Add missing content=builtin.omwscripts if openmw is started via openmw-cs (fixes#7056)
