This means the shared memory struct is just 255 bytes longer than a few
commits ago instead of 32K.
Also introduce a function for putting path strings in the shared memory
as there was too much copied and pasted code and it was error-prone.
Also free some handles once we're done with them so they don't leak.
Manual port of https://gitlab.com/OpenMW/openmw/-/merge_requests/3221 to OpenMW 0.48
Update CHANGELOG.md with a missing entry
See merge request OpenMW/openmw!3182
(cherry picked from commit 462d1c5278)
ba8fbfd9 Update CHANGELOG.md with a missing entry
Create a stateset for every particle system to create its own defineMap
Closes#7304
See merge request OpenMW/openmw!3162
(cherry picked from commit 558b3cbf60)
a08d921c Create a stateset for every particle system to create its own defineMap
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
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.
