Hive Lord logic
Hive Lords do not simply chase the nearest Helldiver. They check player slots in order, then look for a valid underground route point for that player before moving on to the next slot.
- Player priority
- P1 → P4 slot order
- Far destination range
- 150–400 m
- Near destination range
- 30–80 m
Player-slot targeting
Player priority is ordered. Available underground routes determine whether the game moves on to the next player.
The game checks its player list from the first slot upward. For each player, it searches the underground route network for a point that passes the active distance and placement checks. A successful player and route-point pair is accepted immediately.
There is no nearest-player comparison in this step. Distance is checked between route points and the player being tested, not used to rank Helldivers by distance from the Hive Lord.
This establishes player-slot order. In observed lobbies those stable slots appear to correspond to the host first and later joiners after them, but that host/join-order label remains an observed mapping rather than a confirmed in-game name.
| Selection step | Rule | What it does |
|---|---|---|
| Player order | Player-slot order | The game checks player slots in order and stops on the first player with a valid underground route point. |
| Player fallback | Next slot only after failure | If every route point fails for the current player, the game advances to the next player slot. |
| Player distance ranking | None in this selector | Players are not ranked by distance to the Hive Lord here. Distance is checked between route points and the player being tested. |
| Route-point search | Random start; wraps around | The search starts at a random route point and wraps through the list until one passes. |
| Selection result | First valid route point | The first passing route point becomes the destination immediately. |
Moving closer does not move you ahead in the player queue.
A later player can be much closer to the Hive Lord and still lose priority to an earlier player slot if that earlier player has at least one valid underground route point.
Priority and routes
- 01
Check the first player slot
The game begins with the first player slot. It does not first calculate which Helldiver is nearest to the Hive Lord.
- 02
Search underground route points for that player
The game evaluates underground route points against the active distance range and other placement checks.
- 03
Choose a valid route point
If that player has an eligible route point, the selected point becomes the underground destination.
- 04
Only then fall through to the next player
If no route point works for the current player, the game advances to the next player slot and repeats the search.
- 05
Move toward the selected destination
Current code confirms destination selection. The interactive model therefore moves directly toward that destination instead of inventing an unconfirmed route between points.
- 06
Re-evaluate through behavior state
Current code uses both far and near destination ranges. Other movement and emergence rules still need complete mapping.
Route choice can vary without changing player-slot priority.
The selected route point can vary between evaluations, but player slots are still considered in order. Route variation can change the destination without changing which player gets first consideration.
Route simulation
The viewer uses five underground route networks captured directly after landing. Empty areas are places where no route points were generated; they are not artificial cave masks.
The simulation uses the current 150–400 m far and 30–80 m near destination
ranges. It checks simulated player slots in order and moves the Hive Lord directly toward the selected
underground destination. Use the player-count control to add P2–P4, choose which player a map tap moves,
and place an earlier player where no valid route points are available to see it move to the next slot.
Tap to move the selected player, drag to pan, pinch with two fingers to zoom, or use the compact map controls. A far-range arrival hands off to the near-range loop. After each near-range arrival the accelerated model runs pre-emergence, surface, and dive, then selects another near destination and repeats. The automatic condition that exits this close-emergence phase is not yet mapped, so the viewer leaves that transition manual.
Empty areas are left empty rather than drawn as cave masks. The simulation checks player slots in priority order, selects the first slot with a valid destination, and moves the Hive Lord directly toward that node. After a SHORT arrival it now repeats the close-emergence cycle instead of returning to LONG after one emergence. The exact automatic SHORT-phase exit is unresolved, so the viewer does not invent one. Displayed connections use the reconstructed 18 m / four-neighbor graph links.
Destination ranges
The current build uses both 150–400 m and 30–80 m destination bands. Both are active, and the near-range behavior can repeat during the close-emergence phase.
Destination choice varies among eligible route points. A destination must also stay at least 100 m from other live Hive Lords.
| Destination logic | Mapped rule | What it does |
|---|---|---|
| Far destination search (LONG) | 150–400 m | Looks for a destination 150–400 m from the player being tested. |
| Near destination search (SHORT) | 30–80 m | Looks for a destination 30–80 m from the player being tested. |
| Distance from other Hive Lords | ≥100 m | Destinations too close to another live Hive Lord are rejected. |
| Older arrival check | <5 m in 3D | Older code treats the destination as reached inside a 5 m 3D radius. |
| Older directional search | 40–60 m; 35° | Older code contains a separate route-point search limited by both distance and direction. |
| Older paired-point search | <50 m from Hive Lord; <40 m from reference | Older code also contains a paired route-point search with two horizontal distance limits. |
| Route connections | ≤18 m horizontally; up to 4 neighbors | Older code links nearby route points in both directions with at most four stored neighbors. |
Underground route graph
The game generates a dedicated network of underground route points for Hive Lords and groups connected points together. Destination selection uses this network rather than choosing any position on the map.
The displayed connections are a processed reconstruction of each captured underground route network. They show connected route regions, but do not establish that the Hive Lord physically follows every displayed connection as a waypoint sequence.
Evidence status
| Finding | Evidence |
|---|---|
| Current destination selection checks player slots in order and stops on the first player with a valid underground route point. | Confirmed |
| Current destination selection does not rank players by distance to the Hive Lord. | Confirmed |
| The current build uses both 150–400 m and 30–80 m destination ranges. | Confirmed |
| The route-point search starts at a random position, wraps through the list, and accepts the first valid point. | Confirmed |
| The game generates an underground Hive Lord route network and groups connected route points together. | Confirmed |
| The chosen underground route point becomes the Hive Lord destination. | Confirmed |
| It is not yet established that the Hive Lord physically follows every displayed route connection as a waypoint sequence. | Unresolved |
| The code establishes player-slot order, but does not label slot 1 as “host”; host-then-join-order is an observed interpretation of those stable slots. | Supported |
Evidence standard
How the OTL separates code confirmation, controlled live testing, and behavior that remains unresolved.
How the OTL rates evidence
The OTL rates code evidence and live-game evidence separately. A mechanic can be clear in code but still need a controlled gameplay check for hidden state, ordering, or another runtime factor.
Live confirmation means controlled gameplay or instrumented runtime observation, not player impression alone.