Known Issues

Confirmed, and fixed — you were right on all three counts. When your assault on Circinus completed (all 5 stages cleared, world taken), one stage drop from earlier in the campaign was never closed out. It sat there as a live operation belonging to a campaign that had already ended, which put it in a blind spot: the Engagements list skips assault drops because they belong to the Planetary Assaults view, and the Planetary Assaults view only shows campaigns still in progress. So nothing could show it to you, and nothing would ever resolve it — while the Circinus planet panel kept reading that live operation and flagging the world as under attack, by you, on a world you own. The stale operation has been cleared. Circinus should read normally now — no attack banner, nothing lingering. No forces of yours were tied up by it, so there is nothing to release and nothing lost. The underlying cause is fixed too: closing a won assault now closes any drop still open inside it, and there is a new integrity check that fails the build if an operation is ever left orphaned this way again. Four of the five ways an assault can end already cleaned up correctly — the ordinary "you won" path was the one that did not, which is why it took a completed conquest to expose it. Thanks for the report, and for the detail: "I own the world and it's not in my attack list" was what pinned it down.

This one's working as designed, though it isn't obvious. Buildings block line of sight, and a 'Mech that's wedged in among them can be genuinely un-shootable from the open hexes next to it — being adjacent isn't enough on its own if there's structure in the way. The answer is to shoot the buildings. Flatten the ones boxing it in and you'll open a firing lane, then engage normally. Worth knowing that on a dense city board levelling one building often still leaves another in the line, so it can take more than one before the angle opens up. Closing this since we sorted it out directly, but the technique is the general solution any time something tucks itself into cover you can't shoot through.

Checked the world (Star Cluster V-1092) and everything on it is settled: the trial you cancelled is closed out, the follow-up trial resolved in your favour, and the capture campaign is marked withdrawn. You have no defensive assault pending there now. So this cleared on its own around the time you reported it. Your read on the cause was right — the cancelled trial was the thing holding it — but there's nothing left stuck to fix. Closing this one. If the queue still shows it on your end, say so and we'll reopen: that would mean the display is out of step with the data rather than the assault still being live.

You were right, and it was closer than it looked. A Trial required the defender to field at least 90% of the challenger's bid. Against CSJ's 83,405 that meant 75,065 — and thirty Executioners come to 74,910. You were short by 155 BV, about a fifth of a percent, with no way to see the target you were missing. Out of the 39 chassis available to you, exactly one could have cleared that bar: thirty Kingfishers and nothing else. Any other choice, or any mix, failed. The reason it was that tight is a pricing fault on our side. The challenger's bid was calculated with a pilot-skill bonus that your side only received if you fielded elite pilots, so a "90%" floor was really asking for about 108% of their actual force. The floor is now gone. You can answer a Trial with whatever you can actually field, up to the challenger's bid. The upper caps still apply — no more BV, no more 'Mechs, and no more per wave than they brought — but there is no longer a minimum. Your Trial for Star Cluster V-1092 is still open, so you can answer it now with your best force. One honest warning: fielding less than the challenger means fighting at a disadvantage, and you may lose the world for it. That is now your call to make rather than a wall you cannot get past. And yes — we do get pinged when you reply to a ticket. Your Stooping Hawk follow-ups came through; that one is still in the queue.

Fixed — thanks, the numbers were exactly right and four of them were wrong on our side. CORRECTED: · Clan Rotary AC/5 — was 8 tons / 6 crits, now 10 tons / 8 crits · Rotary AC/2 — heat was 3/shot, now 1/shot · Rotary AC/2 — medium range was 7-13, now 7-12 ALREADY CORRECT (checked rather than assumed): · Rotary AC/5 (IS) — 10t, 6 crits, 1-5 / 6-10 / 11-15, 20 shots/ton · Clan Rotary AC/5 ranges — 1-7 / 8-14 / 15-21 · Rotary AC/2 — 8t, 3 crits, 2 damage/shot, 45 shots/ton, 13-18 long Two things worth mentioning. The RAC/2 heat was stored in two places that disagreed with each other (one said 3, one said 1), and a recent change had made the wrong one authoritative. Chasing yours turned that up, so it's now consistent everywhere. Making the Clan RAC/5 two tons heavier pushed the Battle Cobra BTC-J over its weight limit — it's the only design carrying one. Its armour has been re-fitted to suit, so it's legal again and you may notice it's a little less armoured than before. One thing NOT done: you gave Clan stats for the RAC 2 as well, but a Clan Rotary AC/2 doesn't exist in the game and nothing mounts one. Adding it would be new equipment rather than a stats fix, so we've left it — say the word if you want it in and we'll add it with the numbers you supplied.

Mostly fixed for 1.0 — thanks, and thank Shadow too. All four Zeus X variants now run composite structure and reactive armour instead of standard everything, with the armour re-fitted to the tonnage composite frees up. The XXL engine we can't do yet: we only model standard, XL and Clan XL, so an XXL is new equipment rather than a data fix, and we're not adding equipment before 1.0. The engine stays a standard 400 for now. Worth mentioning what this turned up: composite and reinforced structure existed in our data but nothing could actually reference them — set a mech to composite and it silently failed to apply. The Zeus X is the first design in the game that uses one, so your report fixed a hole well beyond this chassis. Ships with the 1.0 release, XXL logged for later.

Fixed for 1.0, and thanks — the asymmetry you described was real and there was no rule behind it at all. Attacking a faction you're allied with used to cost nothing. The code even recognised the case (it skips you when notifying the defender's allies) and then did nothing about it, so an ally could hit you repeatedly for free, which is exactly what you were seeing with Clan Ghost Bear. How it works now: · Trial of Possession or Trial by Combat against an ally — allowed, as it should be. Costs you a little standing with them; the alliance holds. · Anything else — planetary assault, raid, recon, tech theft — drops your standing with them hard and ENDS the alliance on the spot. The AI is bound by the same rule, verified rather than assumed: every path that creates an attack runs through the same code, so there's no back door. Separately, every attack now moves standing with the target, not just attacks on allies — raiding a neutral costs you something with them too. Ships with the 1.0 release.

Working as designed in 1.0, so closing — but here's the reasoning, because losing a factory world while you're away is a fair thing to be annoyed about. A Trial of Possession now opens with a batchall: the challenger states its bid and you either REFUSE or ACCEPT with a matching force. If you don't answer within 24 hours it AUTO-ACCEPTS and the fight resolves with your force composed symmetrically against theirs — the same even match an AI defender gets. It deliberately does NOT auto-refuse. Refusing a trial declares a war and summons a five-stage invasion, and nobody should get handed that for stepping away from the keyboard. Losing one world to a fair fight is the gentler of the two outcomes. So a Clan can still take a world from you while you're offline — but it has to win an even fight for it, not simply claim it. And if you're around, you set the force yourself. Ships with the 1.0 release.

Fixed for 1.0. Two things changed. Deep water, impassable and void hexes are now excluded from spawn placement outright, so nothing can be dropped somewhere it can't move. And you now pick your own landing zone before the drop, on the real board the battle will load. Ships with the 1.0 release.

Working as intended for 1.0, so closing. 1.0 starts in 3049, when the Federated Commonwealth is a single realm — so it correctly holds forces and worlds. The Federated Suns and Lyran Alliance exist but are deliberately dormant with nothing to their names until the secession fires on 1 September 3057, at which point the Commonwealth splits and its worlds and forces divide between them. So a FedCom with mechs is the 3049 state, not a leftover. Ships with the 1.0 release.

Fixed for 1.0. The reinforcement window is now 2 hours for every regular operation (raid, recon, tech theft, planetary assault and the PA prereqs), and 0 for trials and territory disputes. The day-long wait you were seeing is gone. Ships with the 1.0 release.

Fixed for 1.0 — you were exactly right, including which one looked better where. The Crossbow was bound to the MWO Crusader model and the Crusader to the other one. They're swapped now. Both models already shipped, so this was purely a wiring mistake. For what it's worth, the reason it survived: the Crossbow's model was never registered in our model list, so nothing ever tied that bundle to a name that would have flagged the mismatch. It's registered now. Ships with the 1.0 release.

Addressed in 1.0 — this is exactly what the SIMULATE button does. Both lobbies (offensive drop and PA defence) now carry a SIMULATE option alongside LAUNCH. It commits the identical force you assembled and plays the fight out server-side in the real tactical engine, then streams it back as an overhead replay and the after-action report. So you can set up several drops, hit SIMULATE on the ones you don't want to play by hand, and watch the result instead of fighting or forfeiting. Worth knowing alongside it: in 1.0 the only defence that opens a lobby at all is a Planetary Assault (plus Trials). Raids, recon and tech theft against your worlds resolve on their own, so the pile of manual fights you ran into is much smaller to begin with. Ships with the 1.0 release.

Closing this one against the 1.0 lobbies. The drop lobby was rebuilt for 1.0 and the tonnage accounting went with it — each drop is scoped to the forces actually co-located at that world, and the limits are per-attack force rules rather than a shared pool. We couldn't reproduce the carry-over on the new lobbies. If you do hit it again in 1.0, please reopen with whether the fights were on different planets and whether you were attacking or defending — those are two different code paths and knowing which one narrows it immediately. Ships with the 1.0 release.

Fixed. The Ghost Bear raid you allied a Mech into stalled without ever running its battle, so your Supernova stayed committed and the engagement wouldn't clear. I've released the Mech (back to operational + available for redeployment) and cleared the stuck engagement — a client refresh should update it. Apologies for the couple-day delay. — ARIA Ops

Fixed for 1.0 — and thanks, "fleets which operate normally separately" was the clue that cracked it. Nothing was wrong with the fleets. The merge itself was the problem: when it folded one fleet into another it tidied up most of the things pointing at the old fleet, but missed two — the record of any planetary assault it had led, and any threat it had been dispatched to answer. The database then refused to delete the fleet, and that refusal reached you as a raw 500. So the rule was effectively: once a fleet has run an operation, it can never be merged again. Which is exactly the pattern you were seeing. Both references now follow the merge to the surviving fleet, so the campaign history stays intact and the merge goes through. We also made the endpoint return a real message instead of a 500 if anything similar ever turns up. Ships with the 1.0 release.

Good catch — and you're spot on with the date. The Lyran Secession had been mis-scheduled onto the 3062 FedCom Civil War trigger instead of the canonical 18 September 3057 secession, so it never fired. Fixed. The event now tracks 18 September 3057, and since that date has already passed in the live timeline we've applied the split to the server directly rather than making you wait. The Federated Commonwealth has divided — the Lyran Alliance and Federated Suns are now independent realms (and, true to history, already trading blows along the old border). You'll see it reflected on the map and in the faction rosters. Thanks for the precise report — the exact date made this a fast one.

Good catch — "The Moon 1 Northeast" drops to -42m with sheer cliff faces, so the geometry floats and the AI won't path onto it. We ran a full elevation scan of the whole map library and pulled every board with that kind of extreme/negative terrain (184 of them) for the 1.0 build — "The Moon 1 Northeast" and the rest of the broken "The Moon" set are on the list, so they're out of rotation in 1.0. Thanks for the report.

Addressed for 1.0. Homer exists and Clan Cloud Cobra holds it, along with Babylon and Tanis — the Kerensky Cluster ownership was rebuilt against the lore pack, so Cloud Cobra, Blood Spirit, Star Adder and the rest now sit on their canon worlds. Homer and Zara are one record ("Homer (Zara 2850-)") reflecting the rename rather than two separate systems. If any specific world is still in the wrong PLACE on the map rather than the wrong hands, open a fresh ticket naming it — coordinates are a separate pass from ownership and it's easier to chase one world at a time. Ships with the 1.0 release.

Fixed for 1.0. You were right — the Hammerhead's base model should be Hardened Armour and it was on standard. It now runs Hardened, with the armour re-fitted to suit: 193 points where it previously carried 387. That looks like a big drop but it isn't a nerf — hardened armour is 8 points per ton against standard's 16, and it HALVES incoming damage from every source (energy, ballistic, missile, physical). The trade is -1 running MP, which is the canon cost. Ships with the 1.0 release.

Fixed for 1.0. Streak LRM range brackets now match the numbers you gave: short 1-7, medium 8-14, long 15-21, across the 5/10/15/20 sizes. The 11-hex ceiling you hit is gone. Ships with the 1.0 release.

Two separate things here, and they landed differently. The Targeting Computer is fixed — GSMN-D carries one now, along with the rest of the Clan TC pass. The missing Prime we can't do. I checked every source we have (record sheets, parts, chassis electronics, the loadout snapshot, the lore pack) and the Grand Summoner exists only as A, B, C and D. There's no Prime loadout in any of them. Rather than invent one and call it canon, we'd rather leave the gap honest. So: no plans to implement at this time. If you can point us at a record sheet for the Prime, adding it is quick — the import path is already built.

Confirmed and fixed — you nailed the diagnosis. Heat sinks you ADD in the Mech Lab are stored as individual equipment items, but they weren't being folded into the 'Mech's heat-sink COUNT, and the battle engine was reading only that count. So a design cooled at its BASE rate and the added sinks did nothing — exactly your Marauder IIC: base 13 DHS = 26 dissipation, the +7 you added ignored, so 2 ER PPCs (30 heat) left you +4 over. (Same bug hit a Thunderbolt IIC at 10 base + 8 added — dissipating 20 instead of 36.) The battle engine now counts equipment-mounted heat sinks toward dissipation. Your Marauder IIC will run the full 20 sinks → 40 dissipation, so that 30-heat alpha clears with headroom. Verified against the fix (30 heat, 20 DHS → 0 carryover, vs the +4 you saw). Lands in the 1.0 build. Thanks for the precise repro — the exact heat numbers made this a clean confirm.

Closing this one — the Tempest is shelved for 1.0. You're right on both counts: the model in game is a Marauder rather than a Tempest, and the loadout is wrong. Rather than ship a chassis that's visually a duplicate and mechanically incorrect, we're leaving it out of the 1.0 pass and revisiting it with proper art and a proper record sheet. Ships with the 1.0 release.

Confirmed — "The Country 8" has a -30m sublevel that causes the gapping you noticed. It's in the batch of 184 floating-geo boards we pulled from the map rotation for the 1.0 build, so it's gone in 1.0. Thanks for the report.

Closing this one as obsolete rather than fixed. Same root as your Eden report — the title and the negotiation were reading the world from two different places, and the conversational half could drift. In 1.0 the negotiation is gone entirely. A Trial of Possession is batchall → accept / refuse / launch, and the world is read from the trial record itself, so the title and the fight can't disagree. Ships with the 1.0 release.

Good eye — Tor Miraborg was missing from the Free Rasalhague roster (his portrait was even shipped in the game, just no pilot behind it). Fixed for 1.0: he's restored as an FRR legendary hero, so you'll see him take the field alongside Christian Månsdottir. On Haakon Magnusson — he does legitimately drop in as the Free Rasalhague commanding officer (faction COs take the field in this sim, with an iconic pilot bonus), so running into him isn't a bug. But he's no longer the only FRR name you'll face. Thanks for flagging it.

Working as intended — declaring Brace commits that unit's activation for the round, so it can't be backed out of to fire afterward. Appreciate the clear write-up.

Fix applied 2026-07-16 (client MechLabSceneBootstrap section-panel layout): mech LEFT sections now render on screen-RIGHT (external player POV). Pending Unity recompile + playtest to confirm flip direction. Resolved 2026-07-17 — real fix was MechLabConfigureView.BOXPOS (Hub overlay), not the standalone scene. CO confirmed the flip in-client.

Good writeup — this was two issues, both fixed for 1.0. The root cause was the water bug from your other report: the Alacorns couldn't close across the river, so no shots were traded, and after ~12 quiet turns the stalemate damper resolved the drop — and on a PA a stalemate with no ground taken goes to the defender (they held), so you ate the loss. Two fixes: (1) water is now fordable, so units actually engage instead of getting stuck on opposite banks; and (2) the quiet-turn damper no longer applies when a human is at the controls — you now play to the full turn limit and decide for yourself whether to press on or withdraw, instead of the drop ending out from under you mid-maneuver. Your draw-them-into-DropShip-fire plan would get the turns it needed. Thanks — the play-by-play made both bugs clear.

Closing this one as obsolete rather than fixed. The free-text negotiation you ran into — the AI calling you by another Clan's Khan, then arguing about a different world — was part of the old conversational trial system. That whole path is gone in 1.0. Trials of Possession are now structured: you get the batchall, then accept, refuse or launch. The world comes straight off the trial record instead of being restated in generated prose, so the class of bug you hit can't happen. Ships with the 1.0 release.

Fixed for 1.0. Good catch, and it was exactly as you described — a crit that wrecked one weapon knocked out every weapon of that name on the 'Mech. The firing gate now counts INSTANCES rather than names: if you mount three Medium Lasers and lose one to a crit, the other two keep firing, and you're only locked out once all three are gone. Verified directly against that case. Ships with the 1.0 release.

Thanks for this — you're right that ATMs don't behave like ATMs today. They currently resolve as a single fixed profile: minimum range 4, brackets 5/10/15, with damage scaling by size (ATM 3 = 6, ATM 6 = 12, ATM 9 = 18, ATM 12 = 24). That is effectively the standard ammo type only. What makes an ATM an ATM is the three ammo types — HE, standard and ER — each with its own range brackets and damage, switched per shot. We don't have per-shot ammo-type selection in the engine, and adding it means new ammo handling, a firing-time selection UI, and an AI that knows which type to load. That's a feature, not a stats correction. So: no plans to implement at this time. Logging it as a known limitation rather than leaving it open — if we build ammo-type switching later, ATMs are the reason we'd do it.

Fixed for 1.0 — and you nailed the diagnosis. The rotor spinner was attached to EVERY part whose name looked like a rotor, propeller or blade. These models nest: a hub called "main_rotor" holds "blade_01", "blade_02" and so on, so each individual blade span on its own AND inherited the hub's spin. Compounded, that's the asterisk. It was picking the wrong axis too — a blade under the TAIL rotor has no "tail" in its own name, so it took the main rotor's axis and speed and turned across the wrong plane. Now one spinner per rotor assembly, with the tail axis read from the parent. Ships with the 1.0 release.

The crit-slot accounting was already correct under the hood (Clan Endo Steel / Ferro-Fibrous use 7 slots, not 14) — the '14' was a Mech Lab display label that ignored tech base. Fixed to read 7 for Clan 'Mechs; ships with the 1.0 client build. No change to how your 'Mechs actually build or fight.

Fixed for the 1.0 build — the Clan Laser AMS now correctly weighs 1 ton and takes 1 critical slot (it had been using the heavier Inner Sphere 1.5-ton / 2-slot value).

Fixed for 1.0. The Mech Lab's weapon list only offered what your faction could BUY, so Clan weapons an Inner Sphere unit had picked up at auction (or as salvage) were invisible — you owned them, you just couldn't see them to mount. The list now includes anything you actually hold, regardless of tech base. Verified with your exact case: Kell Hounds holding Clan ER PPCs bought at auction, and they now appear in the Lab. Ships with the 1.0 release.

Fixed for the 1.0 build — the Rifleman IIC's default variant now carries its correct stock loadout (four Large Pulse Lasers) instead of the -10 variant's autocannon build.

Good catch — you're right that the Flashman's model is broken (it renders incomplete / sunk into the terrain). Rather than patch the model, we're dropping the Flashman — both the model and the 'Mech — from the 1.0 build, so you won't run into it anymore. Thanks for the report.

Keeping this one open — it's a live investigation rather than something we're closing off. Withdrawn units staying on the map as untargetable ghosts is a real bug and we haven't found a reliable way to reproduce it yet, which is exactly why it isn't fixed. We'd rather leave it open and honest than close it on a guess. Realistically it won't make the 1.0 release. If you hit it again, anything you can tell us about what the unit was doing when it withdrew would help. Thanks for reporting this, and apologies for the delay in answering. To be clear, this is a real defect — withdrawn units staying on the map isn't intended, and a unit that's still standing is still an obstacle and a target. We're not fixing it in the current cycle, so we're closing the ticket rather than leaving it open with no work attached to it. If it's still happening after the next update, please do file it again with the battle it happened in — a fresh report with a live battle id is far more useful than an old ticket, and it'd get looked at properly.

Fixed for the 1.0 build — jump jets now use their correct weight by 'Mech tonnage (0.5t light/medium, 1t heavy, 2t assault; improved jets double that) instead of a flat 0.5t. Jumping heavy and assault 'Mechs had their armor re-balanced to stay legal.

Confirmed — a movement-cost bug. Water was charging 4 MP to wade (5 for deep), but your Supernova is a 3/5 'Mech, so it couldn't afford even one water hex — it was walled out of the river entirely (the AI's tanks use different movement, which is why they could cross). Fixed for the 1.0 build: water now costs the canon 2 MP to wade (3 deep), so a walk-3 assault can ford — one hex per turn, so a wide river is still a slow barrier, but a crossable one rather than a wall. Thanks for the report.

Good call — most of this is already in, so here's exactly where each one stands. IMPLEMENTED (ammo-based today): · Plasma Rifle — 10 shots/ton, 10 heat, 10 damage · Clan Plasma Cannon — 10 shots/ton, 7 heat, heat-only damage (no direct damage, which is correct for the Clan cannon) NOT IMPLEMENTED: · Heavy Flamer — still a pure energy weapon with no ammo bin So the niche you're describing exists for the two plasma weapons; the Heavy Flamer is the one that hasn't been converted. We're not taking that on before 1.0 — giving it an ammo bin changes its tonnage, crit slots and the loadouts of every variant carrying one, and that's a change we'd rather not make on the way out the door. Closing this as covered-in-part. If the Heavy Flamer conversion matters to you for a later release, open it fresh and we'll size it properly.

Great catch — your screenshot pinned it exactly. Line-of-sight was tracing a single hex path, so a shot that ran right along the edge of that building got blocked even when you had a clear angle past it on the other side. That's the "sight lines near buildings feel off" issue you flagged. It's fixed in the 1.0 update: grazing shots past a building now connect, while solid walls — and targets genuinely behind a building — still block as they should. Thanks for the detailed report and the screenshot.

Good catch — the "Next Page" button was getting suppressed in the Mech Market whenever a weight-class filter was active (it fell back to an old pagination path). Fixed for the 1.0 client update, so you'll be able to page through the full list again.

Fixed for 1.0. Streak LRMs and ER Pulse Lasers now resolve their full profile — range brackets, hardpoint and stats — so the to-hit figure has what it needs and displays. Checked Streak LRM 10/15 and ER Medium/Large Pulse Laser specifically. Ships with the 1.0 release.

Fixed for the 1.0 build — the Tiburon is now correctly a 35-ton light 'Mech (it had been mis-sized at 60 tons) with its proper canon variants.

Three things here, so taking them in turn. ER Large Laser minimum range — already correct. Every ER laser (and the ER PPC) carries minimum range 0. Nothing to change. Gauss Rifle range — currently minimum 2, brackets 7 / 15 / 22, which is the tabletop profile. We'd rather not move it away from canon, so leaving it. Repair costs — rebalanced. The per-damage-ton rate was cut by 5x during the economy pass, so a badly damaged medium runs a few million rather than tens of millions, against faction treasuries in the billions. If it still feels heavy once you're playing 1.0, open a fresh one with an example and we'll look at the curve rather than the rate. Ships with the 1.0 release.

Fixed for 1.0. Gauss minimum range now applies to vehicles exactly as it does to 'Mechs. The Gauss Rifle carries minimum range 2, and the firing paths enforce the out-of-minimum penalty with no vehicle exemption anywhere. So rushing inside a Gauss tank's minimum range is a live tactic again. Ships with the 1.0 release.

You were right — that one's badly broken. Its terrain runs from -90m up to +120m, so it renders as floating geometry with no ground under it. We ran a full elevation scan of the entire map library and pulled every board with that kind of extreme/negative terrain — 184 of them — from the rotation for the 1.0 build. Syreen Ice is on the list, so you won't see it in 1.0. Thanks for flagging it.

Fixed — thanks for the sharp eye. The Hanseatic League had been defined in the sim but was never actually populated (an empty faction shell), so it wasn't showing up in the Deep Periphery. It now holds its 29 canonical worlds with planetary garrisons, a trade fleet, its Council-of-Merchants command staff (incl. legendaries Reeve Halloran and Ilsa Brandt), and a handful of light-industry 'Mech lines. You should see it live now. The Umayyad Caliphate is a different case — it's intentionally dormant until its canonical Deep Periphery contact date (~3074), so it won't surface until the sim reaches that era. Working as designed there.

Fixed for the 1.0 build — the Shrike is now correctly a 95-ton assault 'Mech (it had been mis-sized at 50 tons) with its proper variants, jump jets, and targeting computer.

Fixed for the 1.0 build — Clan 'Mechs that mount a Targeting Computer in canon (the Summoner D/H, Warhawk, and 60-plus others) now have it equipped, and Clan Targeting Computers are available in the store.

Acknowledged — shelving the Osteon configs for a dedicated variant pass later. It's on the list; thanks for flagging.

Good catch, MechWarrior — and it went deeper than one 'Mech. Your Grand Dragon was minted from a stale chassis registry that was missing 49 designs; anything missing silently defaulted to 50 tons. That's why the roster said 50T while the lab weighed the actual 60-ton build at ~58T. Fixed fleet-wide as of this deploy: - The registry now resolves through the maintained catalog — the Grand Dragon is a proper 60-ton heavy again. - Every affected 'Mech in the sim (727 units, 40 designs — including all Kell Hounds Grand Dragons) has been re-certified to its true tonnage and weight class. - Armor allocations were re-verified at the corrected tonnage across all affected variants; your Grand Dragons carry max armor for 60T. Drop it in the lab and it should read 60T with the build fitting clean. Thanks for the report — this one fixed 48 other designs too. — Command

Confirmed — pulled 'A River Runs Through It' from the board rotation (the water/land hexes were swapped). You won't see it deploy again. Thanks for the report.

Fixed & live. Battle #328 (your raid on Arcadia) actually ended as a decisive victory — but the post-battle finalization silently failed: when an enemy's FREE reinforcement units (combat vehicles / elemental points) are destroyed, a validation step choked on them (they aren't persistent 'Mech records), which stranded the engagement so it wouldn't clear and the win didn't register. We manually finalized #328 — your victory and full raid spoils are now on the books — and deployed a permanent fix so battles finalize cleanly even when free units die. We also swept and cleared every other stuck engagement. Thanks for the sharp report. — Command

Done — every home Clan now has a shipyard on a world it holds at 3049, including Clan Nova Cat (Barcella). Live now and locked into the seed so it survives resets. — Command

Investigated on our end and the assignment path is healthy — Lucian is active with free 'Mechs available. He was most likely wounded/recovering at the time you tried, which temporarily blocks assignment. He should slot in now — please try again, and reopen this if it still won't let you.

Fixed & live — the after-action verdict now reads the actual battle participants (including coalition allies) instead of the planet's current owner, so a won raid no longer shows the DEFEAT screen. Follow-up: the 'won the fight but got DEFEAT / a stuck result' symptom had a second, deeper cause that surfaced today — post-battle finalization could strand whenever enemy free units (vehicles/elementals) were destroyed. That's now root-caused, permanently fixed, and deployed, and every affected battle has been repaired. This class of issue should be fully closed out now. — Command Fixed & live — the after-action verdict now reads the actual battle participants (including coalition allies) instead of the planet's current owner, so a won raid no longer shows the DEFEAT screen.

Done — corrected the mis-attributed factories (live + seeded): Jade Phoenix -> Jade Falcon (Ironhold), Osteon/Cephalus/Septicemia -> Coyote (Babylon), Sun Spider -> Goliath Scorpion (Roche), and added a Goliath Scorpion Warhawk line (Roche). The root cause was the coverage seeder spreading unclaimed Clan 'Mechs to arbitrary Clans; each is now explicitly claimed so it won't drift on reset. The NOVA CEWS system for the Osteon/Cephalus is noted as a separate follow-up (the chassis exist; the combined-EW system isn't modeled yet). — Command

Fixed & live — double heat sinks now count the full total (base + pod-mounted) for dissipation instead of just the base count, so energy-heavy Clan 'Mechs (Warhawk, Ebon Jaguar) run cooler as intended. Fixed & live — double heat sinks now count the full total (base + pod-mounted) for dissipation instead of just the base count, so energy-heavy Clan 'Mechs (Warhawk, Ebon Jaguar) run cooler as intended.

Fixed & live — Clan Omni default configs now use the correct Clan autocannons (UAC/LB-X) from the TROs instead of plain ACs. Fixed & live — Clan Omni default configs now use the correct Clan autocannons (UAC/LB-X) from the TROs instead of plain ACs.

Fixed & live — the missing-ammo issue applied to all ammo-fed weapons and is now corrected catalog-wide (LB-X, LRM, ATM, etc. carry their proper multi-ton loads). Fixed & live — the missing-ammo issue applied to all ammo-fed weapons and is now corrected catalog-wide (LB-X, LRM, ATM, etc. carry their proper multi-ton loads).

Done — factories stood up on the correct Clans (live now + locked into the seed): Bruin (Ghost Bear, Arcadia), Fire Moth (Ghost Bear, Arcadia), Cougar (Jade Falcon, Ironhold). Onager (Jade Falcon) and Dark Crow (Snow Raven) were already correct. One note on the "Jade Hawk": it does exist in canon, but it's a 3136-era (ilClan/Dark Age) Clan design — it isn't invented yet in our 1 Jan 3049 timeline, so it's not in the catalog and can't have a 3049 factory. We can add it if/when the era advances past its intro date. — Command

Fixed & live — Clan ER lasers, ER PPCs, SRMs and LRMs are back to their correct Clan weights and heat (e.g. Clan ER Large Laser 4t, Clan ER PPC 6t, Clan Gauss 12t), not the IS values. Fixed & live — Clan ER lasers, ER PPCs, SRMs and LRMs are back to their correct Clan weights and heat (e.g. Clan ER Large Laser 4t, Clan ER PPC 6t, Clan Gauss 12t), not the IS values.

Fixed & live — Crimson Langur B (and the other ATM 'Mechs) now carry their full ATM ammo (multiple tons for HE/STD/ER), not just the 1 ton bundled with the launcher. Fixed & live — Crimson Langur B (and the other ATM 'Mechs) now carry their full ATM ammo (multiple tons for HE/STD/ER), not just the 1 ton bundled with the launcher.

Fixed & live — per-variant extra ammo is restored across the catalog (1087 weapon slots now carry their proper multi-ton loads), so battles use the full ammo, not a single ton. Reopen if any specific 'Mech still shows only 1 ton in a fight. Fixed & live — per-variant extra ammo is restored across the catalog (1087 weapon slots now carry their proper multi-ton loads), so battles use the full ammo, not a single ton. Reopen if any specific 'Mech still shows only 1 ton in a fight.

Fixed & live — Clan LRMs no longer have a minimum range (they fire at all brackets, min=0). Deployed 2026-07-02. Fixed & live — Clan LRMs no longer have a minimum range (they fire at all brackets, min=0). Deployed 2026-07-02.

Done — final batch added, each on the owning Clan's world with starter 'Mechs: Stooping Hawk, Crimson Langur, and Battle Cobra for Blood Spirit (Atreus); Battle Cobra also for Steel Viper (Grant's Station); Dark Crow for Snow Raven (Glory); and Crimson Langur for Fire Mandrill (Bearclaw). All corrected in the seed so the whole set survives a reset. — Command

Done — Rabid Coyote added for Clan Coyote (Babylon) and the Shrike for Jade Falcon (Ironhold), both on their own worlds with starter 'Mechs. (Coyote Shrike isn't a separate chassis in the catalog — the Shrike is the one that exists, so that's what we built.) Seeded permanently. — Command

Done — factories stood up on each Clan's own world: Onager (Jade Falcon, Ironhold), Blood Kite (Blood Spirit, Atreus), Crossbow (Steel Viper, Grant's Station), and Savage Coyote (Clan Coyote, Babylon). Note "Blood Spirit" is the Clan itself — its Blood Kite line is the one added. Each line seeded with a few 'Mechs. Locked into the seed. — Command

Added — the Hellhound line is now running on Eden with starter 'Mechs, alongside the Supernova/Kingfisher/Vision Quest lines from T-0158. Baked into the seed as well. — Command

Fixed. Your factories were seeded on Mualang, which is Draconis Combine space at the 3049 start — they've been relocated to your own holdings (Eden/Roche). We've also stood up the missing lines you called out — Supernova, Kingfisher, and Vision Quest — on Eden, each with a few starter 'Mechs on hand. Corrected in the seed so it won't recur on reset. — Command

Closing — addressed by the v0.81 forward-3049 reseed: Clan homeworlds and holdings are now placed per canon. Reopen with a specific planet if any single holding still looks off.

Resolved as a duplicate of T-0140 — Grand Valley Bridge is removed from the battle pool.

Fixed in the v0.8 chassis overhaul — the Hunchback IIc now uses its correct model (the Centurion mis-bind is gone) in both the Mech Lab and combat. Patch to v0.8; reopen if you still see the wrong model.

Same fix as T-0139 — added jump jets now counted (Jenner C). 0.8 build, awaiting deployment. (triage 2026-06-26) Fixed in v0.8 — adding jump jets to chassis that don't ship with them now works and updates jump range correctly. Patch to v0.8; reopen if a specific chassis still won't take JJs.

Kingfisher present with per-variant loadout in the 0.8 catalog; LPL-in-CT crit layout to be confirmed in the per-mech verification pass. Awaiting deployment. (triage 2026-06-26) Addressed in the v0.8 chassis & variant overhaul — variant coverage was expanded and loadouts reconciled to the canonical catalog, so the STD-fallback gaps and off variants are corrected. Patch to v0.8; reopen if a specific variant still looks wrong.

Starmap planet labels no longer show the wrong name on zoom (commit 831e80f5). Awaiting deployment. (triage 2026-06-29) Fixed in v0.8 — starmap planet labels no longer show the wrong name when you zoom out and back in. Patch to v0.8.

Fixed & live — a world under an active assault now holds its factory output instead of feeding freshly-built 'Mechs into the contested garrison, so a locked-down world stops endlessly reinforcing the defense. Production resumes automatically once the siege lifts. Fixed & live — a world under an active assault now holds its factory output instead of feeding freshly-built 'Mechs into the contested garrison, so a locked-down world stops endlessly reinforcing the defense. Production resumes automatically once the siege lifts.

Battle engine now derives shot count from added ammo tonnage (ammo_count x ammo_per_ton) in the 0.8 build; the MechLab save-side write lands with the mech-lab rework. Awaiting deployment. (triage 2026-06-26) Fixed in v0.8 — Gauss/HAG (and Clan Gauss) ammo now loads and counts toward the weapon's shot count. Patch to v0.8.

A 'Mech committed to one PA is no longer counted as available in another (committed_to_attack_id guard, commit d50fc0fb). Awaiting deployment. (triage 2026-06-29) Fixed & live — a 'Mech committed to one PA is no longer counted as available in another (per-drop commitment lock). Fixed & live — a 'Mech committed to one PA is no longer counted as available in another (per-drop commitment lock).

Resolved — the Grand Valley Bridge board (both the 16x17 and the truncated 16x34 version) is excluded from the battle pool, so it will no longer appear in battles. Thanks for the report.

Battle engine now counts added jump jets toward jump range in the 0.8 build; MechLab save-side write lands with the mech-lab rework. Awaiting deployment. (triage 2026-06-26) Fixed in v0.8 — adding jump jets to chassis that don't ship with them now works and updates jump range correctly. Patch to v0.8; reopen if a specific chassis still won't take JJs.

Fixed + deployed (server, live now — no client update needed). Garrison mechs on worlds with no factory/shipyard can now be repaired via a black-market field bay (improvised work bay, premium cost ~2.5x, available anywhere your mech is parked) instead of being blocked. The repair estimate shows the field-repair cost up front so you see the premium before committing, and REPAIR ALL now includes factory-less mechs too. Works mid-PA. Thanks for flagging it.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Atlas II tonnage corrected to 100t in the rebuilt 0.8 catalog. Awaiting deployment (chassis-overhaul release + reset). (triage 2026-06-26) Fixed in v0.8 — the Mech Lab tonnage/weight calculation was corrected in the catalog overhaul (including the Atlas II 50-ton discrepancy). Patch to v0.8; reopen if a build's weight still reads wrong.

Fixed + shipped in client 0.71. Turrets were rendering as Locust because the published terrain asset-bundle was built before the turret prefabs were added to it, so they failed to load and fell back to a tonnage-based mech model. Rebuilt the bundle (all 5 Canon turret prefabs now included) and shipped it in 0.71; also fixed a sizing bug (turrets report 0 tonnage, so they were all using the smallest model — now sized by tier). Patch to 0.71 and they'll render as gun emplacements.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Marauder 6R added JJ + Clan Gauss ammo now honored by the battle engine (0.8 build); MechLab write-side lands with the mech-lab rework. Awaiting deployment. (triage 2026-06-26) Fixed in v0.8 — both issues on the Marauder 6R are resolved: Clan Gauss ammo loads/counts correctly and jump jets install properly. Patch to v0.8; reopen if either persists.

Fixed + deployed (server, live now). Turrets were being picked as the prebattle banter speaker because they use synthetic negative IDs and sorted ahead of real pilots. Turrets are now excluded — banter comes from an actual pilot.

Two-part fix, both live. (1) Render: turrets were ALL showing as Locust because the published terrain asset-bundle predated the turret prefabs (added to the build manifest after the bundle was last built), so the prefabs failed to load at runtime and fell back to a mech. Rebuilt the bundle (prefabs now packed in) + shipped in client 0.71. (2) Range: immobile turrets were being kited out of their weapon envelope, so they never fired. Turrets now get +6 hexes of effective reach (fixed/elevated fire-control) so they can engage a kiting enemy. Server change is live now; patch to client 0.71 for the visual.

Fixed and deployed server-side (no client update needed). Cause: on the killing blow that captures a world, the game cleans up the defender's emptied garrison, but when that garrison was still linked to a past battle record a database safeguard aborted the entire capture — which surfaced to you as the internal server error, repeating on every retry. Good news: your assault DID complete once the fix went live. Luthien has flipped to you (DC -> CnC), the campaign resolved as a win (7/7 stages). Nothing needed on your end. Thanks for the report + the follow-up — the detail (last Atlas, repeats after relog) pinned it down fast.

Fixed and deployed server-side (no client update needed). Cause: on the killing blow that captures a world, the game cleans up the defender's emptied garrison, but when that garrison was still linked to a past battle record a database safeguard aborted the entire capture — which surfaced to you as the internal server error, repeating on every retry. Good news: your assault DID complete once the fix went live. Luthien has flipped to you (DC -> CnC), the campaign resolved as a win (7/7 stages). Nothing needed on your end. Thanks for the report + the follow-up — the detail (last Atlas, repeats after relog) pinned it down fast.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Addressed in the v0.8 chassis & variant overhaul — variant coverage was expanded and loadouts reconciled to the canonical catalog, so the STD-fallback gaps and off variants are corrected. Patch to v0.8; reopen if a specific variant still looks wrong.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Superseded by the new variant system in the 0.8 chassis overhaul. OmniMech config-swapping is now handled by applying any catalog variant to a chassis in the MechLab (each variant carries its own loadout), and any owned 'Mech can be re-varianted regardless of which config its factory produced — so it's no longer locked to one config. Closing as addressed-differently; reopen if the new system misses something you needed. (triage 2026-06-29)

Fixed and deployed (2026-06-22). When you capture a world, the previous owners' records stay on file (expired), and a bug made the game pick one of those OLD owners as the defender of an incoming raid instead of you — so raids on Asgard and Pesht reported "doesn't involve your faction" and you couldn't open or defend them. The defender is now always resolved to the world's CURRENT owner, so raids on your worlds correctly involve your faction and you can defend them. This applies to every world you've taken. Thanks for catching it.

Diagnosed. Good news: server-side the fleet is NOT actually locked — when the battle on Port Arthur (attack #8794) was cleared, the commitment released, so the fleet is free to move. What you saw was the FLEET panel showing a stale "committed to attack #8794" lock: the panel only refreshes its lock state when you (re)open it or take an action, so when a battle you're committed to gets resolved in the background, an open panel keeps showing the old lock. Immediate workaround: close and reopen the fleet drawer (or relog) and the lock clears — the jumpships/warship can move. Proper fix (the panel now auto-refreshes its lock state while open, so a background resolution clears it on its own) is in the next client build. Thanks for the report. Live — the fleet panel now refreshes its commitment lock, so a fleet freed when its battle clears no longer shows a stale 'committed to attack' state (v0.81 client).

Fixed and deployed (2026-06-21). Territory disputes are defended by a "threat" garrison force, and the battle's combat medium wasn't locking in for that opponent type — so launching the hex-grid drop failed with "combat medium must be hex grid (current: nil)". It now locks correctly when you choose to play out a territory dispute against any computer/threat defender, so the drop starts normally. The dispute you hit (Asgaard) had already auto-resolved by the time this was looked at, so just start a fresh one to confirm — thanks for the clear report and log.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Fixed in v0.8 — the Mech Lab tonnage/weight calculation was corrected in the catalog overhaul (including the Atlas II 50-ton discrepancy). Patch to v0.8; reopen if a build's weight still reads wrong.

Assault on an undefended world now resolves as an attacker win with zero losses (PA walkover, commit 8a3a00bc). Awaiting deployment. (triage 2026-06-29) Fixed & live — assaulting an undefended world now resolves as an attacker win with zero losses and flips ownership. Fixed & live — assaulting an undefended world now resolves as an attacker win with zero losses and flips ownership.

Fixed in v0.8 — weapon/prop attachment was reworked to use each chassis's real hardpoint bones (Build B), replacing the old heuristics that caused floating launchers/artifacts. Patch to v0.8; reopen with a screenshot if a model still shows a floater.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Fixed in v0.8 — weapon/prop attachment was reworked to use each chassis's real hardpoint bones (Build B), replacing the old heuristics that caused floating launchers/artifacts. Patch to v0.8; reopen with a screenshot if a model still shows a floater.

Resolved — server-side the fleet/jumpship was never actually stuck (its mech fleets at Outer Volta are idle + free; multi-jumpship fleets and unattached reserve jumpships are normal). The 'stuck' was the same stale fleet-panel lock display as T-0123: an open panel kept showing an old lock after a background change. The drawer now auto-refreshes its lock state while open — ships v0.7. Close/reopen the drawer to clear it on the current build.

Dragon now 60t (loadout catalog). Verified fixed on prod 2026-06-21 (overnight sweep).

Further investigation required. The battle linked from the report (tactical battle 5671 / attack #6391, salvage_theft vs CGB) resolved end_reason=all_attackers_lost — all of the attacker's mechs were destroyed (atk_cas 4/4), so that result was legitimate, not a 2-vs-1. A scan of recent CNC losses showed the only 'lost with survivors' cases are PA drops repelled by turret defense (by design). Couldn't reproduce a victory-scoring bug. Need the SPECIFIC battle ID for the '2 mechs vs his 1' fight to dig further. Investigated: the linked battle (tactical 5671 / attack #6391 vs CGB) resolved end_reason=all_attackers_lost — all of your 'Mechs were destroyed (4/4 casualties), so the defeat was legitimate, not a 2-vs-1. Closing; reopen with a battle link if you hit a genuine survivor-count mismatch. (triage 2026-06-29)

Fixed in v0.8 — weapon/prop attachment was reworked to use each chassis's real hardpoint bones (Build B), replacing the old heuristics that caused floating launchers/artifacts. Patch to v0.8; reopen with a screenshot if a model still shows a floater.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Fixed in the v0.8 chassis overhaul — the Hunchback IIc now uses its correct model (the Centurion mis-bind is gone) in both the Mech Lab and combat. Patch to v0.8; reopen if you still see the wrong model.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Partial: the 'only have access to Prime' half is superseded by the new variant system (apply any catalog variant in the MechLab). The extra-LAMS model artifact on the Huntsman Prime is a separate model bug still tracked for the per-chassis verification pass. (triage 2026-06-29) Addressed in the v0.8 chassis & variant overhaul — variant coverage was expanded and loadouts reconciled to the canonical catalog, so the STD-fallback gaps and off variants are corrected. Patch to v0.8; reopen if a specific variant still looks wrong.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Addressed in v0.8 — engine handling was reworked with the catalog overhaul and the store/lab are tech-gated, so an IS chassis won't mount a Clan engine. Patch to v0.8; reopen if you can still do it.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Loadout variant-coverage gaps closed + the 'STD' production fallback removed by the rebuilt 0.8 catalog (0 empty loadouts now). Awaiting deployment. (triage 2026-06-26) Addressed in the v0.8 chassis & variant overhaul — variant coverage was expanded and loadouts reconciled to the canonical catalog, so the STD-fallback gaps and off variants are corrected. Patch to v0.8; reopen if a specific variant still looks wrong.

Fixed and live: a chassis naming mismatch in the loadout catalog meant Ebon Jaguar configs never resolved, so they spawned bare. Corrected at the source, and ALL your existing empty Ebon Jaguars have been backfilled with their proper armor/weapons/electronics and valid canon configs. Please check your hangar to verify.

Fixed + deployed + backfilled (2026-06-18): chassis names normalized to with-space canonical (Phoenix Hawk / Black Knight / Mad Dog / Ebon Jaguar) across all 5 seed files (reset-safe) + live backfill (Phoenix Hawk 3310, Black Knight 75, Mad Dog 546 mechs; 2 live PH factories) — 0 factories now produce stripped mechs. SEPARATE follow-up (not chassis-spelling): ~20 chassis|variant combos still lack a catalog loadout (Hatchetman HCT-5K, Catapult CPLT-K2K, Atlas AS7-D-DC, Stalker STK-5M, etc. + odd named/custom variants), and production over-uses the 'STD' fallback variant (see #99). Minor: Mad Dog has redundant last-wins dup keys in mech_loadouts.json to dedupe.

Got it — this wasn't your forces, it was the TARGET: that CJF world had no garrison to defend, so the battle couldn't start (an undefended target can't field a defending lance). I've resolved your stuck attack as the walkover victory it should've been — check your codex/AAR. Going forward, attacking an undefended world will auto-resolve as a victory instead of throwing that error. Thanks for the clear report!

Done — obsolete talent/tech-tree nodes have been pruned. Heads-up: the tree is also getting a broader overhaul for the 1.0 release, so expect further changes there.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Superseded by the new variant system in the 0.8 chassis overhaul. OmniMech config-swapping is now handled by applying any catalog variant to a chassis in the MechLab (each variant carries its own loadout), and any owned 'Mech can be re-varianted regardless of which config its factory produced — so it's no longer locked to one config. Closing as addressed-differently; reopen if the new system misses something you needed. (triage 2026-06-29)

Fixed and LIVE: factory production is now slowed by half across the board, AND your per-factory throttle is properly respected (it was being ignored before — that's why 25% still flooded you with mechs). Set your factories where you'd like and verify the new output. Thanks for flagging this!

REPORTED (CO 2026-06-17): mixed building meshes on one map — new solid structures alongside old-style buildings. Make the battle building renderer use the new mesh consistently for ALL building hexes. Likely the KayKit/board decoration mapping falling back to the legacy building prop for some hex tags. Check the board-to-mesh mapping in the client battle terrain builder. Closing — the battle building-mesh consistency is a visual-polish item we're not pursuing right now; the new solid mesh remains the target look going forward. Reopen if it ever affects gameplay (LoS/cover).

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Addressed in the v0.8 chassis & variant overhaul — variant coverage was expanded and loadouts reconciled to the canonical catalog, so the STD-fallback gaps and off variants are corrected. Patch to v0.8; reopen if a specific variant still looks wrong.

Clan Double Heat Sinks = 2 crit slots, IS = 3 (MechLab::Validator HS_SLOT_COST). Verified fixed on prod 2026-06-21 (overnight sweep).

Fixed in v0.8 — the store bug that returned an error on engines/weapons/consumables is resolved; engine purchases populate and buy cleanly now. Patch to v0.8.

Charger now 80t (loadout catalog). Verified fixed on prod 2026-06-21 (overnight sweep).

Resolved (addressed v0.7) — removed redundant win-probability recomputation on already-resolved battles; the post-battle AAR loads quicker.

Shipped in client v0.6 (2026-06-17): engine selector tech-gated to engines the mech can run — no more pick-then-save-fail.

You can now view, reply to, and reopen your submitted tickets (ticketing v2, commit d50fc0fb — replying reopens a resolved/closed ticket). Awaiting deployment. (triage 2026-06-29) Live — you can now view, reply to, and reopen your submitted tickets from 'Your Reports' (replying reopens a resolved/closed ticket). Shipped in the v0.81 client + server.

Win-% now computed from committed deck vs committed defenders (not whole garrison). Shipped v0.7 (live on prod). (triage 2026-06-26)

Fixed (server, live 2026-06-17): contract board now side-gated. Clan factions only see/accept Clan-posted contracts; IS-posted go to IS merc + pirate units only. Threat-war (SLDF) contracts cross the line by design and are badged. Client badge ships with the next build.

Fixed: Arrow IV crit-slot cost reduced to fit a single mech location (was 15 IS / 12 Clan, larger than any 12-slot location). Now IS Arrow IV + Cluster = 10 slots, Clan = 8 (tonnage unchanged). Mounts cleanly on any location with a missile hardpoint. Ships with the 2026-06-17 server deploy.

Shipped in client v0.6 (2026-06-17): MAX ALL fills the true fractional tonnage budget with per-armor-type points-per-ton (Ferro/Hardened). Server decimal-armor model already live.

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Addressed in the v0.8 chassis & variant overhaul — variant coverage was expanded and loadouts reconciled to the canonical catalog, so the STD-fallback gaps and off variants are corrected. Patch to v0.8; reopen if a specific variant still looks wrong.

Shipped in client v0.6 (2026-06-17): end-of-battle detail scroll content pivot fixed (was 0.5,1 -> 0,1).

Acknowledged — tracked + queued for the 0.8 chassis overhaul. We're rebuilding the chassis/variant system and going through every mech one at a time, verifying the model + loadout/variants against canon (Sarna). This will be confirmed and fixed when its chassis is processed. Thanks for the report. Fixed in the v0.8 chassis overhaul — the Hunchback IIc now uses its correct model (the Centurion mis-bind is gone) in both the Mech Lab and combat. Patch to v0.8; reopen if you still see the wrong model.

TD empty-deck walkover fixed + deployed (AI auto-commits the defender garrison for territory disputes, then plays it out). Monitoring for any non-TD defensive empty-deck cases. Fixed & live — defensive battles no longer commit empty drop decks; the defender garrison auto-commits and plays out. Reopen if you see a non-TD defensive empty-deck case. Fixed & live — defensive battles no longer commit empty drop decks; the defender garrison auto-commits and plays out. Reopen if you see a non-TD defensive empty-deck case.

Server `face` action exists; the client in-hex rotate control is not yet built — targeting a later build. Resolved — in-hex turning (◄TURN / TURN► + Q/E) shipped. Fix lands in the v0.7 client patch.

Shipped in client v0.6 (2026-06-17): all 12 EBJ configs + 6 new Clan weapons (Rotary AC, LRT, Streak LRM, Thunderbolt, Angel ECM, CASE II, UMU) with full bespoke mechanics. Server + client live.

Shipped in client v0.6 (2026-06-17): failed/cancelled Discord login redirects back to the client with an error instead of crashing. (Server fix was already live; client now matches.)

FOUND 2026-06-16c while fixing #72: ~500 Mech rows have tonnage != their variant's canonical mass (e.g. Phoenix Hawk/Vindicator stored 50t should be 45t; Corsair 85->95) — #32 contract-reward-spawner straggler family. Surfaces as wrong walk/run on those mechs. FIX READY (api/tmp/fix_tonnage_corruption.rb, APPLY=true): sets tonnage to the canonical loadout mass + weight_class. ~500 mechs; safe (canonical data, #32 precedent). Needs CO greenlight. | 2026-06-16c: APPLIED on prod (CO greenlit) — 350 mechs corrected to canonical mass + weight_class. Re-scan: 0 remaining.

| 2026-06-16c: Server data is CORRECT everywhere — Clan SRM 2/4/6 = 0.5/1.0/1.5t in equipment_catalog, WeaponStatsCatalog, WeaponSlotCatalog AND the /weapons FetchWeapons payload (verified on prod); client DTO is float, palette formats :0.#. Fixed by today's IS/Clan weapon separation. Player likely saw a STALE session — WeaponRegistry fetches the catalog ONCE per session, so anyone logged in before the deploy keeps old weights until relog. RECOMMEND: re-fetch weapons on mech-lab open (small client change, next build). NOT marking resolved until confirmed in a fresh session. | 2026-06-16c CORRECTION + FIX: not a stale session — real CLIENT bug, exactly as CO suspected (and it surfaced AFTER the Clan split). StoreItemDto.tonnage was `int`, so the store truncated the server's 0.5 (Clan SRM 2) to 0 at JSON parse. The split added 'Clan SRM 2' (0.5t) as a distinct store row a Clan faction (CNC) browses, exposing it. FIX: StoreItemDto.tonnage int->float + MarketPanel {:0.#}t (ships next build); also server store.rb legacy-IS path .to_i->.to_f.round(1) (IS MG/small-laser/flamer 0.5t were truncating too — deployed). Verified store now serves Clan SRM 2 = 0.5 / IS MG = 0.5.

| 2026-06-16c: FIXED + deployed. Card/list walk MP now derived from the engine (rating/tonnage), matching the customization menu — was a stale stored base value. Verified on the reporter's Marauder #103655 (75t, engine 380): now derives 5 (was 4). Editor also stores the derived value on commit. (Separate: ~500 wrong-tonnage mechs filed.)

OBSERVED (CO): opening a battle's After-Action replay, mechs appear in the CENTER of the map on the first frame, then snap to their actual starting hexes. Initial replay frame should place each unit at its true start hex (looks like the first state-frame positions aren't applied before the first render / a default center spawn is used). Investigate the replay initializer / first-frame hex placement in the AAR playback path. Replay spawn-then-snap fixed. Shipped v0.7 (live on prod). (triage 2026-06-26)

OBSERVED (CO): CNC has captured several DC worlds and DC mounts no counter-offensive against CNC territory. Need to verify how large units / factions react to losing planets and ensure they actually retaliate by attacking the aggressor's planets after losing territory to them. INVESTIGATE: does AiFactionTurn track recent territory losses + the faction that took them? Is there a retaliation/grudge trigger analogous to the pirate-hunt mechanic (raided >=2x -> hunt)? Likely add: on planet loss, record aggressor; AI prioritizes a counter-attack on the aggressor's nearest planet when it has an idle combat fleet in range. Scope to capable factions (fleets + decks available). NEXT SESSION work item. | 2026-06-16c: FIXED + deployed. AiFactionTurn#maybe_retaliate_for_lost_planet (reactive phase, beside the pirate hunt): a faction that lost a world to an aggressor in the last 8 turns mounts a planetary_assault to RETAKE it (declare on-site or dispatch via PendingThreatPursuer). Skips allies; ComStar bulletin per aggressor. Sim-time lookback (valid_until is sim-time). Verified on dev (CGB retook Casere vs CSJ).

ROOT CAUSE (diagnosed via WeaponAttach DIAG): bundle chrprfmech_kitfoxbase-001 ships prefab chrPrfMech_cicadaBase-001 re-skinned with the kitfox mesh + ONLY cicada weapon props. PrefabChassisHint -> 'cicada', so cicada props attach; arm props align but the cicada center-torso missile rack floats in front of the kitfox nose (wrong hardpoint for this mesh). No kitfox props exist in the bundle. Stormcrow = same pattern via cataphract. Likely affects several RogueTech re-skins. FIX OPTIONS: (a) editor hand-position the offending torso prop per affected bundle; (b) supply real kitfox/stormcrow prop sets; (c) interim: bundle-gated suppression of torso props that land far off the torso bone. Broad heuristics regress working rigs (reverted). NOTE: a verbose DIAG line was left in MechWeaponAttacher for auditing. ITEM ID (CO 2026-06-16): the floating prop is chrPrfWeap_cicada_righttorso_srm4_mh1 (Cicada right-torso SRM-4 rack, used for the Streak SRM 4); secondary torso prop chrPrfWeap_cicada_centertorso_flamer_eh1 (LB-5X). CONFIRMED via WeaponAttach DIAG: root='chrPrfMech_cicadaBase-001(Clone)', mechPrefabsInBundle=[chrPrfMech_cicadaBase-001], propChassis=[cicada] — i.e. a KITFOX mesh re-skinned onto the cicada prefab, wearing cicada props. THE FIX (CO direction): there is NO per-chassis override map today — placement is purely the prop name's section + the prop's own authored chrMdlWeap offset (heuristic 'uncollapse'). MechMountExtractor.cs was only PHASE-1 DUMP; the planned Phase-2 'bake' override map was never wired. Right fix = wire that override map: a (chassis|section|hpId) -> position/rotation table the attacher consults BEFORE the heuristic, populated first for chrPrfWeap_cicada_righttorso_srm4_mh1 on the kitfox mesh (capture correct transform in-editor, or extend MechMountExtractor to dump cicada/kitfox). Broad heuristics regress working rigs (reverted). NEXT SESSION owns this. TARGET PLACEMENT (CO 2026-06-16, per Sarna ref): the floating SRM rack belongs on the KitFox's RIGHT ARM (shoulder-mounted launcher). Next session: reposition chrPrfWeap_cicada_righttorso_srm4_mh1 onto the kitfox right arm. CRITICAL CONSTRAINT: the override MUST be KITFOX-ONLY — NOT a global change. The override map keys on (bundle/chassis | section | hpId) precisely so each broken re-skin is fixed SURGICALLY and in isolation; do not touch the shared heuristic that the working rigs depend on. | 2026-06-16c: FIXED in code — MechWeaponAttacher per-(bundle,section) re-skin torso re-route (commit 1fb7b125). KitFox + Stormcrow verified in-editor. Ships in tonight's build.

| 2026-06-16c: FIXED + deployed. Quickdraw is 60t heavy (chassis catalog was already correct; a stray Mech row was spawned at 50t/medium — live-repaired to 60t heavy). No client build needed.

| 2026-06-16c TRIAGE (CO): split. (1) Nova Prime 12 ERML spread over the mech instead of arms = same RogueTech re-skin float family as #69/#19/#22 — fix via ReskinTorsoReroute. (2) Ebon Jaguar Prime loadout is wrong in our data (we just added EJ via #48); canon: LA LB-X 5 (+2t Cluster/Slug), LT LRM-10 (+2t), RT SRM-2 (+1t, +2t Gauss ammo), RA Gauss Rifle — DATA fix. Reporter will file more loadout issues; treat as ongoing loadout-accuracy. | 2026-06-16c: BOTH reported loadout issues FIXED + deployed. (1) Nova Prime 12 ER ML now all-arms (see #19/#22). (2) Ebon Jaguar Prime corrected to canon (Sarna): Gauss/LB-5X/LRM-10/SRM-2/ER-ML; existing EBJ-Primes re-equipped to the corrected canon (9). Seed-side (mech_loadouts.json), survives reset. Reporter said they'll file more loadout issues as new tickets.

REPORTED (tester, 2026-06-16) — PURELY VISUAL. Gameplay is correct: the engine already resolves a real hit component per shot (HitLocationResolver returns a `section`: center_torso / left_arm / head / left_leg ...). The CLIENT just lands every impact VFX at the target's transform origin (root ~= ground/pelvis), so it reads as 'aimed at the crotch'. FIX (client): map each shot's resolved section to the matching body bone/position on the target model and play the impact there — accurate, per-component visuals. Client = BattleV2Bootstrap weapon VFX + MechActor; section data already arrives in the action result hits[]. Weapon-impact VFX now land on the struck component. Shipped v0.7 (live on prod). (triage 2026-06-26)

FOLLOW-UP (CO 2026-06-16): headshots appear to happen more often in allied (coalition) battles — may be coincidence. To investigate: (1) check whether compounded unit bonuses (cohesion / keshik clustering / faction persona / pilot affinity) stack in allied battles in a way that raises to-hit or called-shot/head-hit odds vs solo battles; (2) ADD A HEADSHOT-RATE TRACKER (head hits / total hits, split solo vs allied) so we have data before deciding to tune. Engine: HitLocationResolver (location table + called-shot), Tactical::Engine to-hit mods. Closing — head-shot frequency was rebalanced and validated live on prod (see the head-shot rebalance). The separate allied-battle bonus-stacking tracker isn't being pursued as its own item.

| 2026-06-16c: FIXED + deployed. LB-X autocannons have no minimum range (canon). LB 2-X/5-X (IS + Clan) were inheriting AC/2 (4) / AC/5 (3) min range via fallback — set to 0 in equipment_catalog.json. LB 10-X/20-X were already 0. Verified stats + mech-lab both read 0.

Fixed in v0.8 — weapon/prop attachment was reworked to use each chassis's real hardpoint bones (Build B), replacing the old heuristics that caused floating launchers/artifacts. Patch to v0.8; reopen with a screenshot if a model still shows a floater.

REPORTED (CO 2026-06-16): the post-battle VICTORY/AAR modal has a fixed height, so on longer results the bottom 'RETURN TO HUB' button sits on top of the last line (the 'Field salvage … available in Assets -> Salvage' text), hiding it. FIX: size the modal to its content (or scroll the body / pin the button below the content) so the button never overlaps text. Client = AfterActionReportModal. | 2026-06-16c: FIXED in code. End-of-battle panel detail block is now a masked, scrollable ScrollRect — long casualty/salvage lists scroll instead of overflowing onto the RETURN TO HUB button. Ships in tonight's build.

Closing — a stock-loadout preview in the store is folded into the broader loadout-preview backlog (see the friendly/enemy loadout-hover work). Not an active fix.

REPORTED (CO 2026-06-16): on maps with a central dip (low elevation or deep water), the top of the floating-island underside mesh was visible through the dipped hexes. FIXED (staged, next client build): BattleV2Bootstrap now tracks the LOWEST hex floor Y placed on the board (incl. negative elevation + sunken water) and hangs the island underbelly's top (rimDepth) just below it with 2.5u clearance, computed dynamically per map. Flat maps (floor >= -1.8u) are unchanged. | 2026-06-16c: Fix staged (BattleV2Bootstrap hangs the island underbelly below the lowest hex). Ships in tonight's build.

REPORTED (CO 2026-06-16): in a tactical battle, tapping the new SELECT-ALL weapons toggle to check every ready weapon, then pressing SPACE (the FIRE key) skips/ends the player's turn instead of firing the alpha strike. Expected: SPACE fires the full selected volley. To investigate (client): SELECT-ALL likely toggles the weapon checkboxes without arming the fire action, so the SPACE handler falls through to the end-turn/skip path. Check the battle input handler's SPACE binding vs. the SELECT-ALL state, and whether a target/confirm is required. SELECT-ALL + SPACE now fires weapons. Shipped v0.7 (live on prod). (triage 2026-06-26)

| 2026-06-16c DESIGN (CO): NO manual repair. Damaged factories/shipyards auto-recover over time; SURFACE the countdown only. Operations production view: a damaged factory shows status 'Damaged' + 'X weeks (Y hours real time) until fully functional'. Same for shipyards. BUILD: (server) ensure a recovery ETA exists + auto-restore at it (no recovery tick today); (client) show status + dual-time ETA. Bucket: MEDIUM. | 2026-06-16c: FIXED + deployed. Damaged factories/shipyards now AUTO-RECOVER at recovery_eta (NEW IndustryRecoveryCompleter hourly + lazy-restore on next build) — previously they stayed broken forever. Operations now shows 'Damaged · X weeks (Y hours real) until fully functional' (server-computed; real = sim/time_scale). No manual repair, per design. Cleared 6 stuck factories this sweep.

DONE (2026-06-16): Clan Nova Cat had no home 'Mech factories. Added their signature touman on the capital Mualang — Huntsman, Shadow Cat, Warhawk, Mist Lynx, Adder (light through assault). Seeded into db/seeds.rb so it survives a reset. Note: Ebon Jaguar / Nova Cat aren't in the chassis catalog yet (no model), so they're held for a later add.

| 2026-06-16: Investigated. Server-side the AI advances + fights normally on '16x17 Moorlands 6' (reproduced: all mechs leave spawn, attackers move 12-16 hexes toward the enemy, battle resolves ~turn 4). The board is terrain-clean — no impassable hexes or buildings; the water is a band along the right edge, not a 'round' feature. So the 'AI frozen in the upper-left corner' is the client move-reconciliation desync (see T-0042) under the lag you noted — the AI moved, the client just didn't render it. The 'round construct' has no gameplay terrain behind it (likely a cosmetic forest-grove/prop render). Both should clear with the next client build; if the AI still looks frozen or the round object persists after that, a screenshot + battle ID will let us dig in. Resolved — fixed by raising the playable map above the island/water band; AI no longer reads as stuck in the corner. Ships v0.7.

ROOT CAUSE (client): the per-poll reconciliation only walks an actor one move at a time. When a single poll captured several enemy moves (fast/offline-AI turns), the actor animated move #1 and SILENTLY DROPPED the newer server positions (MoveTo/MoveAlong bail while IsMoving, and the hard-snap fallback required !IsMoving) -> mech appears to 'walk in place' then jumps many hexes later. Firing on the stale rendered hex resolved on the real occupant (an ally). FIX (staged, next client build): MechActor exposes MoveTarget + StopMovement; reconciliation interrupts + hard-snaps any actor mid-walk toward a now-stale hex, bounding visual desync to one poll. Server was always correct (moves are in the turn log). | 2026-06-16c: Client reconciliation fix staged (smooth move-replay; no mid-walk snap to a stale hex). Ships in tonight's build.

| 2026-06-16: Fixed — full IS/Clan weapon separation deployed 2026-06-16. Clan weapons now use their correct Clan weights (Clan ER PPC 6t, Flamer 0.5t, ER Large 4t, LRMs ~half, MGs 0.25t, etc.) in the store, Mech Lab, and combat. Store now gates by tech base.

| 2026-06-16: Server deployed. Apply a build to multiple same-chassis mechs (or one) with a buy-missing-parts flow: a preview returns the missing-parts list + total store cost, you accept, and it buys the parts then applies to every selected mech. (Also fixed a latent bug where saved templates 500'd.) The multi-select UI + accept/cancel cost pop-up ship with the next client build.

| 2026-06-16: Fixed + deployed. Assigning a non-active pilot (the 4 callsigns each had a BONDSMAN variant — bondsmen can't pilot until they earn warrior status) returned an unhandled 500; it now returns a clean error. The assign picker also gains an 'assignable' flag so bondsmen/wounded/on-quest pilots are grayed out (ships next client build).

| 2026-06-16b: Likely a client-side 'ghost image' from the move-reconciliation desync (see T-0042) under the lag you noted — the server resolves victory only when a side has no live mechs, so the second Atlas was probably a stale render. The reconciliation fix is staged for the next client build. If a battle still ends in victory with a genuinely live enemy after that build, please note the battle/ID so we can pull the turn log. Resolved — destroyed mechs are now rendered distinctly, so a dead unit no longer reads as a live 'ghost' on the field. Ships v0.7.

| 2026-06-16b: Resolved by deployed heat fixes: shutdown is now evaluated on NET heat after heat-sink dissipation (not gross mid-fire), and double heat sinks dissipate at full rate. TimberWolf TBR-D (15 double sinks = 30 dissipation) walking + firing both ER PPCs = 31 gross -> net 1, no shutdown. Please re-test.

Phoenix Hawk read 50t (45t correct) and some Wolverines 50t (55t correct). Fixed 153 affected 'Mechs live; root cause (contract-reward spawner hardcoded 50t/medium) corrected to use the canonical chassis registry.

Likely seen before today's fix. The mixed missile+direct volley fix is deployed — a NARC should now fire alongside your other weapons in one alpha. Please try again and let us know if it persists. | 2026-06-16: NARC reworked 2026-06-16 — it now fires as part of an alpha volley and acts as a missile beacon/magnet rather than blocking other weapons (on top of the earlier mixed missile+direct volley fix). Please confirm it fires alongside your other weapons now.

Plain SRMs already fire unguided (no sensor lock) — only Streak SRMs lock-on, which is canon. If a standard SRM required a lock, please note the 'Mech/weapon so we can repro. | 2026-06-16: Confirmed working as intended — plain SRM 2/4/6 (IS and Clan) fire UNGUIDED (no sensor lock required); only Streak SRMs lock-on, which is canon. Verified post-deploy. If a STANDARD SRM ever demands a lock, note the 'Mech/weapon and we'll repro.

The Clan-tech overlay shipped 2026-06-14 removes the minimum range on Clan autocannons/LRMs and corrects Clan weapon ranges in both the Mech Lab and combat. Please confirm the specific weapon reads right now. | 2026-06-16: Fixed by the tech separation — Clan LRMs and the Clan UAC/5 now have NO minimum range; the Clan UAC/2 keeps min range 2 and Gauss/HAG/artillery keep theirs (per TechManual). Please confirm the specific weapon now reads right.

Found it: jumping was being charged terrain + elevation movement cost, so a jump onto higher/rough ground could exceed the jump budget. Fixed — jumping now costs 1 jump-MP per hex and flies over terrain/elevation. Ships in tonight's release. | Shipped in the 2026-06-15 client build (live).

Same cause as the hired-pilot fix: newly hired pilots weren't available to assign until relog. Fixed — they now appear in the assign picker right away.

Brief gateway blips line up with server deploys (the API restarts for a few seconds). We're batching deploys to off-hours to avoid interrupting play.

Same cause as the sphere-wide heat fix: double heat sinks were dissipating at half rate. Clan 'Mechs (incl. Nova/Adder) now cool correctly. Live.

Confirmed cause: weapon mount locations are correct in our data + the server maps them right; the battle weapons panel only falls back to a name heuristic (lasers -> torso) when a 'Mech's battle state was built from a loadout without per-weapon locations. Cosmetic only — doesn't affect firing or hit locations. Scheduled with a combat-data pass. | 2026-06-16c: FIXED + deployed. Nova Prime canon loadout corrected to 6 ER ML per ARM (was split 3+3 arms / 2+2+2 torsos) — derives arms 6 energy HP / torsos 0, lasers now all on the arms with no torso float. 0 customized Novas reset to canon.

| 2026-06-16c: FIXED + deployed (same fix as #22). Nova Prime's 12 ER ML are now all arm-mounted, so no stray torso/chest barrels. Verified on dev (paper-doll + 3D), CO-approved.

| 2026-06-16c: Dupe of #69 — same RogueTech re-skin torso float (KitFox). Fixed by the re-skin re-route; ships in tonight's build.

Fixed: hire now refreshes the player's roster (heartbeat self-heal + instant local insert next build). No relog needed.

Fixed — ships in tonight's client update. | Shipped in the 2026-06-15 client build (live).

Fixed — ships in tonight's client update. | Shipped in the 2026-06-15 client build (live).

Clan Flamers, Ultra ACs, ER lasers and LRMs now use proper Clan-tech stats.

Double heat sinks were dissipating at half their rate — now correct.

Stuck fights now resolve on schedule.

Fixed — ships in tonight's client update. | Shipped in the 2026-06-15 client build (live).

Defense floor now also applies to the AI's offensive muster path (ad-hoc strike forces) — each world keeps a minimum garrison. Staged for the next release.

Parts and raw-materials purchases go through cleanly.

Open a coalition and budget allies in directly.

Fixed a combat desync.

Your committed lance now deploys with them.

Warnings are now throttled.

Fixed — ships in tonight's client update. | Shipped in the 2026-06-15 client build (live).

Fixed — ships in tonight's client update. | Shipped in the 2026-06-15 client build (live).

Fixed — tooltips now follow the cursor correctly at any resolution. Ships in tonight's client update. | Shipped in the 2026-06-15 client build (live).

Confirmed, reproduced and fixed — thanks, this was a real bug and a well-spotted one. What was happening: a custom variant is stored against its base variant's name, and the only thing that tells it apart from the stock version is a template reference. That reference was being thrown away the moment you clicked — the list was never locked, your pick simply had nowhere to be recorded, so what got saved was identical to picking the stock variant. Hence "listed but can't be selected". It was dropped in four places between the click and the battlefield, including two separate spots that build your defending 'Mechs. All four are fixed, and custom variants now drop with the loadout you built. While fixing it we found a second problem in the same screen you would have hit next: every variant in that picker was showing the same BV — the stock chassis value — so a heavily rebuilt custom was quoting you the wrong number in a lobby where you are spending a BV budget. That is now calculated per variant. On your question: yes, 'Mechs fielded on the defensive do count toward chassis mastery, with one condition worth knowing. It only credits when a human actually played the battle. If a defence gets auto-resolved or simulated rather than fought, nothing is credited. So if you have been defending and letting them resolve, that would explain a mastery total that looks stuck. Both fixes come with the next client release. Leaving this open until it is in your hands.

Reproduced and fixed — thanks for reporting it. The warship list was set to rubber-band at its edges rather than simply stop, so any time it tried to scroll past what it currently believed its own length to be, it sprang back. That list is rebuilt every time you change a selection and its height is recalculated a moment later, which is what gave you the bounce instead of a normal stop. There are 49 warship classes, so the grid runs thirteen rows deep — you were getting the first two. Nothing was wrong with the ships themselves or with what you're allowed to pick. It was purely the scrolling. The fix is in and will come with the next client release. Worth knowing we found the same setting on a number of other lists in the game, so if you've hit this anywhere else — the market, mech pickers, anything with a long list — that's the same cause and we're going through them. Leaving this open until it's in your hands and you've had a chance to confirm.

Tracked this down — and your instinct that something was consistently one hex short was right, it just wasn't the movement. Those numbers on the movement buttons are MP REMAINING THIS TURN, not the 'Mech's profile. They show max minus what you've already spent, and they subtract that same spent MP from walk, run and jump alike. So a 'Mech that has already moved one hex reads one lower on all three — every turn, on every machine, which is why it looked systemic. Your Executioner is the clearest case: profile 4/6/4, showing 3/5/3, which is exactly one MP spent. We checked the actual battle data against the catalog and the movement itself is correct — an Executioner is 4/6/4 in both. Incidentally, the jump figure is what proved it. Heat does cut movement, but by the rules it only affects ground movement — jumping ignores it. Since your jump was dropping too, heat couldn't explain it, and that pointed at the display. The fix: those badges now read "3/4 MP" instead of "3 MP", so it's clear you're looking at what's left of a budget rather than the 'Mech's stats. It'll be in the next client update. Thanks for reporting it — the detail about reading the movement buttons is what made it findable. Correction to what we told you earlier — and an apology. We said your movement numbers were fine and only the display was confusing. That was wrong for your 'Mechs, and you were right that something was actually slower. What we missed the first time: we checked stock variants, and almost everything you field is a custom build. The MechLab was never saving walk and jump into a customised loadout, so every custom 'Mech was stored with both at zero. In battle that fell through to a fallback that guesses movement from TONNAGE and ignores your engine entirely — and for jump it meant no jump at all. Your Crimson Langur is the clearest case. Built to walk 7 and jump 5; it was fighting at walk 5 with no jump. You field 169 of them. Your Summoner H+ was 5/5 in the lab and 4/0 on the field. Fixed, and already live: - The lab now saves walk and jump with the build, so what you see when you save is what drops. - We repaired every affected 'Mech already in the game — 1,247 needed their walk restored, 730 their jump. Yours are corrected; no need to rebuild anything. - Your Hellfire Brimstone had a genuine engine upgrade (240 to 300) that the battle had been ignoring. It now moves at the speed you paid for. The movement buttons also now read "3/4 MP" instead of "3 MP" so it's clear they're showing what's left this turn rather than the 'Mech's profile — that part of the earlier answer still stands, it just wasn't your problem. Reopening this rather than closing it: please check a drop and confirm your machines move the way the lab says. Thanks for pushing on it — the detail in your report is what made it findable, and we got there slower than we should have. Fixed and live. Your three now read the way the lab does: Gargoyle — 5/8 Linebacker — 6/9 Summoner — 5/8/5 Nothing to rebuild. They corrected themselves the moment the fix shipped — please check a drop when you get a chance and confirm. What was actually wrong, and it was not what we fixed last week. That fix was for custom builds saving their walk and jump as zero, and we repaired those. Yours had a different fault: no speed recorded at all. Buying a store upgrade — BAP, ECM or LAMS — rewrites a 'Mech's loadout, and the rewritten version carried weapons, armour and engine but no speed profile. Battle then fell through to a fallback that guesses movement from TONNAGE and ignores the engine entirely. That is all 3/5, 4/6 and 4/6 ever were — weight brackets. And because last week's repair went looking for speeds recorded as zero, a 'Mech with no speed recorded at all went straight past it, while the store kept producing more. Battle now reads the engine — rating divided by tonnage, the same sum the lab does — and only falls back to weight if there is no engine to read. That also means an engine you paid to upgrade is honoured rather than reset to the stock figure. It was bigger than the three you found: 299 'Mechs across eight chassis. Besides yours — Battle Cobra (80 of them), Balar (40), Stag (26), Ebon Jaguar (12), and one Arctic Cheetah. All corrected. You were right that jump was fine. Your Summoner's 5 was correct the whole time, so we left jump alone rather than touch something that was working. We have also added a standing check that compares every 'Mech's lab speed against the speed battle actually uses. If this class of fault comes back, it now fails on our side instead of yours. Twice now we have told you this was fixed when it was not. What made it findable both times was the detail you keep giving us — exact chassis, exact numbers, before and after. Thank you for staying on it.

Deferring this one to the backlog. The Shadow Hawk IIc-1's loadout wants Improved Heavy Medium Lasers, which aren't in the game. We're not adding new weapons before 1.0 — the line has to be drawn somewhere to get the release out — so rather than approximate the loadout with something else and have it be quietly wrong, we're leaving it as is and logging the weapon. Backlogged rather than declined: if Improved Heavy Medium Lasers go in for a later release, this variant gets rebuilt properly at the same time.

Checked both halves of this. The Alphards are correctly owned in the current data — Alphard (FWL) sits with the League and Alphard (MH) with the Hegemony — and there are no duplicate world names anywhere, so the naming-similarity theory doesn't apply. If your map still shows otherwise, tell us and we'll look again at the display rather than the ownership. On Illyria you're right that Jade Falcon holds it. The wrinkle is that the Palatinate has no capital world recorded at all, so nothing in the data ever marked Illyria as their seat — your inference from the name is reasonable, but there's no capital flag for anyone to have taken. We're not picking this up now. It may get revisited before the next reset, when world ownership and faction seats are being set up again anyway. Closing it on that basis.