---
id: mounting
title: A platoon aboard a transport is worth something the basis cannot say
status: open
dependsOn: [candidates, features]
exitCriterion: >
  A carried unit's worth is scored, and a platoon offered a ride takes it when
  the ride is worth more than the ground.
---

# mounting

The route exists and nothing chooses it. `canCarry` is on the wire, a candidate
that walks into a carrier's hex and ends with `LOAD` is generated, and in the
acceptance scenario it was offered once and declined:

| round | the platoon chose | mount offered |
|---|---|---|
| 1 | stand @ (6,1) | 0 |
| 2 | stand @ (5,0) | **1** |
| 3-7 | stand / flank | 0 |

It is scored as an ordinary stand in the carrier's hex - no line of sight,
nothing adjacent - so it loses to every alternative, and by round 3 the platoon
had walked away and it was never offered again.

## What a carried unit is worth

Two things are measured and **no current column expresses either**:

- it **moves at the carrier's speed**. A foot platoon runs 1 and a Badger runs
  9, so the ride is worth **nine times its own pace**; a Maxim hover transport
  is 12. A battle armour squad runs 4, so the same Badger is worth 2.3 - the
  multiplier is a fact about the pair, not about mounting.
- it **cannot be shot at separately**: `Entity.isTargetable` answers false once
  the transport id is set.

**Whether it can fire is unverified.** `isEligibleFor(FIRING)` answers *true*
for a carried unit, which is not the same question as having a legal shot, and
the difference has not been settled. Do not price a silence that has not been
measured.

So the trade is at least mobility and protection, bought with something not yet
established. The question this epic answers is what that is worth.

## What mounting is

**A `MoveStepType`, not an action.** `LOAD`, `MOUNT` and `UNLOAD` are steps, so
mounting belongs to the movement decision, and `SdsClient.buildPath` already
carries them - `MoveStepType.valueOf` has no whitelist. Measured: `FORWARDS+LOAD`
is legal at 2 MP, `MOUNT` at 0, `LOAD` alone from an adjacent hex refused.

**Stacking and loading are separate permissions.** A carrier's hex is barred by
stacking and open for loading, and MegaMek grants the two independently, so a
carrier that can take a unit makes its hex *terminal*: it may end there, and
nothing walks through. Without that the search never reaches the carrier and
there is no route to append `LOAD` to.

**Three predicates, and they are not the same question:**

- `Transporter.canLoad` - capacity and type alone, blind to where the machines
  are. It accepts a foot platoon into a `FixedWingSupport` flying at elevation
  999.
- `Entity.canLoad` - that plus a position check. The boolean toggles it:
  `canLoad(e, false)` matches the transporter, `canLoad(e)` applies it. **This
  is the one to ask.**
- `MovePath.isMoveLegal` - neither. It is true for an Atlas that has no handles
  for the squad, because it validates the path; the load is resolved by the
  server afterwards.

## Open

- [ ] **What a carried unit is worth**, per the trade above.
- [ ] **A route cannot name what to load, so the load never happens.** Answered,
      and it is a protocol gap rather than a generation one. A route is a list
      of step names, so `SdsClient.buildPath` calls `addStep(MoveStepType)` and
      never the `(MoveStepType, Targetable)` overload that names the carrier.
      Measured: a bare `LOAD` step reports `target=null` and the same step given
      the carrier reports it by name - **and both are `isMoveLegal` true**,
      which is why nothing caught it. In a match the platoon's menu narrowed to
      the single mount candidate, it chose it, it walked into the carrier's hex,
      and `carriedBy` stayed empty. Fixing it means a step that can carry a
      target id.
- [ ] **What a carried unit may do**, once one can be carried.

## Getting off is the carrier's decision

**A carried unit gets no turn**, so nothing asks it where it wants to be put
down: in a match, from the round after it mounts, only the carrier is ever
offered a movement decision. `UNLOAD` is measured to match - it is the
*carrier's* step, and every form of it on the passenger's own path is refused:

| path | form | legal | mp |
|---|---|---|---|
| carrier | `UNLOAD` bare | no | - |
| carrier | `UNLOAD` naming the passenger | **yes** | **0** |
| carrier | `FORWARDS` then `UNLOAD` naming the passenger | **yes** | 1 |
| passenger | any form | no | - |

**Three steps, three different rules**, which is why each was measured rather
than reasoned from the last: `LOAD` is refused from an adjacent hex and
`MOVE_ILLEGAL` from inside the carrier's own; `MOUNT` is the passenger's, legal
from beside the carrier, and free; `UNLOAD` is the carrier's, needs the
passenger named, is free, and is legal both standing still and after driving.

So a drop costs the carrier nothing but the ground it covers, and the carrier
can move and then put its passenger down.

### What a drop does, measured

**The named hex is honoured.** The carrier sent
`{"name":"UNLOAD","target":1,"hex":{"x":3,"y":1}}` from (3,2) and the passenger
was on (3,1) in the next frame, twice in one match. So a drop location is chosen
rather than decided by the rules, and `SafeDropoff` has something to choose
between.

**A dropped unit gets a movement turn the following round.** Dropped in round
2's movement phase, it was asked for a movement decision in round 3.

**A unit dropped in the movement phase gets neither a firing turn nor a
movement turn that round.** Measured on `scenarios/tactics/mount-close.mms`,
where the same platoon is asked for firing decisions with a menu of seven in
five other rounds - so the absence in the drop round is the drop and not a lack
of targets:

| round | passenger's movement turn | passenger's firing turn |
|---|---|---|
| 1-3 | yes | yes, 7 candidates |
| 4 | yes (it mounts) | - |
| **5** | **none - the carrier unloads it** | **none** |
| 6 | yes | yes, 7 candidates |

Two instruments failed before this one and both failed on the target rather than
the mechanism: a Locust that stayed out of the platoon's range all match, and a
gun emplacement that was destroyed in round one and stalled the match. An
UrbanMech walks 2 and survives.

**The jar agrees, and names the mechanism.** `MovePathHandler.processSteps`
sends an `UNLOAD` step to `TWGameManager.unloadUnit`, which reaches
`Entity.setTransportId(-1)`; that one setter sets both `unloadedThisTurn` and
`done`. `isSelectableThisTurn` is false while either holds, and
`determineTurnOrder` allocates turns only to entities that pass it, so no firing
turn is generated. `isEligibleForMovement` tests `unloadedThisTurn` directly.
`resetEntityPhase` clears `done` between phases but not `unloadedThisTurn`,
which is cleared only in `Entity.newRound` - which is why the flag survives
movement into firing. The one exception is a grounded Small Craft unloading
something that is not infantry: that branch clears both flags and grants a
movement turn at half MP. It grants movement, not shooting.

**This is what MegaMek does. Whether it matches the rules is a question for
jmm.** In particular, a dropped unit shooting the round it is put down is a
thing the code refuses in every branch, and it is worth confirming that is the
rule rather than an implementation choice.

So a drop is positional: what the passenger gets is a place to be at the start
of its next turn, and `SafeDropoff` is about where it wants to *stand*, not
where it wants to shoot from this phase.

**This is what MegaMek does. Whether it matches the rules is not established
here.**

### Four duties and two profiles, one mechanism

`TaskOverride` and `TacticOverride` now carry `Spot`, `Board`, `Carry`,
`Deliver`, and the `Embark` and `SafeDropoff` profiles. **None of them needed
new machinery.** `Spot` was expressible in existing columns, `Embark` found the
basis gap and recorded it, and the drop-off column is the one addition jmm has
sanctioned. Four consumers of one design is a better answer to "can tactics be
built from what exists" than any single tactic working.

### The algorithm, as jmm gave it

- Calculate eligible moves for the carrier with normal feature scoring
- From that set, calculate all eligible drop-off points for the passenger
  (typically a subset of moved locations + possibly some adjacency superset
  depending on type of dismount)
- For the set of all possible drop-off points, score the passenger's evaluation
  of where it would LIKE to go
- For all scored drop-off points, they give their score to the hex the carrier
  would have to walk to, in order to use that drop-off point
- This is now a per-hex feature for the carrier, which is 0 in hexes that aren't
  drop-off eligible, and some normalized-to-1 as "best dropoff I could ask for"
- The carrier has a TacticsOverride to have it even consider that feature which
  would normally be weighted 0

**It is a back-projection.** The passenger's valuation of a drop hex flows
*backwards* through the reachability relation onto the carrier's move hex that
would enable it. The carrier is not evaluating the passenger; the passenger's
own scoring is being projected.

**And it is a new column**, which is worth stating rather than slipping past:
`Spot` needed none, `Embark` found a gap and recorded it, and this one jmm has
explicitly sanctioned.

### The clamp is the hard part

> The biggest issue with this is that we have to ensure the feature stays 0 if
> none of the drop-off points are any good for the carried unit at this time.
> That's how you don't have 3-range infantry mount, and then immediately
> dismount next turn not being any closer to the enemy. If none of their hexes
> would lead to good shots they should score the hex 0 as a clamp.

**A relative normalisation defeats this outright.** "Normalised to 1 as the best
drop-off I could ask for", read as *best within this set*, makes the least-bad
drop of a uniformly bad set score 1 - and the platoon dismounts pointlessly,
which is the anti-pattern the clamp exists to stop. The reference has to be
absolute: what a good position is *for that unit*, not the best of what is on
offer.

**`range_band_fit` is the measure, and two halves of it had to be fixed
before it could read.** Both were found by using it, and both were the same
defect in different places: a conventional platoon's numbers are not on its
weapons.

- **The damage.** `projected_damage` summed `weapon.damage`, and
  `WeaponType.getDamage()` answers a sentinel for an infantry weapon - `-15.0`
  for a point that delivers 3.00. `ConvInfantry.getDamagePerTrooper()` times the
  trooper count is the real figure, it is on the wire as `infantryDamage`, and
  `projected_damage` reads it.
- **The reach.** Fixing the damage moved the column not at all, because
  `projected_damage` still asked `brackets::projected` for the shot - and that
  refuses a weapon whose bracket damage is nought *before* it reports the range.
  Every bin on a conventional infantry weapon is nought, so the rifle that does
  the shooting was thrown away at the damage gate. Measured off the wire, the
  25-trooper Motorized Infantry platoon's whole armament:

  | weapon | usable | short | medium | long | damage bins |
  |---|---|---|---|---|---|
  | Rifle (Bolt-Action) | yes | 0 | 0 | **3** | 0.00 / 0.00 / 0.00 |
  | Swarm Mek | yes | 0 | 0 | 0 | 0.00 / 0.00 / 0.00 |
  | Stop Swarm Attack | yes | 0 | 0 | 0 | 0.00 / 0.00 / 0.00 |
  | Leg Attack | yes | 0 | 0 | 0 | 0.00 / 0.00 / 0.00 |

  The rifle's long bracket of 3 is the only range in the list, and it is the
  three-range platoon of jmm's requirement. `brackets::reaches` answers the half
  that is populated - which bracket, and what the range and the weapon's own
  modifier charge - and the platoon supplies the damage.

With both, `best_damage` for that platoon reads 0.24 where it read 0.00, and
`range_band_fit` reads 1.00 inside three hexes and 0.00 beyond.

### The clamp, demonstrated

`scenarios/tactics/mount-approach.mms` is the instrument, and it exists because
neither earlier scenario could ask the question. `mount-probe.mms` mounts
reliably and its enemy is never in reach, so every drop reads nought and a
working clamp is indistinguishable from a broken one; `mount-close.mms` starts
everybody on one edge, where the platoon has a shot from the ground and never
boards. This one puts them in sequence: the pair deploy apart, the platoon
boards while there is nothing to shoot at, and the carrier then drives the
length of the board towards an UrbanMech slow enough to still be there.

So the same question is asked in both directions inside one match. Seed 1:

| round | carrier | enemy | drop hexes offered | best worth | past the clamp | carrier chose |
|---|---|---|---|---|---|---|
| 1 | (3,2) | (12,14) | - | - | - | the platoon mounts |
| 2 | (3,2) | (12,11) | 6 | 0.00 | **0** | drives to (3,8) |
| 3 | (3,8) | (10,10) | 4 | 0.00 | **0** | drives to (8,9) |
| 4 | (8,9) | (9,9) | 4 | 1.00 | **4** | **drop at (7,8)** |
| 5 | (8,9) | (9,9) | - | - | - | the platoon is on the ground at (7,8) |

Both outcomes, and the reason differs the way the requirement says it should:
in rounds 2 and 3 the enemy is seven and eight hexes off, outside the rifle's
three, so a platoon put down there would be no closer to anything. In round 4 it
is adjacent.

**It clamps within a round as well as between them.** On seed 2 and later in
seed 1 the carrier offers six hexes and keeps two, so this is a per-hex bar
rather than a per-round switch: the hexes beside the carrier are not all worth
the same.

**For this passenger the column is a step, not a slope**, and that is a fact
about the design rather than about the feature. A bolt-action rifle has a single
bracket - `0 / 0 / 3` - so its to-hit is the same at one hex as at three, and
`range_band_fit` reads 1.00 everywhere inside the reach and 0.00 outside it. That
is all a clamp needs, and it is not enough to *rank* one drop hex above another
by range. A passenger with two brackets would separate them; this one cannot.

**Suppressing them all is how the carrier drives on**, and it needs no separate
branch. `Duty::Deliver` narrows the carrier's menu to its `UNLOAD` routes; with
none left the narrowing is empty, `harmonise::constrain` restores the whole
menu and counts the duty unsatisfiable. Rounds 2 and 3 above are that count.

See `plan/ev.md` for the category the damage figure belongs to - four weapon
classes now where `getDamage()` returns a code.

**The pattern is still right.** It is `Bounded`, and its denominator is `best_damage(posture.unit)` -
the unit's own best firepower - so it scores against that unit's own standard
rather than against the board, the force, or the other candidates. Its zero case
is the clamp, already written: *"A machine with nothing left to fire has no band
to be in. Zero rather than a half: there is no range that would help it."*

### Two jobs, and the vocabulary already separates them

"A feature like *this is my best option*" and "stay 0 when none of them are any
good" pull against each other: the least-bad drop of a uniformly bad set **is**
that unit's best option. They are two jobs and the basis already distinguishes
them.

- **`Local`** is min-max across this decision's own candidates - literally "my
  best option". It exists: `damage_lead`. And **`Weights` will not accept it**,
  enforced by a `compile_fail` doctest, because a local column "means nothing
  across two decisions". It ranks a menu and cannot be weighed against anything
  outside it.
- **`Bounded`** means *a rule gives the domain*, and the rule may be about the
  unit: `range_band_fit` divides by `best_damage(posture.unit)` and returns zero
  when the unit has nothing that would help.

**So the carrier's column must be `Bounded` with a per-unit reference, and the
clamp is its zero.** The carrier is not choosing among drops - it is weighing
*dropping* against *driving on*, which is a comparison across candidates of
different kinds, and a `Local` column cannot be weighted into that at all. A
self-relative ranking is welcome *inside* the drop set, where argmax is the only
thing asked of it.

That resolves both of jmm's constraints without a fourth normalisation: rank
within the set if it helps, but what reaches the carrier is measured against the
passenger's own standard, and is nought when nothing clears it.

**This is a missing feature, not a missing capability.** `Bounded` demonstrably
takes a per-unit reference today, so the drop-off column is a feature to write
rather than a normalisation to invent.

- [x] **Where to drop, scored as the passenger.** `Posture` already carries the
      candidate hex beside the unit and every positional feature is written
      against that pair, so scoring a unit at a hex it does not occupy is what
      `pathfind` and `stands` do every turn. What is missing is only that
      generation is driven from the actor - `generate(.., me, ..)` builds one
      unit's menu - so this needs the generator callable for a non-actor unit.
      **It is plumbing, not a new evaluation model**, and it is not
      `TacticOverride`: that gives a unit different weights for its *own*
      candidates, where this is one unit's turn producing another's.
      Both are only observable in a match. `TWGameManager.loadUnit` sends a
      packet and throws without a live `Server`, so unlike motive damage this
      cannot be driven headlessly - and `Entity.load` is only half the
      operation, leaving the cargo's own `transportId` at -1 and the unit still
      reading as targetable. **The acceptance scenario is the instrument**, not
      a convenience.
- [ ] **Which battle armour may ride a Mek.** A Black Hawk (Nova) A carries an
      `Elemental Battle Armor [Laser](Sqd5)` and refuses a
      `Fenrir Battle Armor [ERML](Sqd5)` - same carrier, same
      `BattleArmorHandles` - so the gate is a property of the squad. Generation
      is unaffected: it asks `canLoad` and gets the right answer either way.

A carrier is a specific population: an Atlas and a Manticore have `MekArms`,
`ClampMountMek`, `RoofRack` and `TankTrailerHitch` and carry no infantry at all.
286 designs have an `InfantryCompartment`, and the 1047 with
`BattleArmorHandles` are all OmniMeks.