To make the order of elements deterministic. Using memory address based objects
as map key makes order of elements there nondeterministic. Later it can be
replaced with vector when there are no indirect munipulations with container
inside iteration loops.
Change map key to const MWWorld::LiveCellRefBase* to avoid erasing and inserting
elements on MWWorld::Ptr update.
Store CharacterController by value instead of pointer to avoid redundant memory
allocation.
Useful when need to find tiles with high number of updates.
Add debug Lua package with new functions to toggle render mode and set navmesh
render mode.
In file included from /home/elsid/dev/openmw/apps/openmw/mwphysics/actor.hpp:7,
from /home/elsid/dev/openmw/apps/openmw/mwphysics/trace.cpp:9:
/home/elsid/dev/openmw/apps/openmw/mwphysics/ptrholder.hpp: In member function ‘osg::Vec3f MWPhysics::PtrHolder::velocity()’:
/home/elsid/dev/openmw/apps/openmw/mwphysics/ptrholder.hpp:42:25: error: ‘exchange’ is not a member of ‘std’
42 | return std::exchange(mVelocity, osg::Vec3f());
| ^~~~~~~~
In file included from /home/elsid/dev/openmw/build/clang/unity/apps/openmw/ub_mwworld.cpp:41:
/home/elsid/dev/openmw/apps/openmw/mwworld/groundcoverstore.cpp:10:9: error: no type named 'Query' in 'MWWorld::EsmLoader'; did you mean '::EsmLoader::Query'?
EsmLoader::Query query;
^~~~~~~~~~~~~~~~
::EsmLoader::Query
/home/elsid/dev/openmw/./components/esmloader/load.hpp:23:12: note: '::EsmLoader::Query' declared here
struct Query
^
Some managers may use the environment in the destructors. Setting them to
nullptr may lead to nullptr dereference when the object is still alive and can
be accessible. But after object is destructed it's UB anyway to dereference
nullptr or a dangling pointer.
Simultaneously writing to sqlite3 database is not possible. Process exclusively
locks the database for this. Another process will fail to perform any request
when database is locked. Alternatively it can wait. Handling this situation
properly requires complexity that is not really needed. Users are not expected
to run multiple openmw processes simultaneously using the same navmeshdb.
Before this change running multiple openmw processes using the same navmeshdb
can lead to a crash when first transaction fails to start because there is
exception thrown and not catched.
Remove use of explicit transactions from DbWorker. Handling all possible
transaction states due to different errors brings unnecessary complexity.
Initially they were introduced to increase time between flushes to disk. This
makes sense for navmeshtool because of massive number of writes but for the
engine this is not an issue.
