Skip to main content
The Physics surface provides assertions and adapter methods for testing entity movement, velocity, forces, and ground state. Use PhysicsTestAdapter to manipulate physics properties and PhysicsAssert to verify them. Physics testing is inherently time-dependent and approximate. Entities move over ticks, gravity pulls them down, collisions deflect them, and forces accumulate over time. This means physics assertions always use tolerances, and you must wait the right number of ticks for the physics simulation to settle.

Physics Testing Limitations

Before diving into examples, understand these constraints:
  • Tick-dependent - Physics state changes every tick. You must call ctx.waitTicks(n) after applying forces or spawning entities to let the simulation process.
  • Approximate values - Velocity and position are floating-point values affected by gravity, friction, and collision. Always use tolerance parameters in assertions.
  • Ground detection lag - An entity spawned in the air needs several ticks to fall and be detected as “on ground.” Wait 2-5 ticks before checking ground state.
  • Server-side only - HRTK tests server-side physics. Client-side visual interpolation is not tested.

Complete Example Suite

Adapter Methods

Assertion Methods

Practical Tips

  • Build a solid floor with ctx.fillRegion(...) before spawning entities if your test requires them to be on the ground. In a void world, entities will fall indefinitely.
  • Wait at least 2 ticks after spawning before checking ground state - the entity needs time to settle.
  • Use generous tolerances (0.5-1.0) for velocity assertions because gravity and friction modify values between ticks.
  • addForce applies an instantaneous impulse, not a continuous force. The entity will decelerate due to friction on subsequent ticks.

Next Steps