The Physics surface provides assertions and adapter methods for testing entity movement, velocity, forces, and ground state. UseDocumentation Index
Fetch the complete documentation index at: https://docs.hrtk.frotty27.com/llms.txt
Use this file to discover all available pages before exploring further.
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
| Method | Parameters | Returns | Description |
|---|---|---|---|
getVelocity | Object store, Object ref | double[] | Get entity velocity as [vx, vy, vz] |
setVelocity | Object store, Object ref, double vx, double vy, double vz | void | Set entity velocity directly |
addForce | Object store, Object ref, double fx, double fy, double fz | void | Apply a force impulse to the entity |
getSpeed | Object store, Object ref | double | Get the entity’s current scalar speed |
isOnGround | Object store, Object ref | boolean | Check if the entity is grounded |
Assertion Methods
| Method | Parameters | Failure Message |
|---|---|---|
assertVelocity | Object store, Object ref, double vx, double vy, double vz, double tolerance | ”Expected velocity [vx,vy,vz] but was [actual]“ |
assertSpeed | Object store, Object ref, double expected, double tolerance | ”Expected speed [expected] but was [actual]“ |
assertOnGround | Object store, Object ref | ”Expected entity to be on ground” |
assertInAir | Object store, Object ref | ”Expected entity to be in air” |
assertStationary | Object store, Object ref, double tolerance | ”Expected entity to be stationary but speed was [actual]“ |
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.
addForceapplies an instantaneous impulse, not a continuous force. The entity will decelerate due to friction on subsequent ticks.
Next Steps
- World Testing - entity spawning and positioning
- ECS Testing - lower-level component access
- Stats & Combat - knockback and damage