DEVELOPMENT PLAN #87 — Where Broken Gear Gets Fixed: Field Repairs and Rear Workshops

Contributed by: Takeshi Miyaoka on Saturday, November 07 2026

Last modified on Saturday, November 07 2026

This is a development plan: it describes something we would like to build next. None of it is implemented yet, and the details are still under consideration and may change.

This morning's post (#86) added "Workshops in use" and "Deployed / required" to the Production window. Right now the workshops only build new equipment. So where does gear damaged in battle get fixed? Tonight's plan splits a damaged item into the part that can be repaired in the field and the part only a rear workshop can restore, and lets workshops share their work between new builds and repairs. It builds on the existing improvement item BTL-013, and we have added this plan to that ticket.

The current Production window, captured from a development debug build with a verification setup. Workshop capacity (1.2 / 2) is used only for new builds; there are no repair orders yet.

Where things stand: damage stays, but only some gear can be fixed

Damage that equipment takes in battle now stays on it after the battle ends (it used to be restored automatically). Every day at midnight the remaining damage is repaired in the field, as far as the government's materials allow. Units on the move are not repaired, and equipment that is completely lost is not covered.

However, repair capacity only comes from a few series that have gained a "repair" effect through research, such as biometal models and military trucks. Most equipment therefore never recovers. Meanwhile, gear that can be repaired goes back to brand-new condition with nothing but field tools. There is no way to send gear back to a workshop, and the screens do not show how damaged anything is.

What we want to make more interesting

Restoring gear to new condition with limited field tools feels wrong. But if nothing can be fixed at all, the wounds of a single battle drag on forever. So we want to draw a line per model: "this much in the field, the rest at the rear." That turns maintainability into a reason to pick one model over another. A model with slightly weaker stats but easier upkeep could win a long war.

Plan 1: condition and the field-repair limit

Each item would have a condition (1 − remaining damage ÷ damage limit), and each model a field-repair limit between 50% and 90%. In the field, gear is repaired a little at a time until its condition reaches that limit. Research-based repair capacity only makes repairs faster; it never lifts the limit.

Each category gets a default, and models can override it. For example: infantry gear 90%, armor 85%, support equipment 75%, vehicles 70%, aircraft 60%, ships 50%. A simple military truck might get 85%, while an Assault Gun Vehicle, which combines a gun and a hull, might get 65%. An Assault Gun Vehicle at 38% condition can climb back to 65% in the field, but the last 35% only returns at a workshop.

Concept mock (plan under consideration). A unit's equipment condition with a condition bar, the field-repair limit (white mark), an outlook and a status. Numbers and names are illustrative.

Plan 2: workshops share time between building and repairing

Damage beyond the limit would be repaired by sending the equipment back to one of your own workshops. While it travels and is being repaired, it does not count toward the unit's strength, and it rides on the existing equipment transport. At the workshop, repairs join the same queue as production orders and use the same work capacity as new builds. A repair restores the item to 100%, materials and costs come from the military share of the national budget, and the item returns to its unit when done.

We would like the Production window to list "Repair" rows next to new builds, showing how much workshop capacity goes to repairs and how "Deployed / required" recovers when they finish. Each workshop can switch "Repairs first" on or off; when it is off, repairs only use idle capacity. You choose, on one screen, whether to rush new equipment or bring damaged gear back.

Concept mock (plan under consideration). This morning's Production window with a repair row added. Numbers, places and unit names are illustrative, not actual game values.

Implementation steps and how it fits with other systems

The planned order is: (1) master data for maintainability per model and category (limit, work and materials); (2) the field-repair limit, plus a basic repair capacity that works for models without research; (3) sending gear back (temporary detachment and equipment transport); (4) workshop repair work (materials and costs, never counted twice when the same step is re-run); (5) the unit and production screens (Japanese and English); and (6) save/load round trips and the nightly 31-day comparison.

The adopted equipment specification currently repairs in the field until no damage remains, so this item changes it. A follow-up plan lets commanders' personalities decide when to send gear back (BTL-014, touched on in #77); it comes after this system.

Tell us what you think

Does a field-repair limit between 50% and 90% sound like a meaningful difference between models? Or would something simpler, like "all vehicles go back to the rear," be easier to follow? We would love to hear whether choosing between repairs and new builds for your workshops sounds fun.

Image 1 is from a development debug build captured with a verification setup; images 2 and 3 are concept mocks (plans under consideration). Numbers are illustrative, not actual game values.

This morning's post: DEVELOPMENT SNAPSHOT #86 — The Production Window Looks Ahead: Shortages and What to Build

Commanders' judgment: DEVELOPMENT PLAN #77 — Commanders Who Reread the Battle

Previous plan: DEVELOPMENT PLAN #85 — When the Weather Gets to Work

See the files currently available and the development status on the download page

Comment (0)

Happa - DEVELOPMENT PLAN #87 — Where Broken Gear Gets Fixed: Field Repairs and Rear Workshops
https://www.happa.bz/article.php?story=devblog-087-field-repair_en