Six ways to misconfigure a sandbox.
None of them log anything.

The static and physics paths build genuinely different things. A static entity gets a trimesh collider — exact, concave, and correct to stand on. A physics entity gets a convex one, because the physics engine will not simulate concave shapes; so a spawned archway you can walk through as scenery becomes a solid lump the moment you set physics: true.

Two smaller things worth knowing. count is clamped to a minimum of one, so "count": 0 spawns one object rather than none. And scale on a physics entity is applied to the mesh and collider rather than the body, which is the correct way to do it but means the two paths respond to scale through different machinery.

The symmetry is the one to internalise. There is no such thing as a one-way aggressor here — you cannot set up a predator that hunts a prey faction which ignores it, because declaring the hunt makes the prey hostile back. If you want that asymmetry you get it from behaviour, not from relations: give the prey a low health pool so it crosses the flee threshold on the first hit.

Both surprises come from the same two simplifications. There is no raycast anywhere in the visibility check — geometry between two agents has no effect on whether they see each other. And the whole calculation is flattened onto the ground plane, with height discarded before the distance is measured, so an agent directly overhead sits at a flat distance of zero and counts as seen at any altitude.

Neither is a defect. The sandbox exists to watch faction logic and behaviour states play out on an open plane, and it is built for exactly that. But it does mean the sandbox cannot answer questions about cover, stealth, elevation or blocked sightlines, because it is not modelling any of them — and a run that looks like a stealth test is measuring something else entirely.

guard and idle are the same code path. The two names exist to let you say what you meant, which is worth something in a file someone else will read, but they produce byte-identical behaviour. Do not expect a guard to defend a position more stubbornly than an idler; nothing distinguishes them.

And three of the six rows above give you a motionless agent — but only one of the three is a spelling mistake. The other two are things you asked for. A patrol with an empty waypoint list falls through to the same branch as an unrecognised name, so "my patroller isn't patrolling" has two quite different causes that look the same.

Because nothing is random, a fight's outcome is decided before it starts — who wins follows from health, damage and who closed first. That is the point: it makes a sandbox run repeatable, so when you change one number you are looking at the effect of that number rather than at noise.

The flee rule has a detail worth holding on to. Fleeing is a reaction to a visible threat, not a health state: an agent at one percent health with nobody in its cone goes back to patrolling quite happily. It only runs while it can see what it is running from — which also means it stops running the moment the threat leaves its cone, and, since the retreat direction is recomputed every frame as "away from that agent", it runs in a straight line with nothing to stop it leaving the ground plane entirely.

Sequencing is strict, and it has a consequence people miss: an objective that is already satisfied still waits its turn. If objective three is "eliminate the ghosts" and there are no ghosts, it does not fire early — it fires the instant objectives one and two are done.

★ The timer restarts at every objective. Two objectives of one second each take two seconds, not one, because seconds is measured from the previous objective's completion rather than from the start of the quest. The data contract's own documentation says "since the quest started"; the code disagrees, and the code is what runs.