When a position is forced, the actor position in physics subsystem is
overriden. The background physics thread is not made aware of this,
its result are simply discarded.
There is a short window where this doesn't work (in this
example, actor is at A and script moves it to B)
1) actor position is set to B. (among others, Actor::mPosition is set to B)
2) physics thread reset Actor::mPosition with stale value (around A)
3) main thread read simulation result, reset Actor::mSkipSimulation flag => actor is at B
4) physics thread fetch latest Actor::mPosition value, which is around A
5) main thread read simulation result, actor is around A
To avoid this situation, do not perform 2) until after 3) occurs. This
way, at 4) starts the simulation with up-to-date Actor::mPosition
Restore projectile caster from savegame (#5860)
See merge request OpenMW/openmw!616
(cherry picked from commit d595c7adb0fb45eafed6d3d0403ad640a91411ed)
c5426bec In the savegame, projectile caster is identified by its actor id. When
This enables accelleration of heightfield collisions.
Unfortunately, `btHeightfieldTerrainShape::processAllTriangle` does not
yet use the accellerator data, so this change does not improve
performance yet but might do so in future bullet versions.
References:
* Accellerator introduced in:
https://github.com/bulletphysics/bullet3/pull/2062
* Feature request to use the accellerator in `processAllTriangle`:
https://github.com/bulletphysics/bullet3/issues/3276
projectile collision shape.
A side effect of moving actors outside of projectile collision shape is that if both the actor and the projectile are
near a wall, the actor could get moved outside of the world.
A prerequisite to create physics objects for statics was to remove the
dependency on base node (since it doesn't yet exists) for object
position. It is still necessary for animation though.
Restore the basenode (and the associated FIXME) so that animated objects works properly.
Since actors can be active in 3x3 grid around the player, we need to
first load all statics in a 5x5 grid around the player.
Split load and unloading in 2 phases. Add an mInactiveCells set into the
scene, which contains all cells inside the aforementioned 5x5 grid.
These cells contains only heightfields and physics objects of static
class.
imprecision issue with projectile collision detection.
Simplify the mechanics: manage hits in one spot.
Give magic projectiles a collision shape similar in size to their visible
model.
Rename the 2 convex result callback to clearly state their purpose.
In this case, the actor mPreviousPosition is not updated, so the actor
position is interpolated between an old (stucked) position and the new
(unstucked) position. The new position is most likely "stucked", so the
unstuck code strikes again, making the actor "vibrates".
That's exactly what the sync code path does, and it doesn't exhibit this
behavior.
What happened is that the last handle to an Actor shared_ptr was a
promoted weak_ptr. When the shared_ptr goes out of scope, the Actor dtor
is invoked. That involves removing the Actor collision object after
exclusively locking mCollisionWorldMutex. In this case, the lock was
already held in the outter scope of the promoted weak_ptr.
Reduce the scope of the mCollisionWorldMutex to never encompass the
lifetime of a promoted weak_ptr.
This unbreak abot's boat mods: they're continually teleporting
the boats (who is an actor with waterwalking effect). As such, the
physics simulation was never run and the boat never went to sea level.
One of the issue since the introduction of async physics is the quirky
handling of scripted moves. Previous attempt to account for them was
based on detecting changes in actor position while the physics thread is
running. To this end, semantics of Actor::updatePosition() (which is
responsible for set the absolute position of an actor in the world) was
toned down to merely store the desired position, with the physics system
actually responsible for moving the actor. For the cases were complete
override of the physics simulation was needed, I introduced
Actor::resetPosition(), which actually have same semantics as
original updatePosition(). This in turn introduced a loads of new bugs
when the weakened semantics broke key assumptions inside the engine
(spawning, summoning, teleport, etc).
Instead of tracking them down, count on the newly introduced support for
object relative movements in the engine (World::moveObjectBy) to
register relative movements and restore original handling of absolute positionning.
Changes are relatively small:
- move resetPosition() content into updatePosition()
- call updatePosition() everywhere it was called before
- remove all added calls to the now non-existing resetPosition()
tldr; ditch last month worth of bug introduction and eradication and redo
it properly
This gives finer control over reseting positions (switch off tcl is no
longer glitchy) and solve most of the erroneous usage of stale World::Ptr
indicated by:
"Error in frame: moveTo: object is not in this cell"
its current position.
Use it in relevant MWScripts opcode (move and moveworld).
Remove the fragile detection of scripted translation from PhysicsTaskScheduler.
No user visible change, just a more robust mechanism.
