fparkan/docs/appendices/knowledge-boundaries.md

# Границы знания

Этот раздел перечисляет области, где контракт ещё не закрыт полностью. Они не
мешают безопасному чтению и lossless сохранению, но не должны превращаться в
authoring API без динамического подтверждения.

## Render state

Доказаны frame boundaries, world traversal, material resolve и крупные проходы.
Не доказаны символами точные имена renderer vtable slots, полный набор CShade
state transitions и окончательный порядок части transparent/FX/shadow subpasses.

Дистанционная кривая тумана по квадратам границ подтверждена в живом CShade.
Обычный GPU fog color из горизонта подтверждён исполнением; выбор проходов по
native shade-state и их временные изменения цвета пока заменены общим туманом мира;
это приближение считается как `render_coverage fog_pass_eligibility_approx`.

После ограничения цели рельефом интерактивная камера проверяет движение
против каждого отрисовываемого корневого строения класса `FORT` и его
отрисовываемых компонентов. Для этого пути используются текущая Node38-поза
компонента и его преобразование присоединения. При попадании камера сохраняет
прежнюю позицию, но оставляет новый поворот. Так приложение связывает мировой
MSH-запрос со свободной preview-камерой; это не подтверждает алгоритм
стратегической или следящей камеры оригинала.

Локальный MSH-запрос `query_slot_segment` сверён с оригиналом на фабричной
стене и дверном проёме. Runtime-адаптер `query_building_segment_world` теперь
повторяет helper batch bit `0x0008` через связанный узел, указанный raw-словом
`Batch20 +0x06`. При повторе он обходит Node38-поддерево: сначала допустимых
потомков, затем сам узел. Флаги ветвления сверены с оригиналом. Синтетические
тесты покрывают связи, отсутствие геометрии у промежуточного узла, маски,
равные попадания и предел в 200 пересечений.

Игнорируемый тест приложения загружает настоящий PLANT 4 из AutoDemo и его
исходную CTLD-привязку Node3 (`frame_a = 0`, `frame_b = 1`, blend `0`). В
контроллере корневого PLANT нет записей tag-21 для открытия двери. В исходной
закрытой позе камера блокируется о дверь через обычный путь обновления
приложения. Для второго запроса тест вручную задаёт время `1` только Node3,
обновляет иерархию позы компонента и преобразование присоединения, затем
проверяет, что камера проходит через проём. Это подтверждает только подачу
выбранных поз в коллизию приложения: тест не запускает событие открытия, не
доказывает видимое открытие двери и не сравнивает полный игровой цикл с
оригиналом.

Открыты выбор первого корня и правила состава узлов/slot-ов оригинального
мирового запроса, сравнение полного обхода с оригиналом, а также связь с
игровыми позами и событиями. Текущий путь приложения использует все
отрисовываемые компоненты строений `FORT`, но их выбор ещё не сопоставлен с
поведением оригинала для первого корня и всего мира. Совпадение со
стратегической и следящей камерами не подтверждено
([MSH](../reference/msh.md)).

Кривые alpha и метрика расстояния порталов реализованы для MSH без type 16
([описание кадра](../reference/render-frame.md#прозрачность-порталов-msh)). Native CPU clipping может выбрать другую первую вершину;
это приближение явно считается как `portal_fade_packet_selection_approx`.

Данные type 16 ещё не декодированы. Внутренний ракурс «Конструктора» после
настоящего входа игрока подтверждает исчезновение чёрной поверхности в проходе;
наружные окна обеих миссий сверены на расстояниях около 60/85/110, а ближние
окна — с внутренней стороны. Окно «Конструктора» на правом краю кадра при
дистанции около 85 совпадает; внутренние дальние ракурсы и остальные случаи
отсечения ещё не приняты. Общей готовности R2 эти пары не доказывают.

Старые захваты без `geometry_projection` используют состояние камеры после
обхода мира, которое может отсекать близкие поверхности. Это отмечается
`captured_projection_unverified`; для приёмки таких поверхностей нужен новый захват.

Закрывающий эксперимент: запустить оригинал в совместимой Windows/DirectX
среде, перехватить DirectDraw/Direct3D calls и surface flips, сохранить state
log на минимальных сценах с одним типом материала.

## FXID field-level semantics

Control Op1 пока использует цвет и радиус без случайных добавок команды;
это явное приближение считается в `render_coverage control_op1_jitter_unsupported`.
Масштаб радиуса длиной преобразованного направления и нижняя замена 0,01 восстановлены.

Control Op2 воспроизводит modes 0/2; modes 1/3, body+76 и неподдержанные
time modes/привязки считаются как `render_coverage control_op2_unsupported`.
Управление фазой экземпляра командами Control остаётся до его подключения в runtime.

Размеры команд, resource references, lifecycle, flags families и используемые
time modes известны. Не закрыто значение каждого поля body opcodes 1--10,
отсутствующий во всех проверенных каталогах opcode 6 и точные формулы редких
time modes.

Закрывающий эксперимент: изменять по одному полю копии эффекта, воспроизводить
его в контролируемой сцене и логировать runtime command object, emitted
primitives, sound events и reads в `Effect.dll`.

## Script VM

Доступны packages, symbols, event sections, variable declarations и version
checks. Полная instruction grammar `.scr`, semantics opcodes и serialization
state ещё не восстановлены.

Для GOG `ai.dll` статически восстановлены пять ветвей evaluator-а 16-byte
записей условий по RVA `0x5180`, включая проверки типов, поиск объектов,
короткие выходы из обхода списков и запись байта завершения. Однако не найден
код-производитель этого массива и контракт его владельца с runtime. Reader
`FUN_10011b20` хранит описатели событий и вложенных записей `.scr` во внутренних
контейнерах с шагом `0x14` и `0x20`; сами дисковые структуры имеют переменную
длину из-за length-prefixed имён и списков ссылок. Связь этих контейнеров с
массивом evaluator-а не доказана. Виртуальные методы,
через которые проходят проверки, остаются внешней границей, а сам evaluator
не сравнивался с работающим оригиналом. Описание этих ветвей — статический
вывод по одному известному `ai.dll`, а не утверждение о совпадении во время
исполнения.

Для начального сценарного события закрыт более узкий путь. В проверенной GOG
сборке `ai.dll` SHA-256
`c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc` функции
`FUN_10011f40` (RVA `0x11f40`) и `FUN_10011f10` (RVA `0x11f10`) выбирают первое
имя-событие C-string `Init` и запускают его инструкции по порядку. Для координат
из TMA найден и проверен ещё один участок: `iron3d.dll` SHA-256
`d1dc4ea8535e2069b0a05c9e8be2724dd438ba44cca7a83007d8b2e50f9e35fa`,
`FUN_100392e0` (RVA `0x392e0`) выполняет x87 `FISTP qword` и передаёт младшие
DWORD координат пятым и шестым аргументами `CreateSuperAI`. Затем
`ai.dll!FUN_10005c70` (RVA `0x5c70`) преобразует DWORD в `float`, а `Handler(19)`
возвращает его к DWORD усечением.

Две x86-проверки вызвали эти оригинальные DLL-функции на изолированной
синтетической памяти. Caller oracle подтвердил AutoDemo-координаты
`(500.2857, 751.8217) -> (500, 752)`, ties-to-even в nearest-режиме и переход
`-0.6 -> 0xffffffff`. AI oracle проверил оба набора AutoDemo anchor-ов,
дублирующий `Init`, имя `Init\\0suffix\\0`, отсутствие события, а также
нативную связку `FUN_10005c70` → `Handler(19)`: DWORD `(0xffffffff, 10001)` стал
полями `(2^32, 10001.0)` и varset-записями `(0, 10001, 2)`. Эти проверки
подтверждают только изолированные участки ABI.

В одном read-only snapshot запущенной GOG AutoDemo были связаны записи кланов
Iron3D и указатели `GetSuperAI` из `ai.dll` (таблица RVA `0x55398`). Клан 0 имел
исходные float-координаты `(500.2857, 751.8217)` и поля AI
`(+0x80, +0x84, +0x7c) = (500.0, 752.0, 0)`; клан 1 имел `(728.0, 449.0)` и
`(728.0, 449.0, 1)`. Первый набор связывает те же значения в одном процессе и
выбирает ближайшее округление среди направлений округления x87. Синтетические
tie-векторы проверяют, как сам `FISTP` реагирует на каждый RC, но не измеряют
control word процесса.

Лицензированный AutoDemo по-прежнему загружается с raw TMA anchor-ами
`[(500.2857, 751.8217), (728.0, 449.0)]` и записями `[(500, 752, 0),
(728, 449, 1)]`. Rust теперь также читает optional `.fml` sibling для каждого
script base и поддерживает узкий набор атомарных формул в первом `Init`.
Отсутствующий `.fml` не мешает пакету с одними `Handler(19)`; другие ошибки
чтения распространяются как VFS errors.

Нативный конструктор показывает предупреждение при координате выше `10000`, но
продолжает работу. Rust моделирует числовую запись, а не это UI-предупреждение;
на первом `FISTP qword` он явно завершает загрузку ошибкой для NaN, infinity и
значений вне signed-qword диапазона. В первом событии `Init` Rust поддерживает
два доказанных действия: `Handler(19)` и formula assignment selector `-1` при
source `-1`, нулевой глубине условий и корректных индексах. У `Handler(19)`
control находится в `header_words[3]`, а `header_words[1]` — result-save
reference; оба равны `0xffffffff` в поддержанной форме. В дисковом заголовке
formula assignment `header_words[1]` — индекс целевой varset ячейки,
`header_words[2]` — source, а индекс formula row занимает `header_words[6]`;
индексы цели и формулы в native record находятся по смещениям `+0x08` и `+0x1c`
соответственно. Маппинг подтверждён
`ai.dll!FUN_10011b20` (RVA `0x11b20`) и исполнителем `FUN_10012020` (RVA
`0x12020`), SHA-256 `c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc`.
`Handler(19)` (`FUN_1000aa38`, RVA `0xaa38`) использует references `0..2`;
`header_words[2]` его result-save guard-ом не проверяется.

Formula table загружается из `<bundle-base>.fml`; native `FUN_100123b0`
(RVA `0x123b0`) проверяет ordinal, compiler `FUN_100152a0` (RVA `0x152a0`)
строит числовые, переменные и операторные узлы, а evaluator `FUN_10015b30`
(RVA `0x15b30`) в проверенных путях `+` и `-` считывает значения переменных и
сохраняет результаты как `f32` при x87 control word `0x007f`. В GOG-сборке
`ai.dll` с SHA-256
`c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc` поиск
переменной через varset vtable slot `+0x10` ведёт на RVA `0x16ad0`: сравнение
байтов точное, регистр учитывается, при повторах берётся первое объявление.
Getter `FUN_10013190` (RVA `0x13190`) читает type `3` как `f32`, type `5` как
беззнаковый `DWORD` и возвращает число через x87. Затем evaluator сохраняет
его как `f32` до операции. Оператор `+`
считает right+left, `-` — left-right; результат также сохраняется как `f32`.
Target type `3` сохраняет эти bits; type `5` проходит через `FUN_10012c00`
(RVA `0x12c00`) и `__ftol` (RVA `0x1df70`) к raw DWORD с усечением к нулю.
Изолированный x86 oracle на оригинальном `ai.dll` и настоящих ресурсах
подтвердил таблицы `tut1_pl2`/`scr_pl_1`/`scream` с
26/5/149 строками и 15 присваиваний: кампанийные `df0..df3` и `Single.01`
`dT8/dT9` получают `0`; `scream` задаёт `fDifficulty = 0.8f` и остальные
проверенные DWORD `0, 0, 1, 10, 0, 100, 400, 2`.

Граница Rust остаётся узкой: один числовой токен либо ASCII-имя переменной,
или два таких атома с одним бинарным `+`/`-`. Имя проверяется раньше числового
преобразования, сравнивается с учётом регистра и выбирает первое совпадение;
публичный `FormulaTable::evaluate_numeric_literal` принимает только числовые
литералы. Временная копия значений начинается со значений по умолчанию и
обновляется после каждого успешного действия `Init`, поэтому следующая формула
видит предыдущие записи. Нет
поддержки неизвестных операторов, унарных форм, третьего атома, отсутствующих
или не-ASCII имён и source-copy ветви `source != 0xffffffff`; native source-copy
переносит всю запись varset. Preview сохраняет package, но не применяет частичные
writes; полный load отклоняет новый мир и сохраняет прежние world/RNG. Это
политика ограниченного Rust resolver-а, а не правило оригинального dispatcher-а.

Ресурсные строки с переменными найдены в поздних событиях: `c1m3e.fml` row 19
(`0.8 + fT`) вызывается из `Fort_Captured`, row 22
(`dBuildingProtectHits - dT2`) — из `PBM_BUILDING_PROTECT_Start`, а `c1m4e.fml`
row 0 (`fTemp + 0.00001`) — из `PBM_BUILDING_INF_CAPTURE_Start`. Декодирование
этих `.scr` не показывает эти формулы в первом `Init`. Игнорируемая проверка
читает настоящие `.fml` и `varset.var`, но вставляет строки в синтетический
`Init`; она проверяет resolver, а не оригинальное исполнение. Одноразовый x86
oracle на исходной GOG `ai.dll` с SHA-256
`c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc` проверил
13 отдельных присваиваний: 9 контролируемых выражений и 4 вызова с настоящими
строками `.fml` (`c1m3e` rows 19/22, `c1m4e` row 0 дважды подряд). В каждом векторе
native harness записывал вычисленный `f32`, типизированное raw-слово и getter;
scratch-проход через публичный Rust parser/resolver совпал со всеми 13
векторами по `f32`-результату и raw-записи. Для native вызовов control word
временно принудительно устанавливался в `0x007f`: 87 наблюдений сохранили
`0x027f` на входе и после восстановления,
а canary-проверки прошли. Менялись только varset-копии в памяти. Это
подтверждает компиляцию формулы, локальное вычисление и typed writes для этих
входов, но не запуск исходного поиска и обхода события `Init`, исполнение поздних
событий или поведение живой миссии.

Лицензированный test загружает одну первую кампанийную миссию
`CAMPAIGN/CAMPAIGN.00/Mission.01/data.tma` после literal writes; это не проход
всей цепочки кампании. Обычная `Single.01` доходит до следующего blocker-а:
`Handler(43)` в clan 1, `Init` instruction 10. Rust не перескакивает его;
preview оставляет varset этого клана на defaults, а полный load завершает ошибкой
с rollback. В `fparkan-assets` теперь есть bounded TRF reader, pure ore/power
core и `ResearchCandidateSet::refresh_selection`: последний получает уже
упорядоченные entries и отдельный TRF-контекст, затем читает Unit DAT через VFS.
Он не строит AI-каталог и не исполняет script instruction. Runtime всё ещё не
создаёт владельца живого контекста, не передаёт реальные AI candidates и не
выбирает результат Handler(43). Это не общий dispatcher и не загрузка игры.

Начальный массив слота AI `+0x38` теперь восстановлен отдельно от этого
исследовательского пути. В `iron3d.dll` SHA-256
`d1dc4ea8535e2069b0a05c9e8be2724dd438ba44cca7a83007d8b2e50f9e35fa`
`FUN_100392e0` (RVA `0x392e0`) вызывает слот для каждого значения счётчика
`second_resource.tag`. В `ai.dll` SHA-256
`c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc` метод
RVA `0x2010` передаёт `AI+0x83c` в `FUN_10002980` (RVA `0x2980`), где
`FUN_100048f0` (RVA `0x48f0`) добавляет переданный DWORD. Вызывающая сторона
повторно передаёт `0xffffffff`; эта функция не записывает значение обратно.
Поэтому подтверждён только начальный массив sentinel-слов. Неизвестно, какие
поздние обработчики читают эти ячейки и заменяет ли кто-либо их ID. В начальном
массиве нет назначенных ID объектов; дальнейший смысл этих слов пока не
установлен. Сам массив не является списком
`BehaviorDistributorState.registered_objects` и не определяет владельца
контекста исследований.

Rust хранит этот снимок как `MissionAiStartupState` в состоянии загруженной
миссии. Полная загрузка проходит по всем TMA-кланам, включая кланы без пакета
сценария и без пути таблицы исследований; при предпросмотре список состояний AI
остаётся пустым. Знаковое поле `second_resource.tag` читается по сырым битам как
`u32`. Бюджет в 1 000 000 DWORD на миссию и выделение памяти с обработкой ошибки
защищают только память Rust; это ограничение не приписывается оригинальному
движку. Искусственные Rust-тесты проверяют обе формы TMA-клана, индекс клана,
независимые массивы, пустой путь сценария, предпросмотр, чтение тега как
беззнакового числа, лимит и откат при ошибке. Проверка на оригинальных ресурсах
для `Single.01` подтверждает состояния обоих кланов (`9/9`) до выполнения
`Init`; это не полный запуск миссии и не исполнение исходных DLL.

Для GOG-сборки также найден статический host call path в `Init`. В
`iron3d.dll!FUN_1005ff40` (RVA `0x5ff40`) одна ветвь сначала проходит записи
кланов и вызывает для них `FUN_100392e0`, затем вызывает `FUN_10039440` (RVA
`0x39440`). Эта функция передаёт AI callback-у пару явных аргументов через
vtable slot `+0x14`. В `ai.dll!FUN_10001ae0` (RVA `0x1ae0`) аргумент callback-а
записывается в `AI+0x3fc`; затем объект `AI+0x438` получает вызов Behavior
vslot `+0x2c`. В проверенной `Behavior.dll` (SHA-256
`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`)
`FUN_1001adb0` (RVA `0x1adb0`) выполняет начальную подготовку расписания.
Метод ищет первый `Init` только при нулевом latch
`AI+0x8a8`, а при dispatch временно ставит и снимает recursion guard
`AI+0x78`. В этой ветви поэтому известны callback ingress и порядок
warm-start → `Init`, но смысл аргумента callback-а здесь не сопоставлен с Rust
`MissionMode`.

Изолированный x86 oracle вызывает исходные `iron3d.dll!FUN_10039440`,
`ai.dll!FUN_10001ae0` и script dispatcher на синтетических записях и проверяет
режим, guard, latch, Handler(19) writes и повторный вызов. Отдельный oracle
исполняет `Behavior.dll!FUN_1001adb0` с искусственно заданной очередью, сверяя
срок, шаг LCG и очистку полей. Это подтверждает ABI и локальные переходы исходных
функций, но не доказывает, что полная штатная загрузка выбранной миссии в
оригинальном процессе доходит до этой ветви в том же порядке. Метод
`FUN_10001ae0` оставляет latch `+0x8a8` сброшенным, когда `Init` не найдено;
если оно найдено при уже занятом guard `+0x78`, dispatch пропускается, но latch
всё равно устанавливается. Rust пока запускает обработанный поднабор при каждой
полной загрузке и не моделирует аргумент callback-а `AI+0x3fc`, guard `+0x78` или
latch `+0x8a8`.

Rust `load_mission` принимает явный `queue_time_ms`, а не читает оригинальное
время очереди. Новый `Engine` начинает локальный Behavior RNG с seed `1` и
учитывает шаги генератора этой стартовой последовательности; не восстановлены
другие потребители исходного генератора, поэтому равенство полной случайной
последовательности не утверждается. Начальная фаза выполняется после регистрации
объектов в создаваемом мире Rust;
это интеграционный выбор runtime, а не подтверждённая эквивалентность всех
host construction phases. Не проверена другая лицензированная миссия с
непустым `Init`. Вызов `Behavior.dll!FUN_10019e80` (RVA `0x19e80`, SHA-256
`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`) исполнялся
на синтетических интерфейсах. Путь членства в реальных distributor-списках
связан с полями TMA и Unit DAT: `World3D!CreateObject` передаёт selector
и class word через дескриптор в Behavior (RVA `0x7e55`, `0x7e62`), а
`Behavior.dll!FUN_10005e60` (RVA `0x5e60`) проверяет высокий бит registration
key, AI и distributor. Selector из первого DWORD после имени ресурса выбирает
слот `GetSuperAI`; таблица этой функции находится в `ai.dll` RVA `0x55398`.
Хеши `MisLoad.dll`, `iron3d.dll`, `ArealMap.dll`, `World3D.dll` и
`Behavior.dll`, использованных для цепочки, перечислены в
[справочнике TMA](../reference/tma.md).

Отдельный режимный бит Behavior нельзя выводить из `MissionMode`. Конструктор
Behavior (`Behavior.dll`, RVA `0x3600`) вызывает `World3D!stdGetGameMode` (RVA
`0x14750`), который читает host-global по RVA `0x795130` в `World3D.dll` (SHA-256
`17e4a3089b2583a8cf2356c9db0390b1aba138356a09130d79b4e7e4791da61e`). В
обычном пути `stdInitGame` (RVA `0x13e90`, запись режима около `0x14040`)
формируется отдельное host-значение; в наблюдавшемся запуске AutoDemo getter
вернул `4`, и бит `0x2` был снят. Это объясняет соответствующий gate при
создании Behavior, но не устанавливает отображение между host-режимом и Rust
`MissionMode`.

Наблюдение обычного запуска лицензированной GOG AutoDemo подтвердило четыре
добавления с ключами `0x80000003..0x80000006` в два клановых списка. Полная
загрузка Rust сохраняет соответствующие `ObjectHandle` в точном доступном слоте
`GetSuperAI` до стартового `Init`; preview не создаёт членств. Лицензированный
тест связывает эти записи с TMA ID 4–7, selector и Unit DAT class. Это
подтверждает только состав списков, не точную эквивалентность всей загрузки или
регулярного шага Behavior.

Нативный `Behavior.dll!Add` (RVA `0x1aac0`) и `normalize` (RVA `0x1ac90`)
проверены прямыми x86-вызовами на синтетических записях при x87 control word
`0x007f`, измеренном также у игры на входах обоих методов. Rust повторяет
начальные доли и нормализацию отдельными операциями `f32`, а повторную запись
сопоставляет по `ObjectHandle`, меняя только долю существующего участника.
Пять DWORD после доли хранятся сырыми; ненулевое первое слово закрепляет вес,
смысл четырёх следующих не установлен. Лицензированный AutoDemo-тест проверяет
список TMA-объектов и получившиеся начальные доли по кланам, но это не сравнение
живых весов миссии с полями исходных runtime-записей. Не восстановлено соединение
с реальными интерфейсами ArealMap, нужными `FUN_10019e80`; полный Behavior tick
flow и общий dispatcher событий также остаются открытыми.

`loaded_mission_behavior_control_groupings` публикует только начальную
группировку подготовленной Control-таблицы. Ветка с меткой `2` исходного
`Behavior.dll!FUN_1001be10` (RVA `0x1be10`) дополнительно вызывает
`FUN_1001b4b0` и обращается к свойствам через QI `0x204`, включая запросы с
номерами `0x700`, `6` и `0x400`. Результат `0x700` попадает в строку кандидата
по смещению `+0x3c`, результат `6` — в `+0x40`, а `0x400` может обнулить второе
поле. Их доменный смысл, множитель `0x700`, агрегаты Behavior QI `0x204` и
прочие числовые поля кандидата не восстановлены. Rust не подставляет множитель
`0x700`, нулевые агрегаты, выбранный индекс или эффект. Список для метки `30` не
встречается в ресурсах AutoDemo и проверяется только на искусственном наборе.

Игнорируемая проверка AutoDemo сравнивает порядковые номера записей начальной
группировки, отдельно выведенные по снимку текущих меток дескрипторов, с
состоянием Rust после полной загрузки. Это подтверждает согласованность разбора
подготовленной таблицы и правила группировки на этих ресурсах, но не является
захватом состояния Behavior оригинала и не устанавливает, когда список
прикрепляется или обновляется в живом объекте. Полный штатный путь загрузки и
запуска, агрегаты Behavior QI `0x204`, обновление после изменений Control,
`Handler(43)` и полный игровой цикл остаются отдельными границами.

Начальные свойства `CurrentOre`/`MaximumOre` восстановлены отдельно от
регулярного обмена. В проверенных `Behavior.dll` (SHA-256
`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`) RVA
`0x8790` выбирает начальные значения по class word, `0xb110` регистрирует
дескрипторы кодов 4/5, `0xb470` пишет только код 5, а `0xb5b0` читает код 4
как дополнительное слово и код 5 как основное. `MisLoad.dll` (SHA-256
`c607762bb67db14ca530927c8e1347339b62b0a163ac90c708ee83142292e2bf`) RVA
`0x40b0` выбирает первое свойство TMA с точным именем `CurrentOre` и передаёт
его `raw_value[1]`; setter сохраняет биты напрямую. В AutoDemo snapshot на этих
входах было восемь объектов Unit DAT, у всех raw `CurrentOre` равен нулю;
четыре объекта класса `0x01008000` не вошли в distributor, но остались среди
инициализированных Rust-состояний. Поэтому путь нулевого значения наблюдался
наживую, но ненулевое TMA-значение в живой миссии пока не проверено.

Синтетический x86 oracle вызвал `Behavior.dll!FUN_10008790` напрямую для классов
`0x80000004`, `0x80000008`, `0x01002000`, `0x01004000` и `0x01008000`; перед
вызовом в записи были значения `CurrentOre=123` и `MaximumOre=-1`, так что
проверено их перезаписывание. Тест выставляет `a64=1`, чтобы отключить отложенный
side effect обёртки setter-а. Это подтверждает ветви initializer-а, но не весь
путь его запуска и связи с остальными фазами объекта. Другой изолированный x86
oracle проверяет ненулевое raw-слово `CurrentOre`, только чтение `MaximumOre` и
перестановку строк дескрипторов на синтетических записях свойств.

Не проверен селектор 4 для внешнего config-like ресурса: в наблюдавшемся
AutoDemo его вызова нет, а установленный `Behavior.ini` не содержит
`Mine_MaxOre`, `Storage_MaxOre` или `Transport_MaxOre`. Поэтому Rust пока
воспроизводит доказанные class defaults (500, 4000 и 2000) и не заявляет
поддержку конфигурационного переопределения. Отдельно не доказано, что каждый
Unit DAT создаёт тот же Behavior-компонент во всех host factory paths. Rust
ограничивает новую запись полными TMA-объектами с Unit DAT; preview, прямые
prototype roots без Unit DAT и отложенные spawn после исходной загрузки вне
этой модели. Путь в `ArealMap.dll` (SHA-256
`a25f9254ebb339d70e2e07c8121950191e9584ca0858d8e9c2e2b6c671edf6ea`) к
`CreateObject` по RVA `0x14fd0`/`0x15290` показывает выбор World3D factory
selector `3` или `4` по старшему биту. Для ветки GOG `AniMesh.dll` (SHA-256
`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`) RVA
`0x2ff0` показывает одну ветку создания: после QueryInterface для IID `0x204`
выполняется отдельный импорт `GetQueue()`, а на возвращённом объекте вызывается
метод через vtable slot `+0x30`. `CreateBehaviour` вызывается только при
ненулевом результате этого метода и host class `3` или `4`; class `4` получает
адреса полей prototype `+0x140` и `+0x160`. Семантика метода slot `+0x30` не
установлена. Другие factory paths, нулевой результат и spawn после исходной
загрузки остаются за границами подтверждённой ветки.

Для `Handler(30)` отдельно подтверждены обратный вызов `iron3d.dll` RVA
`0x611d0` (SHA-256 `d1dc4ea8535e2069b0a05c9e8be2724dd438ba44cca7a83007d8b2e50f9e35fa`),
начальные поля IGame и проверки режима/состояния. Обработчик выбора миссии
выставляет режим 1 (RVA `0x29142`), а обработчик таймера — режим 3 (RVA `0x70f3`).
Небольшая тестовая x86-программа сравнивает этот обратный вызов с исходной DLL
на синтетических структурах. Пока не восстановлен сквозной путь от выбора и
инициализации миссии к первому событию Handler(30): Rust загружает миссию, но
ещё не выполняет штатный `stdInitGame`, переход состояния `5 -> 4`, запуск и
игровой цикл с полной диспетчеризацией событий. Поэтому
совпадение изолированного обратного вызова не доказывает совместимость живого
сценария.

Закрывающий эксперимент: найти dispatcher loop в `ai.dll`, сопоставить jump
table с instruction sizes, построить disassembler и сравнить выполнение
коротких scripts с оригиналом. Для evaluator-а условий отдельно проследить
создание записей `this + 0x34`, выполнить те же входные данные в оригинале и
сверить байт завершения, порядок поиска, ранние выходы и граничный случай
`payload == count`.

## Saves and campaign state

Найдены `saveslots.cfg` и `missions/dispatcher.ini`, но binary savegame payload,
serialization World3D/AI/script/RNG и migration rules не закрыты.

Нужны сохранения оригинала в контролируемых состояниях: старт миссии, изменение
позиции, здоровья, order/path, FX/timer, script variable, research/economy,
mission completion, pause и non-default game time.

## Physical/control formats

CTLD и связанные resources структурно читаются, count patterns и variants
известны. Не названы все секции, shape types, coefficients и точный contact
solver. То же относится к редким MSH auxiliary streams и части CTPT/NDPR flags.

### Класс Control при загрузке Unit DAT

Для двух подтверждённых полных Unit-DAT путей Rust теперь сохраняет класс,
который передаётся конструктору Control, вместе с ветвью-источником. Лицензированный
`min_l_n1.dat` проходит high-bit route и даёт класс `3`; synthetic-тесты покрывают
оба маршрута, известные FourCC и отсутствующие root metadata. Отдельное
исполнение проверило только чистый getter `Terrain.dll+0x33ae0` (SHA-256 и точный
RVA приведены в технической главе). Остальная цепочка через ArealMap, World3D,
Terrain/AniMesh и создание controller восстановлена по статическим инструкциям,
таблицам и конфигурации. Она не означает исполнения оригинального полного
loader-а, Control activation, движения или периодического tick.

Не моделируются произвольный ненулевой host с неудачным QueryInterface, preview
без полного Unit DAT, отложенный spawn и другие host/factory routes. В частности,
generic failed-query путь native оставляет class `0` и не читает FourCC; это не
эквивалентно canonical no-host lookup корневой registry entry. Остаточные вопросы
об активации и игровом поведении описаны в технической главе.

Одна цепочка Unit DAT → AniMesh descriptor → Control теперь восстановлена
статически в [главе о Behavior и Control](../tomes/06-behavior.md): raw
`parent_or_link` копируется в descriptor. В non-`EXTO` registry path parent ID
разрешается в индекс устройства и сдвигает локальный индекс только когда parent
ID не равен `-1` и IID `0x202` доступен; иначе используется raw локальный индекс.
В этом потоке нулевой raw kind пропускает узел вместе с потомками, поэтому общий
assigned ID нельзя получать из preorder-позиции записи. Полная загрузка миссии
в FParkan строит упорядоченную базовую проекцию таблицы
Control для объектов с Unit DAT: корневые записи добавляются, `EXTO` добавляет
строки с ключами глобальной MSH-иерархии, а `INTO` обновляет первую строку
выбранного индекса либо добавляет список при sentinel `-1`. Проверка полной
загрузки на оригинальном `min_l_n1.dat` получает 11 строк: 10 корневых записей,
четыре замены `INTO` и одну добавленную строку дочернего `EXTO`. Ветви C4/C8 и
добавление `EXTO` подтверждены машинными инструкциями оригинальных модулей, но
полный результат FParkan не сравнивался с таблицей из запущенной игры. Тест на
искусственном дереве также проверяет ID после пропущенного поддерева с raw kind
`0`. Проекция хранит общие поля и происхождение записей; она не исполняет все
обработчики Control.

Control различает добавление устройства и применение одной записи к уже
выбранному устройству. Исполнение оригинальной 32-битной DLL на искусственных
данных подтверждает общие поля переопределения для получателей tags `2`, `3`,
`4`, `5`, `8`, `9`, `10`, `15`, `19`, `21`, `25` и `27`: остаются прежними слот,
ключ, ID компонента, множитель и класс, а коэффициенты копируются из новой
записи. Обёртка tag `2` по RVA `0x29650` дополнительно пересчитывает два кэша
и обнуляет массив состояния map-строк; это выполнено на native DLL, но пока
не моделируется в базовой Rust-проекции. Её callback `0x29940` проверен только
с неизменной пустой парой ресурсов; стрельба не проверена.
Искусственный tag `9`-объект создан
без FX-хоста (`+0x3c == 0`), а запись не содержит строк таблицы map; поэтому
работа FX-хоста здесь не проверялась. В Rust parser-е
`Unsupported { typed_record_index: Some(_) }` означает, что разбор остановился
внутри списка typed records; без индекса остановки unsupported может относиться
к effect-tail после уже разобранного списка. Эти случаи нужно различать.
Ветка default native-фабрики вызывает конструктор по RVA `0x20800`, поэтому
неизвестный Rust parser-у tag не доказывает отказ оригинального loader-а. Подготовка assets
сейчас пропускает Control refs у non-geometric prototype, поэтому отсутствие
подготовленного CTL должно оставаться явным unavailable result, а не
трактоваться как пустой список.

Global Control getters `1/2` и setter `1` проверены в native x86 oracle для
искусственных factory/descriptor pairs `9`, `15` и `19`, а в Rust реализованы
для текущего descriptor tag `19` с factory tags `9`, `15`, `19` и `25`. Для tag
`25` общий getter slot `+0x10` подтверждён чтением vtable, но агрегатный вызов
этого класса native oracle не запускал. Rust API обращается к строкам проекции
конкретного живого `ObjectHandle`; это запрос к уже загруженной таблице, а не
исполнение Control или Behavior tick. Setter `17`, остальные factory tags и
внешние эффекты их методов не включены. Структурное чтение записи CTLD с
меткой 17 ещё не восстанавливает её обработчики и игровое поведение.
Для tag `9` selector `0` использует
отдельный scale `+0x11c`; остальные поддержанные классы используют коэффициент
напрямую. Пустой набор и нулевой знаменатель остаются native no-result, а
неподдержанный factory tag и расчётный диапазон произведения/отношения за
нормальным диапазоном `f32` становятся явной ошибкой Rust.

Проекция полного mission load недоступна для неполного списка typed records,
Control resource у non-geometric prototype и некоторых неразрешённых EXTO node
mappings; preview и объекты без Unit DAT root её не строят. Её соответствие
полной загрузке игры для всех типов компонентов и factory paths ещё не
установлено. Полный Rust load AutoDemo проверяет доступность всех восьми таблиц
и числа строк `14, 12, 15, 13, 12, 12, 11, 11`; это не сравнение с живой
таблицей оригинала. Setter `1` меняет multiplier `+0x4c` выбранных строк, но расписание
и lifetime этих объектов после конструктора и в отложенной загрузке остаются
непроверенными.

Для `Control.dll` (SHA-256
`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) tag-26
getter selector `0x300` восстановлен локально: RVA `0x21d00` читает provider по
ключу `fixed_words[1]`, затем умножает provider, CTLD coefficient `fixed_words[11]`
и поле объекта `+0x4c` именно в таком порядке. Provider getter RVA `0xdc40`
читает type-1 поле `+0x14` строки, которую `FUN_10008b10` (RVA `0x8b10`)
добавляет из NDP в таблицу с шагом `0x2c`; `FUN_1000b240` (RVA `0xb240`)
инициализирует это поле как `1.0`. Начальный Rust snapshot повторяет порядок
NDP строк корневого ресурса и примонтированных `EXTO` (без первой строки
последнего), сохраняя исходные таблицу и строку как provenance. Ключ устройства
сначала меняется по подтверждённому MSH mapping для `EXTO`, затем это готовое
значение применяется напрямую как индекс provider sequence. Длина этой
sequence определяется NDP: она не дополняется по числу узлов модели и ключ не
пересчитывается ещё раз по числу provider rows. `INTO` provider строк не
добавляет. Для примонтированного `EXTO` с пустым NDP невозможно безопасно
применить native skip-first путь, поэтому Rust явно сообщает unavailable;
таблица из одной строки допустима и даёт нулевой вклад. Если обязательный NDP
sidecar недоступен, запрос `0xe00` сообщает это отдельно, оставляя независимые
агрегатные selectors `1/2` доступными.

Поля `parent_index`, Control flags и начальный stage count для NDP-строк
проецируются из AniMesh по глобальному ordinal; точные правила, native ABI
векторы и лицензированная root/`EXTO` fixture описаны в
[техническом подразделе](script-vm.md#начальная-msh-часть-строки-provider).
MSH-часть проверки подтверждает начальный снимок: сборка runtime parent-ов
остаётся статическим выводом по RVA `AniMesh.dll+0xa460`, а последующие
изменения в полном Control/animation tick-е не проверялись.

Устройство фабрики `2` через selector `6` читает `+0x174` только при текущем descriptor tag `2`,
затем проверяет, что устройство создано фабрикой `2` и поле доступно. Значение
должно быть конечным нормальным числом или нулём любого знака. Строки в
`[27..35)` и `[35..43)` читаются до первого NUL: хвост игнорируется,
ASCII-регистр не важен. После изменения пустая строка оставляет старые биты;
пустая пара конструктора уже совпадает и не вызывает пересчёт. Проверка не
использует список имён: нужен один корневой mesh `BULL` из `ObjectsRegistry`,
без дочерних компонентов и записей timeline; все типизированные записи должны
иметь tag `17`, а эффекты и таблица NDP — разбираться полностью. Число строк
NDP произвольно, включая пустую таблицу.

Сканер возвращает коды выбранной начальной группы в исходном порядке. Допустимы
`1/4/12`. `Some([])` означает, что по полному разбору данных команд нет: группа
отсутствует, пуста или сырое беззнаковое значение индекса не меньше числа
групп. `None` означает неподдержанный либо неполный разбор; повреждённые данные
дают ошибку. Для выбранного opcode `4` нужны FXID-типы `2/3/4/5/7/8/9` и
допустимые CPT-смещения внутри компонента; типы `1/6/10` остаются недоступными.
Непредставленный ключ или число не превращаются в ноль. Если распознанный
ресурс повреждён, новая миссия завершается ошибкой до публикации, сохраняя
прежние мир и RNG.

Загрузка лицензированной AutoDemo и Rust-запрос selector `6` охватили 12
устройств и семь пар с битовыми значениями:
`bb_m_01=43f98000`, `bm_m_01=44228000`, `bl_l_01=436a0000`,
`br_b_01=44c80000`, `bf_b_01=443b8000`, `bl_m_01=443b4000`,
`bm_l_01=43340000`. Все семь значений совпали с замороженными арифметическими
векторами. Пятнадцать изолированных вызовов selector `35` оригинальной DLL
(включая семь однострочных BULL-таблиц) проверили арифметику при x87 control
word `0x007f`, но не создавали полный native World. Таблица Control-устройств
Rust по-прежнему строится при полной загрузке
Unit DAT. CPU-проекция не воспроизводит временное создание объектов оригинала и
его побочные эффекты FX, звука и RNG, размещение в World или следующий Control
tick. Полное размещение объектов, игровой tick, Handler 43 и другие
неподдержанные форматы остаются открытыми.

Для provider-строки Rust хранит amount `+0x08`, накопитель `+0x10`, обработанное
количество `+0x0c`, долю `+0x14`, стадию `+0x18` и flags `+0x28` раздельно.
Инициализатор `Control.dll+0xf940` кладёт результат selector `3` в текущее и
обработанное количество; при подтверждённых единичных множителях это raw
`max_volume` NDP. Таблица также хранит capacity aggregate `+0x58c`, текущий
aggregate `+0x590`, dirty `+0x598` и начальный gate `+0x618`.

Прямой API `apply_loaded_mission_control_node_delta` сохраняет native четвёртый
аргумент `0`: меняет amount, долю, флаг истощения, aggregate и dirty, оставляя
`+0x10` нетронутым. Публикация `0x200` отражается в CPU-проекции соответствующего
узла модели по правилу исходного обработчика; стадия и соседние узлы не меняются.
Обработанное количество при этой прямой операции остаётся прежним.
API `distribute_loaded_mission_control_provider_amount` переносит
`Control+0x10ba0`: proportional mode делит добавку по свободной ёмкости, а
вычитание распределяет по текущим количествам; sequential заполняет строки
вперёд, снимает с конца и использует исходный запрос даже если общая ёмкость
округлилась вниз. Row updater вызывается с четвёртым аргументом `1`, поэтому
`+0x10` получает фактическую разницу amount. После распределения обязателен
`0x11130(root, true)`.

Три API работают только с CPU-проекцией и не подключены к GPU/window path или
игровому Control clock. Отдельный
`advance_loaded_mission_control_budget` переносит `0x2d340` для фабричных
callbacks `9`, `15`, `19`, `26` и общей default-пары; category lookup использует
текущий descriptor tag из подтверждённого префикса `0..=34`. Ставки сохраняются
в `+0x5dc/+0x5e0`. Шаг выполняется транзакционно, а неподдержанный
специализированный callback, provider или диапазон числа возвращает ошибку без частичного
изменения. Тест с нулевым знаменателем генератора подтверждает откат после уже
выполненного изменения потребителем. Пустая таблица всё равно записывает в оба поля отрицательный ноль;
неактивный callback не требует provider lookup. Class-9 constructor начинает
шесть значений `+0x98..+0xac` с `1.0` и шесть дельт `+0xb0..+0xc4` с нуля;
`INTO` сохраняет эти runtime-массивы. Gate `+0x618` изначально
выключен; событие `7` задаёт его по правилу `gate = (arg == 2)` и вызывает
`0x2dc20`, только если gate изменился. События Control в Rust пока не
исполняются, поэтому ресурсный шаг вызывается явно и не подключён к часам.
Capacity aggregate выведен при подтверждённых единичных множителях Unit DAT;
изменение масштабов `0x9ee0`/`0x9f90` не реализовано. Из-за округления `+0x590`
может стать больше сохранённого `+0x58c`; распределение сохраняет этот signed
capacity по native формуле, не вводя отдельного запрета. Если итоговый stage walk
нуждается в неизвестном состоянии, depletion lifecycle, FX или host callback,
распределение сообщает ошибку и не публикует ни одной частичной записи.
Отдельный
`update_loaded_mission_control_node_stage` реализует наследование parent ratio
и stage, ceiling-арифметику, CPU visible stage и копию processed amount.
Отдельная `propagate_loaded_mission_control_node_stage` переносит `0x11130`:
после обновления строки она сканирует более поздние provider-строки и обходит
найденные поддеревья в native depth-first порядке. Для родителей
`[-1, 0, 0, 1, 3]` порядок — `1, 3, 4, 2`. Переносит унаследованный Control
ratio/stage, флаги `0x80/0x100` и drain количества; маска `0x140` пропускает
только перезапись flags, не drain и рекурсию. Ухудшение определяется ростом
стадии либо флагом истощения `0x10` уже обновлённого родителя. Отдельный
`update_loaded_mission_control_node_stage` сохраняет одиночную семантику
`0x11220`.

Пропагация клонирует Control provider-таблицу и публикует её только после
успешного обхода. Неизвестная parent-связь в просматриваемом суффиксе,
lifecycle/visibility/FX callback или неподдержанное численное значение дают
ошибку без частичных изменений. `update_effects = true` отклоняется, если
стадия любого обработанного узла меняется и требуются неисполненные FX/host
callbacks. Licensed двухстадийный узел шахты подтверждает переход `0 → 1` через
новый API при доле `0.5`, без FX и window path. Гибель root/critical узла и
неизвестные flags/aggregate также остаются явными ошибками.

Rust query обращается к загруженному объекту и поддерживает `0xe00` для пар
текущего descriptor tag и factory tag `(5,5)`, `(5,26)`, `(26,5)` и `(26,26)`;
прочие специализированные tag/factory пути остаются явными границами. Запрос
читает текущее type-1 значение provider. Licensed `min_l_n1.dat` подтверждает
изменение `0xe00` и Behavior `0x1002` с `1.0` до `0.5` после явного уменьшения
количества вдвое; чтение получает текущее значение provider, который также
меняет явный бюджетный шаг.

Indexed selector `0x400` в том же Control IID `0x204` возвращает текущее type-1
значение строки provider, выбранной через key устройства, при любом descriptor
и factory tag. Rust принимает конечное normal-or-zero значение, включая оба
знака нуля, и сохраняет его биты; недоступная таблица, отсутствующий key и
значения вне этой численной области дают типизированную ошибку. В оригинальном
`Control.dll` с SHA-256
`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e` ветвь
`FUN_1002bb40` (RVA `0x2bc3c`) читает provider pointer `device+0x44` и key
`device+0x04`, вызывает provider slot `+0x0c` в режиме `1` и не проверяет
descriptor/factory tag. Rust-проекция читает сохранённый снимок; она не вычисляет
value из amount, maximum, coefficients или множителя `M`. Native selector-cell
alias/fallback за пределами валидной записи и поведение native при невалидном
key остаются неисследованными; Rust не подставляет для них `0.0` или `None`.
Это покрывает перечисленные query-пути. Полный интерфейс IID `0x204`, его
взаимодействие со всеми Behavior-вызовами и полный игровой tick остаются за
границей подтверждённого поведения.

Объём свидетельств для `0x400` ограничен и состоит из трёх частей. Native
oracle на настоящем `Control.dll` проверил шесть выходов по raw bits для
ограждённого синтетического owner/provider table; он вызвал indexed query и
реальный provider getter, но не создавал оригинальные factory-объекты. Матрица
выходов находится в [техническом разборе](script-vm.md#индексный-control-getter-сырой-селектор-0x400).
Независимый разбор AutoDemo обнаружил восемь таблиц и 100 устройств с
доступными ключами, но все выбранные provider values равны `1.0`; такой набор
подтверждает загрузку и область ключей, однако не различает, какую именно
строку выбирает алгоритм. Игнорируемый Rust-тест опрашивает эти 100 устройств и
проверяет те же биты, не выдавая равенство ресурсных данных за доказательство
индексирования.

Вместе native-векторы и resource acceptance не подтверждают состояние
оригинальных factory instances, полный контракт IID `0x204`, полный
Behavior-call flow или живую миссию/gameplay. Поведение при ошибочных native
указателях и ключах, а также selector-cell alias/fallback вне валидной строки
по-прежнему не описано; Rust сохраняет typed errors на этой границе.
Native oracle проверил изолированные пути распределения, обновления класса `4`,
стадийную арифметику `0x11220`, обход дочерних provider-строк `0x11130` на
interleaved parents `[-1, 0, 0, 1, 3]` с callback-порядком `1, 3, 4, 2` и
visibility transition `0x11920` с исходными AniMesh callbacks. Отдельный
бюджетный вектор исполняет `0x2d340` → `0x2dca0` → tag 15 `0x22bb0` →
`0x10ba0`: подтверждены коэффициенты `0.5` и `1`, точные amount/ratio и
приоритет категории перед порядком устройств. Положительный вклад генератора
в этом векторе подставлен mock-ом. Отдельный вектор с исходным генератором
tag `19` (`0x22980`, `0x229a0`, `0x22a60`) проверяет полную и ограниченную
rate, изменение provider и собственного множителя генератора; отрицательные
параметры и нулевой знаменатель не проверены. Новый оригинальный вектор
`0x2d340` смешивает tag `19` и tag `26`: supply `0.125` покрывает половину
demand `0.25`, итоговые множители равны `0.6875` и `0.5`, а выходы —
`0x80000000` и `0x3e800000`. Тот же oracle подтверждает tag-26 selector `0x500`,
общий reader `0x21d50` и сохранение поля `+0xa4` при `INTO`. Rust-тест
повторяет бюджетную пару и разрешает tag `26` в projection INTO guard, оставляя
теги `1`, `17` и `30` явными границами. Native-векторы бюджетного шага
подтверждают текущие ставки `+0x5dc/+0x5e0`, включая значения `0.2`/`0.4` у
потребителя tag 15, пустой результат `-0.0` и невырожденную пару исходных
устройств tag 19/tag 15 при `dt = 0.375`; Rust-тест повторяет поля этой пары
на синтетической таблице. Rust переносит class-9 rate/update и шестизначную
adjustment `0x25a90`, tag-26 rate/update и setter selector `0x500`, общую
default callback-пару `0x21860/0x21890`, а также category map только для current
descriptor tags `0..=34`. Остальные ещё не описанные специализированные
callbacks остаются явными ошибками.
Лицензированный `min_l_n1.dat` содержит исходные factory/current tags
`[19, 19, 9, 15, 12, 12, 13, 13, 26, 25, 21]`. Публичный API оставляет всю
таблицу без изменений при не конечном интервале. Для конечного интервала
ignored Rust-тест проходит budget по всем 11 строкам без фильтра. При `dt = 0.5`
обе output rates равны `0x3c23d70a`, первые два множителя tag `19` равны
`0x3f7fd70a`, остальные множители остаются `1.0`, а добавка tag `26` остаётся
нулевой. Эта проверка подтверждает только CPU-проекцию реальной таблицы; она
не запускает native полный mission tick и не подключает Control clock.
Успешные бюджетные native-векторы используют синтетические
NDP/Node38-строки и подтверждают локальные переходы и порядок вызовов, а не
полный Control tick на миссии. Прямые oracle-вызовы `0x11220` для одиночной
строки используют `updateEffects = false`, что исключает ветвь Control FX и
`0x11af0`; в отдельном сценарии класса `9` `0xfca0` возвращается сразу после
смены видимости, поэтому связанное с ним движение не проверено. Хотя у строки
Control выставлен flag `0x102`, слово флагов ANI `+0x14` и производные байты
`+0x111..+0x113` изначально равны нулю. Вызовы AniMesh `0x93c0` и `0xa2a0` обновляют производную геометрию и
видимость, это отдельная непроверенная граница, а не FX callbacks. Распределение
и бюджетный шаг вызывают обязательный `0x11130(root, true)`, но их проверенные
векторы имеют одну строку без смены стадии; они не доказывают исполнение FX или
`0x11af0`. Бюджетная
часть активного `0xbcf0` исполнена на синтетическом хосте класса `10`:
при периоде `500` и нулевом RNG проверены пропуск до deadline и на равенстве
`437.5`, затем ресурсный `dt = 0.5` при времени `500`. На том же ограниченном
хосте без устройств seed `0x12345678` подтверждает новые RNG draw при временах
`500`, `501`, `502`, `503` и ресурсные clocks `0`, `0`, `502`, `502`: deadline
пересчитывается при каждом принятом активном вызове. Проверены также точное
равенство с ненулевым RNG, расход RNG при принудительном `+0xd4` и сохранение
RNG/счётчика в неактивной ветви. Движение и очереди исключены условиями этих
векторов; активация `+0xe0` задавалась явно. Отдельный native-вектор класса `4`
вызывает `0x314f0` через синтетический owner `+4` и переходник `0x31ae0`.
Он сравнивает raw `f32` слова абсолютных часов и baseline, вычисленный до
округления `u32` в `f32`: для `16777217` это `0x4b800000/0x4b7fff9d`, для
`16777219` — `0x4b800002/0x4b7fff9f`. Последовательность `100`, `101` оставляет
`+0xe4` нулём после первого вызова, поэтому старое условие `+0xe4 == 0` добавляет
начальную команду повторно: счётчик `+0x370` переходит с `1` на `2`. Это путь
тестового интерфейса owner `+4`; статическая цепочка AniMesh `Agent+0x158`
ведёт к primary Control owner slot `+0x08` напрямую в `0x314f0`. Геометрические
callbacks подставлены явно, матрица identity и масштаб единичный, таблицы
устройств и shapes пусты. Вектор подтверждает ABI/арифметику часов, но не
реальную матрицу и callbacks из миссии или полный Unit DAT loader.

Источник времени и доставка прослежены статически:
World3D RVA `0x6bf0` вычисляет часы из `timeGetTime()` с игровым смещением и
поправкой на паузу, затем выполняет первый обход `6/1`, шаг мировой физики и
второй обход `6/0x1c`. При создании объекта World3D RVA `0x7cb0` вызывает slot
`+0x38` с literal-null payload в `0x7d1a`, а затем передаёт в тот же slot DWORD
из `DATWorld+0x32a38` в `0x7e6e`; RVA `0x7ea0` повторяет передачу часов в
`0x80a9`. Setter RVA `0x5140` записывает этот DWORD в `DATWorld+0x32a38`.
AniMesh RVA `0x2ff0` получает для `Agent+0x158` Control base owner по QI selector
`0xa`, после чего `Agent` RVA `0x1a80` dispatch-ит событие `4` через его primary
slot `+0x08` прямо в `Control.dll+0x314f0`. Это и отдельный синтетический вызов
через owner `+4` — подтверждённые интерфейсные пути, но пока не единая трасса
игрового старта. Control RVA `0x7830` численно преобразует unsigned DWORD в
`f32` перед primary slot `+0x58`; фабрика выбирает RVA `0xcbb0` для класса `9` и
RVA `0xbcf0` для остальных. Статические вызовы не подтверждают их исполнение на
миссии: связывание реальных интерфейсов, активация устройств и shapes, остальные
ветви `0xbcf0` и
автоматическое изменение provider через clock и бюджет Rust остаются открытыми. Источник контактного коэффициента прослежен статически,
но не исполнен. Подробные векторы и статические границы приведены в
[техническом подразделе о provider-состоянии Control](script-vm.md#изменение-provider-состояния-control).

Отдельный API `advance_loaded_mission_resources` принимает явное время очереди
и обновляет представленные поля `CurrentOre`, строк распределителя и Control
selector `1`. Тот же расчёт вызывают `step_headless` и `frame` с явным
clock очереди; подготовка ресурсов и мировой шаг завершаются атомарно.
Оконное приложение пока использует static preview. Этот путь не обновляет
Control amount, профили или special object-state gate. Если обязательный
запрос позднего объекта не поддержан, транзакция возвращает ошибку без применения
подготовленных изменений. AutoDemo-тест подтверждает связь настоящих профилей с
этим шагом и проверяет откат при ошибке ресурсов или мировой очереди,
но не полный паритет миссии; отдельный aggregate getter Behavior RVA
`0xa490` в oracle не исполнен.

Behavior selectors `0x1002` и `0x1005` используют значения выбранного
профиля из `behpsp.res`, разобранного до создания нового мира. `0x1002` складывает
только текущие descriptor tag `26` запросы `0xe00`, затем применяет
`Transfer_Ore_OffBoard`; `0x1005` возвращает `Transfer_Power_Out`. Это начальный
снимок профиля и provider-строк. Полная загрузка сохраняет результат у
`ObjectHandle` и возвращает
ошибку, если известный код класса не имеет корректной записи; класс,
отсутствующий в таблице выбора, сохраняет начальные значения конструктора.
Preview и объекты без полного Unit DAT не получают профильное состояние.
Native oracle подтвердил соответствия кода класса выбранной записи, разбор
`.var` и применение второй области данных;
оригинальный aggregate getter Behavior RVA `0xa490` остаётся статически
исследованным, но не исполнен в oracle.

В x86 oracle при x87 control word `0x007f` проверены порядок, signed zero,
отрицательные входы, расширенный промежуточный диапазон и subnormal return.
Rust запрос ограничивает себя normal-or-zero значениями, поэтому явно отклоняет
промежуточные случаи, где результат выходит за поддерживаемый диапазон f32,
даже если позднее умножение вернуло бы его в диапазон. Это ограничение
поддержки Rust snapshot, а не неверный native-результат.

В Unit DAT fixture `UNITS/BUILDS/MINE/min_l_n1.dat` проверена реальная связка
`fr_l_mine.ctl` + `fr_l_mine.ndp`: tag `26`, ключ `2` в локальной NDP таблице
из `22` строк, коэффициент `1.0`. Игнорируемый runtime-тест выполняет полный
загрузочный путь, подтверждает root/`EXTO` размеры `22` и `4` и итоговые `25`
provider rows после пропуска первого `EXTO` row. Он вызывает Rust query по
восстановленному native правилу адресации и получает начальное значение `1.0`;
getter оригинальной DLL здесь не исполняется. Это не запись живого
resource-device значения во время игры.

### Профиль владельца Control из CTLD

Общий проход оригинального `Control.dll!FUN_1000fac0` (RVA `0x0fac0`, SHA-256
`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) проверен
прямым x86-вызовом под control word `0x007f` на synthetic backing. Оригинальный
`AniMesh.dll` query `0x51f0` и методы диапазона component ID `0`
`0x5780/0x57c0` участвуют в векторе; Rust воспроизводит его raw output bits и
отдельные cache, order, clamp и signed-zero случаи.

Для обычной начальной загрузки входной масштаб единичный. Конструктор модели
AniMesh RVA `0x68a0` задаёт `Model+0x158/+0x15c/+0x160 = 1.0`;
`Agent+0x158` хранит указатель на отдельный Control. Перед Control event `4`
World3D проходит Agent event `0`: AniMesh RVA `0x1a80` вызывает базовый return
`0x17df0` и передаёт event `4/null` модели, FX, CollManager и CollObject.
Проверенные ветви модели `0x75b0/0x6fc0`, Effect `0x3d30` и CollManager
`0x1ce00` не меняют масштаб. CollObject получает событие через основной
интерфейс `0x3c2fc`, slot `+0x08 -> 0x1f530`: он кэширует host-интерфейсы,
а необязательный вызов CollManager `0x1c330` сохраняет только указатель
`CollObject+0x20` в `CollManager+0x3c`. Поэтому FAC0 получает `[1, 1, 1]`.
Отдельные пути `AddNewObjectToGame`/mirror и последующие placement/tick остаются
за этой границей. В synthetic x86-векторе scales `[2,3,5]` заданы отдельно.
Подробная привязка интерфейсов приведена в [разборе Script VM](script-vm.md).

Смысл `Slot68 +0x30/+0x34`, tag-27 cache DWORD, owner accumulators `+0x530`,
`+0x534`, `+0x538` и результата mutable word `26` не имеет доказанных единиц
измерения. Неизвестные слова остаются raw; их нельзя подписывать как массу или
площадь. Synthetic x86 vector напрямую записывает scales `[2, 3, 5]` в
`AniMesh +0x158/+0x15c/+0x160`; это не значения обычной миссии. Проверка
стандартных `ArealMap`/`World3D` и AniMesh callback-ветвей до FAC0 подтвердила,
что setter не вызывается, поэтому полный начальный loader использует defaults
конструктора `[1, 1, 1]`. Конкретный отдельный путь World3D `AddNewObjectToGame`
и mirror-варианты передают свой transform-вектор setter-у; это отдельная
граница, как и более поздние placement/tick.

Полный Rust loader теперь выполняет FAC0, затем FCA0 при построении
`build_control_device_projection_with_class`. `MissionControlOwnerProfile::load_projection`
сохраняет отдельный результат FAC0, а `fca0_projection` — статус следующего
прохода. FCA0 проверяет класс **владельца** `owner +0x50`: класс `9` сразу
возвращает неизменённую копию; это не условие по device factory tag `9`. Любой
известный класс, отличный от `9`, включая `0`, проходит общий расчёт. В Rust
`MissingNativeControlClass` означает, что проекция не восстановила метаданные
класса, а не то, что оригинальная DLL не содержит класс. `Fac0Unavailable`
применяется только к не-классу-9 ветви, потому что класс `9` выходит до проверки
FAC0.

FCA0 суммирует selector `0xe00` в обратном порядке по устройствам с текущим
descriptor tag `5`. Изолированный x86-вектор исполняет оригинальный reader
`0x21d00` и FCA0. Статическая проверка двух factory vtables подтверждает общий
reader `0x21d00` и setter `0x21d50` для tags `5`/`26`; provider getter `0x0dc40`
использует `owner +4`, а canonical `QueryInterface(0x204)` задаёт
`owner +0x38 -> owner +0x0c`.
В каноническом constructor/event-4 пути scalar `+0x1a8` и means `+0x354/+0x358`
равны `1.0`. На исходном Control.dll с SHA-256
`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e` FCA0
подтверждена по RVA `0x0fca0` при x87 control word `0x007f`. Слова
`[0,1,2,6,7,8,9,10,11]` в canonical-default векторе имеют биты
`40200000 c0a00000 40c00000 3f800000 40000000 41200000 41e70000 c22d4000 40e70000`.

Лицензированный тест `full_load_builds_effective_control_device_table_for_mine_unit_dat`
настоящего `min_l_n1.dat` теперь проверяет class `3`, `fca0_projection = Ok(())`,
11 устройств и все 25 provider rows. Его девять target words
`[0,1,2,6,7,8,9,10,11]` равны
`40000000 40000000 40000000 00000000 00000000 00000000 00000000 00000000 00000000`;
word `26` после FAC0 остаётся `0x7f7fffff`, а оригинальный блок, FAC0 агрегаты
`0x470833fc/0x4897e712/0x4d9452cb` и 25 значений строк сохраняются. Это Rust
full-load результат на оригинальных ресурсах, а не сравнение полного native
Unit DAT loader-а или gameplay. Rust helper поддерживает только конечные входы
и промежуточные значения домена `normal-or-zero`; прочие битовые случаи остаются
вне заявленного диапазона.

Полный динамический жизненный цикл после начальной загрузки не подтверждён:
поздние изменения owner scalar/means, activation, игровые часы, Control tick и
placement не сведены в одну проверенную трассу и не включены в Rust-проекцию.
Отдельные constructor, setter и loader-пути уже прослежены; физические единицы
слов профиля и накопителей остаются неизвестны. Для закрытия границы нужны
динамическая трассировка и сравнение полного Unit DAT load с оригинальным
loader-ом при одинаковых ресурсах и условиях.
Подробные RVA, QI/provider layout, арифметика и пределы векторов приведены в
[описании изолированного прохода FAC0](script-vm.md#изолированный-проход-fac0)
и [разборе FCA0](script-vm.md#изолированный-проход-fca0).

## DirectPlay wire

DirectPlay lifecycle и имена игровых messages известны. Wire framing, payload
schema, reliability flags и `netZipData` требуют записи обмена двух
оригинальных клиентов.

Native interoperability подтверждается только успешным обменом original client
<-> compatibility implementation в обе стороны.

## Shell, HUD, шрифты и локализация

Граница shell подтверждена exports `createShell/getIShell`, `IGUIServer`,
верхнеуровневым UI-pass и файлами `ui/*.cfg`, `DATA/TextRes.cfg`,
`gamefont.rlb` и `sprites.lib`. Для полной GOG-сборки подтверждены раздельные
форматы: `gamefont.rlb` читается общим RsLi reader, но его native consumer этим
не установлен; для меню подтверждена цепочка `menu_resources.cfg` → NRes
`font.lib` → native lookup `MENU_FONT` с получением реального font-объекта.
Reader `fparkan-font` разбирает 20-байтовый Tfnt prefix, 256 записей фиксированного
шага и передаёт вложенный Texm общему reader-у. Native consumer подтверждает
два целочисленных параметра, per-byte spacing и signed advance; смысл трёх glyph DWORD
и поля заголовка по `0x0c` пока не установлен. Это не реализует выбор шрифта, текстовый
layout или glyph drawing. `menu_resources.cfg` и шесть вариантов
`MENU_FONT`/`GAME_FONT` сопоставлены с NRes-записями в
[разборе shell и шрифтов](ui-shell.md). Также остаются открытыми выбор dimension
на фактическом дисплее `1280x1024`, widget tree, layout rules, sprite command
semantics, focus/navigation и HUD state machine.

Закрывающий эксперимент: сопоставить оставшиеся детали `shell_ctrls.cfg`,
`cursor.cfg`, `game_resources.cfg` и `hq.cfg` с GUI object factories и снять
command/event captures для меню, HUD, briefing и диалогов.

## Research, economy and properties

Для GOG `ArealMap.dll` SHA-256
`a25f9254ebb339d70e2e07c8121950191e9584ca0858d8e9c2e2b6c671edf6ea`
`CalcFullResearchCost` по RVA `0x16280` имеет подтверждённый ABI
stdcall `[context, candidate, out1, out2]`, `RET 0x10`, и восстановленный
алгоритм для одного candidate tree: zero-kind subtree pruning, direct preorder,
общая дедупликация, ordered DFS по `TRF2`/`TRF3`, raw gates из `TRF1` и
последовательное `f32` сложение. Принятый набор из 23 synthetic native cases
включал Calc и два AI predicate; для контролируемых сравнений x87 word был
установлен в `0x007f`. У набора synthetic context, поэтому он не измеряет
реальную миссионную стоимость.

Отдельный прямой вызов chooser-а `ai.dll` SHA-256
`c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc`
`FUN_10010f90` (RVA `0x10f90`) прошёл 3 guard-case и frozen-матрицу из 15
проверок при заданном порядке кандидатов. Тот же код использует конструктор RVA
`0x10480`, parser первого Unit DAT дерева RVA `0x102c0` и предикаты RVA
`0x115f0`/`0x11530`. Wrapper Handler(43) по RVA `0xd54a` и catalog loader
`0x104e0` не вызывались. Эта матрица не подтверждает полный Handler(43),
миссионный источник списка или штатный порядок AI-каталога.

`fparkan-assets` декодирует используемые NRes chunks, сохраняя сырые TRF0 words
и непрозрачные данные. Native cost outputs сопоставлены только с двумя raw
words: out1 складывает TRF0 word 1 и подписан как ore, out2 складывает word 0
и подписан как power. Смыслы остальных полей полного 32-byte callback record
не установлены. Non-ASCII case folding research keys также остаётся открытым;
Rust явно возвращает unsupported для таких сравнений.

Rust `ResearchCandidateSet` получает ordered entries, а TRF-context передаётся
отдельно. Ошибка чтения VFS, неверный Unit DAT magic или неполное первое
дерево пропускают entry; missing key даёт false predicate. Cost вызывается и
для пустой таблицы: он возвращает `EmptyResearchTable`, после чего этот entry
пропускается с сохранением второго status.
Другие ошибки таблицы и
`UnsupportedNonAsciiLookup` остаются явными Result-ошибками. Уже записанные
statuses и выбранный индекс на ошибке не откатываются; это политика Rust API,
не доказательство полного native error ABI.

Два Rust-предиката повторно обходят один декодированный tree с той же
immutable TRF-таблицей. Общий helper может остановить второй проход при первом
ложном флаге; native RVA `0x11530` продолжает обход и накапливает
неиспользуемые float sums. Первый проход уже проверил ключи всех enabled
компонентов, поэтому подтверждается только эквивалентность state/selection
для такого входа, не идентичность callback trace или вычисления этих sums.

Статический перенос владельца исследовательского контекста подтверждён по трём
GOG-модулям. В `iron3d.dll` (SHA-256
`d1dc4ea8535e2069b0a05c9e8be2724dd438ba44cca7a83007d8b2e50f9e35fa`)
`FUN_1005ff40` (RVA `0x5ff40`) передаёт индекс клана в `FUN_100392e0` (RVA
`0x392e0`), где он сохраняется в `row+0x1c` и копируется в `descriptor[0]`.
Thunk RVA `0xcd0a0` ведёт к `World3D!GetNetPlayerNum` (RVA `0x9110`), а RVA
`0xcd08e` — к `World3D!AddNewObjectToGame` (RVA `0x8310`); SHA-256
`World3D.dll`: `17e4a3089b2583a8cf2356c9db0390b1aba138356a09130d79b4e7e4791da61e`.
Вызов getter-а без аргументов завершается обычным `RET`; его результат становится
arg1 следующего вызова. `AddNewObjectToGame` принимает девять DWORD, включая
указатель на descriptor в arg9, и очищает стек через `RET 0x24`. RVA `0x83e9`
читает arg9; ветвь class `0xb`/QI `0x502` на RVA `0x853e` загружает
`descriptor[0]` и передаёт его в слот `+0x5c` на RVA `0x8544`;
`MisLoad.dll` (SHA-256
`c607762bb67db14ca530927c8e1347339b62b0a163ac90c708ee83142292e2bf`)
`FUN_10002a30` (RVA `0x2a30`, `RET 8`) записывает его в `inner+8`. TMA tag
`row+0x20` ограничивает число вызовов AI slot `+0x38`, но не задаёт владельца.

Создание AI не фильтруется по наличию сценарного пути. В `iron3d.dll` SHA-256
`d1dc4ea8535e2069b0a05c9e8be2724dd438ba44cca7a83007d8b2e50f9e35fa`
`FUN_1005ff40` (RVA `0x5ff40`) проходит записи кланов и вызывает для каждой
`FUN_100392e0` (RVA `0x392e0`); в `ai.dll` SHA-256
`c19cd6cd31cd2896f8c4ba0f0e700dd3408aec8182daaf4863d98a7d233a2abc`
`CreateSuperAI` (RVA `0xf710`) выделяет AI и вызывает конструктор по RVA
`0x1000` без проверки пути сценария. Создание исследовательского контекста
следует за успешным созданием AI и требует включённого флага создания
исследований и непустого `second_resource.path` до первого NUL. Переданный в
`descriptor[0]` индекс клана, а не `second_resource.tag`, задаёт владельца;
тег остаётся счётчиком начальных вызовов AI slot `+0x38`.

В Rust эта граница представлена только загрузкой таблиц. Полный
`load_mission` требует явный `MissionStartupInput { queue_time_ms,
research_creation_gate }`; этот флаг не выводится из `MissionMode` или имени
пути. Если флаг равен `true`, загрузчик проходит по существующим
`MissionAiStartupState` всех TMA-кланов, в том числе без сценарного пакета,
читает их `second_resource.path` до первого NUL и отклоняет не-ASCII путь.
Пустая строка пропускается; выключенный флаг и статический preview не читают
TRF. На каждого
владельца сохраняется отдельный `ResearchTrfDocument` с нормализованным путём,
даже когда разные кланы указывают на один файл. Обычные тесты на искусственных
данных проверяют владение у кланов со сценариями и без них, повторное
декодирование, пропуски, ошибки и откат; игнорируемая проверка оригинальных
ресурсов связывает реальные `Campaign.00/Mission.01` пары путей с индексами владельцев.
Rust пока сохраняет только декодированные данные и связь с владельцем: он не
создаёт полный исследовательский контекст, не строит AI-каталог и не исполняет
`Handler(43)`.

Нативный metadata loader нельзя считать простым копированием таблицы. В GOG
`Behavior.dll` (SHA-256
`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`) selector
`0x204` по RVA `0xa490` обновляет сохранённое float-значение `+0x678`. В GOG `Control.dll`
(SHA-256 `bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`)
selector `0x36` проходит цепочку RVA `0x31af0` → `0xe6c0` и записывает в общую
ячейку памяти по RVA `0x434bc`; selector `0x91` выполняет одноразовую
инициализацию, только если функция ещё не выполнила её. В Rust пока хранятся
только декодированные TRF-данные и сведения о владельце: эти побочные записи,
очередь и lifetime контекста не моделируются.

Открыты runtime-выполнение Handler(43), создание и lifetime research context,
включение factory-цепочки в полный штатный startup миссии, построение AI
candidate list и штатный порядок кандидатов, live x87 policy,
inventory/economy transitions и точная типизация всех 16-byte TMA property
values. Strict ore comparison и выбор первого кандидата при равенстве известны
только для supplied-order chooser. Ignored acceptance проверяет реальные Part 1
AI DAT prefix и `scream.trf`, но byte-sorted порядок не заявляется как native
catalog order и не сравнивает цену с вызовом chooser-а в mission context.

Для проверки оставшихся границ нужно на живой миссии установить, проходит ли
штатный `Init` по статически восстановленной передаче owner, зафиксировать
создание и lifetime исследовательского контекста и сравнить порядок кандидатов
и cost outputs оригинала с Rust. Покупки, inventory transitions и typed
property schema требуют отдельных контролируемых исследований.

## Rare branches

- `Land.map poly_count > 0`;
- RsLi adaptive methods `0x080` и `0x0A0`;
- Texm formats 556 и 88;
- FX opcode 6;
- редкие material flags и MSH auxiliary streams.

Такие ветки реализуются по бинарному коду и synthetic tests, а статус
corpus-verified получают только после реального файла или runtime trace.