# Устаревание юнитов в производстве и очередях

Продолжение модернизации и пунктов 4.1, 4.2, 4.7–4.9. При наличии доступной замены старый тип перестаёт приниматься в новый заказ и очередь, а уже выбранный заказ и записи очереди переходят на замену. Существующие отряды при этом не меняются: для них остаётся отдельный платный приказ U/Shift+U.

## Общий расчёт

Производство и модернизация используют один проход по полной цепочке `upgrade_to`: национальная доступность, технология, домен и ресурсы текущей сети города. Недоступный промежуточный вариант не мешает перейти к более позднему доступному. Стоимость, наличие денег, казармы и оставшееся движение относятся к улучшению готового отряда и не определяют устаревание производственного типа.

Устаревший тип не показывается в списке новых заказов. Ядро отвергает его явный выбор и добавление в очередь со структурированной причиной и номером замены. Губернатор и ИИ пользуются той же проверкой. Проекты с собственными типами используют свои ссылки и требования; изменение шаблона не создаёт отдельного исключения.

## Заказ и очередь

Автоматическая замена сохраняет щиты, инженерный вклад, ограничения запаса, пищу, население и казну. Она не создаёт юнит и не расходует случайность. Порядок очереди, повторяющиеся заказы и находящиеся между ними здания сохраняются. Если меняется только очередь, текущее здание и его инженерные щиты остаются прежними.

Расчёт выполняется перед обработкой городов, после изменений требований и при последующей успешной команде владельца. Изменение границ перепроверяет затронутые стороны. Дорога, завершённая рабочим в текущей модели межходового расчёта, может сделать замену доступной до городского урожая. Открытая технология обновляет оставшийся заказ и очередь в том же результате команды. Это порядок собственного движка; точная последовательность фаз Windows-оригинала остаётся непроверенной.

Когда ресурс теряется, старый тип снова можно выбирать, если выполнены его собственные требования. Уже обновлённый заказ автоматически не понижается. Потеря требований у выбранного нового типа сохраняет прежнюю политику ожидания допустимого производства; этот крайний случай требует оригинального контроля.

Если собственная замена дешевле накопленного запаса, смена цели не обрезает щиты и не выпускает юнит немедленно. Завершение происходит при обычном расчёте города; действует существующее правило обнуления/ограничения излишка.

## Просмотр и ускорение

Для старого заказа интерфейс строит неизменяющее представление города с актуальной целью и очередью. В окне показаны замена, её стоимость и сохранённые щиты. Просмотр и отмена не переписывают состояние партии. Расчёт ускорения использует ту же актуальную цель; подтверждённое ускорение списывает её цену и заполняет её запас. Фактический выпуск проверен через обычный ход города и ИИ.

## Сохранения

Экономическая модель изменена с `city-economy-v12` на **`city-economy-v13`**, схема собственного состояния — с 20 на **21**. Миграция опубликованной схемы 20 меняет ровно эти два поля. Карта, юниты, порядок Wait, задания/прогресс рабочих, щиты, текущий заказ, очередь, игроки, решения и PRNG остаются прежними. Устаревшие заказы нормализуются следующей успешной командой; загрузка сама по себе их не меняет. Неизвестные модели отвергаются.

Проверены два подготовленных файла, созданных сохранёнными модулями опубликованной сборки `15f51b71cae309fa`: обычная партия с незавершённой дорогой и очередью, а также самодостаточная партия с собственными правилами. Это подготовленные проверочные состояния, а не утверждение об их естественном ручном прохождении. В обоих случаях сравниваются все поля с допуском только двух изменений версии. Встроенный пользовательский набор сохраняет прежний идентификатор и содержимое.

## Проверки и источники

Скачать подготовленные исходные файлы схемы 20: [обычная партия с дорогой и очередью](data/published-schema20-production-road.json), [партия с собственным набором](data/published-schema20-custom-production.json). Их можно открыть кнопкой загрузки партии; это собственный JSON, не оригинальный SAV.

16 новых проверок производства покрывают доступность ресурса, национальную цепочку, текущую цель/очередь, щиты/инженеров, команды отказа, фактическое обучение, потерю ресурса, обычное завершение дороги, исследование, ускорение, собственный тип, чужой город, миграцию и неверные модели. Дополнительная проверка переносит опубликованный пользовательский файл схемы 20. [Сводный отчёт](data/production-obsolescence-verification.json) содержит результаты автоматических и публичных браузерных проверок.

[Браузерный отчёт](data/browser-obsolescence-verification.json) проверяет список заказов, просмотр/отмену без мутации, цену и фактическое ускорение, выпуск мечника, обычный ответ ИИ, экспорт/загрузку, потерю железа и импорт опубликованного файла с рабочим. [Снимок окна](data/production-obsolescence.png).

[Оригинальное руководство, раздел The Production Box](https://manuals.plus/m/0e4e661dbe03e34fd522a8657e1f6f14e231f153a7db35db7510f651a27ea36e) прямо описывает автоматическую замену строящегося юнита после открытия доступной более новой версии и порядок очереди. Национальные ссылки и требования берутся из закреплённого BIQ Atlants. [C3X, закреплённый анализ исключения промежуточных типов](https://github.com/maxpetul/C3X/blob/117bb1699376754738f3ed5e04f4c27b42845919/injected_code.c) помогает выделить отдельные модифицированные варианты поведения; его необязательные изменения не принимаются за правила исходной игры.

Сходство с Windows проверяется отдельно от воспроизводимости нашего движка. Открыты точный порядок фаз исследования/урожая, ресурсные и уникальные крайние случаи, полный каталог способностей и остальные системы MVP. [Модернизация готовых юнитов](unit-upgrading.md) · [Конструктор](custom-unit-designer.md) · [Полный план](../development-plan.md).