The One Line That Sank Seven Ships to the Mariana Trench

During a maritime simulation run, all seven ships in the fleet sank to roughly 2,989 m below sea level — Mariana Trench depth. They had been floating fine just the day before.

Buoyancy static-fallback bug — vessel altitude z before/after. With buoyancy off (red), the ships free-fall for ~2 seconds then sink to -2989 m. With buoyancy applied (cyan), they settle at +0.9 m on the surface.

First Clue — "All of Them, Exactly the Same"

When you hit a physics bug, the first thing to check is reproducibility. If the seven ships had sunk to different depths, you'd suspect individual physics parameters — mass, inertia. But all seven sank in exactly the same pattern.

💡 "Deterministic = not a parameter problem" — When every entity fails identically, it's not an individual physics-value issue; it's a shared branch that handles them all together. The fact that all seven trajectories were carbon copies was itself the signal that "buoyancy was never switched on in the first place."

The z trajectories make it clear: immediately after spawning, the vessels free-fall under gravity for about two seconds (z ≈ −19 m), then continue sinking indefinitely because the upward force is zero. Buoyancy was never applied.

The Real Cause — "UUV" Wasn't in the Identifier

In deep-ocean environments without a water mesh, there is a fallback path that creates a virtual water surface to compute buoyancy. The problem was the condition that decided whether to activate the fallback.

The condition was roughly: "If any entity in the fleet has an identifier containing UUV, treat the environment as underwater and enable the buoyancy fallback."

Rendering diagram…

The fleet included a submarine whose identifier contained no UUV substring. The submarine was unquestionably an underwater asset, but its naming convention used a different abbreviation. As a result, the system concluded "no underwater entities present" → the entire fleet's buoyancy setup was skipped → all seven ships went down together.

⚠️ The trap of using substring matching as a gate — Making important branching decisions on checks like "UUV" in identifier means any slight deviation in naming convention silently misfires. And because a single wrong judgment turns off the entire block, the symptom isn't "one ship" — it's "the whole fleet."

The Fix — and the Lessons

The fix was to broaden the detection condition to cover all naval asset types — USV, UUV, destroyers, submarines, and so on — by matching against a comprehensive set of maritime asset keywords including SUBMARINE. After the fix, z went from −2989 m to +0.9 m (settled on the surface) — the cyan curve on the right side of the chart.

This bug left three lessons.

1. Deterministic failure points to a shared branch — not individual values, but the code that handles them all together.
2. Don't use substring/string matching as an important gate — use explicit criteria like type enums or flags.
3. A "non-critical" branch can take down the whole system — one buoyancy line sank the entire fleet.

In a nutshell

📌 The buoyancy fallback was activated by a single "UUV" substring check. Because the submarine's identifier didn't contain those characters, the entire fleet's buoyancy was switched off and all seven ships sank to -2989 m. Deterministic failures point to shared branches; substring gates should be replaced with explicit type criteria — one line can sink a fleet.