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.
Use "pragma max_page_count" to define max allowed file size in combination with
"pragma page_size" based on a new setting "max navmeshdb file size".
* Stop navmeshtool on the first db error.
* Disable writes to db in the engine on first "database or disk is full"
SQLite3 error. There is no special error code for this error.
* Change default "write to navmeshdb" to true.
* Use time intervals for transaction duration instead of number of changes.
If object is too big iteration over all tiles covering it can take too much
time. Limit bounds to a square around a player position to cover only tiles
that will be present in navmesh based on max tiles number option.
Each object is associated with a set of tiles its present in. Culling can
reduce this set but it has to be update when bounds change position. Do this
in TileCachedRecastMeshManager::setBounds updating the set and adding/removing
objects to the corresponding CachedRecastMeshManagers.
Perform all request to db in a single thread to avoid blocking navmesh
generator threads due to slow write operations.
Write to db navmesh for all changes except update as it done for memory cache.
Batch multiple db operations into a single transaction to speed up writing by
not executing fsync after each insert/update query. All reads are performed in
the same transaction so they see uncommited data.
* Change job change type to remove when tile is outside allowed range.
* Swap try number and change type in job priority. To make sure remove jobs
always processed before any other.
When player tile changes distance to player that is part of jobs priority is
invalidated. So jobs are no longer in the right order. This can lead to
processing of farests tiles first.
Sort queue each time player tile is changed.
Add special loading progress bar.
It should be fast enough to not keep loading screen for noticably long but
will provide better pathfinding for actors inside interior cells.
Use LRU modification to hold currently used items. Use RecastMesh binary
data for item key.
Store original pointer of btCollisionShape in user pointer to make available
it as an identifier within all duplicates. Use pointer to heights data array
for btHeightfieldTerrainShape.
When player move fast enough, tiles update for specific area square
couldn't catch player move. Tiles to be removed are left in the queue
with lower priority then tiles to be added which are nearest to player.
This can lead to overflow for amount of tiles. So we try to do remove
first. But we detect change type approximately using mixed change type,
because even if we do it precise, change type could change while job
is in queue.
