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
Fix bug in LuaUi::Element::destroy() that sometimes leads to an infinite loop on UI cleanup
See merge request OpenMW/openmw!3033
(cherry picked from commit 364bc91f5b)
c6eed2a6 Fix bug in LuaUi::Element::destroy() that sometimes leads to an infinite loop on UI cleanup
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.
Shaders, if deemed necessary, get attached to the node mentioned by the
top of the requirements stack. Previously an empty stack was incorrectly
assumed to mean no shaders were required, but we found out that was
wrong. We need to put shaders *somewhere*, and the root of the subgraph
we're modifying should be the best place.
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
Apply minor fixes to Lua documentation
See merge request OpenMW/openmw!2785
(cherry picked from commit 56c8c25a0e)
ccdd381f Minor fixes to Lua documentation
Fix executable for silicon builds
See merge request OpenMW/openmw!2767
(cherry picked from commit 3979d540b1)
f729a280 Fix executable for silicon builds
