Let an aero on the ground end its turn, and say where its altitude went

[HammerGS]

What this changes

An aero sitting on the ground can end its turn again. The unused-velocity check asks isAirborne(), which is true for any aerodyne whatever its altitude, so a fighter at altitude 0 looked like it was still flying and was refused permission to end its turn. It had no way to comply: on a ground map one velocity point costs sixteen hexes of movement, and at altitude 0 every move step is illegal because the aero movement section is gated behind altitude above zero. Move refused and not-moving refused leaves the unit stuck for good. Now exempts an aero at altitude 0 on a ground map.

The altitude report says what the altitude went on. Report 9095 read "loses N altitude(s) from weapon attack", which sounds like the unit was shot down. It fires only when a unit pays for its own air-to-ground attack run: 2 for a dive bomb, 1 for a standard attack, 0 for strafing or an altitude bomb. Nothing an enemy fires reduces a target's altitude. It now reads "loses N altitude(s) making an attack run", with Spanish and Russian updated to match.

Related to #8931

Testing

Tested in game. A fighter at altitude 0 with velocity remaining now ends its turn on Done, where before it was told it had not used all its velocity and the turn would not end.

compileJava, checkstyleMain, spotlessApply and javadoc pass.

What is not proven yet

• No unit test. The behaviour is a Swing nag gate reading entity state; it was verified by watching the gate's own inputs and verdict in the log, before and after.
• The reworded report was read in the properties files, not seen on screen.
• The Spanish and Russian rewordings are mine and have not been checked by a native speaker.

Scope

This came out of #8931 and does not close it. That report has a fighter losing altitude it never spent, which is a separate fault still open. This makes the resulting state survivable rather than terminal.

An earlier version of this PR also added a crash check, on the theory that a fighter could fly itself to altitude 0 on an attack run. It cannot. ComputeToHitIsImpossible already refuses an attack that would take the attacker to zero:

// You can't make attacks that would lower you to zero altitude
if (altitudeLoss >= (attacker.getAltitude() + altLossThisRound)) {
    return Messages.getString("WeaponAttackAction.TooMuchAltLoss");
}

At altitude 1 a standard attack costs 1 and is refused; at altitude 2 a dive bomb costs 2 and is refused. The crash check was guarding a state legal play does not produce, so it has been dropped. Worth knowing for anyone looking at this path in future.

Known and not fixed here

• Eject is illegal at altitude 0. Confirmed in game: an eject step on a grounded fighter comes back MOVE_ILLEGAL, so the crew cannot leave. Being able to end the turn is not the same as being able to escape.
• Entity.isAirborne() reads (!isDestroyed() && altitude > 0) || mode == AERODYNE || mode == SPHEROID, so any aerodyne counts as airborne at altitude 0 and even when destroyed. That is the root of this whole class of problem, and 309 call sites depend on it.

---

• This PR is focused on one issue or RFE
• Every file in the diff has a deliberate change
• Tests added or updated - not applicable; a nag-gate condition and a report string, verified in game
• Javadoc literals use {@code true} / {@code null} rather than bare or quoted text
• Dev team only: AI tools used -> AI Assisted Development label applied

[Copilot]

🟢 Approval recommended

The change is minimal, uses established crash-handling utilities consistently with other call sites, and directly addresses the reported stuck-at-altitude-0 behavior without introducing new API surface.

Pull request overview

Fixes a Total Warfare server-side edge case where an aerospace fighter that loses altitude to weapon-fire-induced altitude loss can reach altitude 0 but not be processed as having crashed, leaving it “airborne” and unable to resolve movement/velocity-gated actions (Issue #8931).

Changes:

• After applying per-round aero altitude loss from weapon fire, immediately check whether the unit has reached a crash condition.
• If a crash condition is met, invoke the existing crash-processing flow to resolve the crash and generate reports.

File summaries

File	Description
megamek/src/megamek/server/totalWarfare/TWGameManager.java	Adds a post-altitude-loss checkCrash() + processCrash() step to ensure weapon-fire altitude loss that reaches the ground triggers a crash resolution.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[HammerGS]

Correction to the description, pushed as af41ea1. The code is unchanged.

I had this as altitude knocked off by weapon fire. It is not. WeaponAttackAction.getAltitudeLoss is the altitude the attacker spends making an air-to-ground attack: 2 for a dive bomb, 1 for a standard attack, 0 for strafing or an altitude bomb. Nothing an enemy fires strips a target's altitude, so the test steps I wrote could never have reproduced it.

The fix still holds. An aero that spends its last altitude attacking a ground target ends up on the ground, and nothing checked for a crash. Reproducing it means dive bombing from altitude 2, or a standard air-to-ground attack from altitude 1.

[HammerGS]

Tested in game and working. Out of draft.

A fighter at altitude 0 with velocity remaining now ends its turn on Done. The gate's own inputs are unchanged, only its verdict:

alt=0 airborne=true unusedVelocity=true ... -> blocks=false

Scope narrowed while testing. An earlier version added a crash check for a fighter flying itself to altitude 0 on an attack run; that cannot happen, because ComputeToHitIsImpossible already refuses an attack that would take the attacker to zero. It was dropped in 739da54 and the reasoning is in the notes.