1 files changed, 136 insertions, 28 deletions
diff --git a/docs/tomes/06-behavior.md b/docs/tomes/06-behavior.md
index 0bd00df..bcb7320 100644
--- a/docs/tomes/06-behavior.md
+++ b/docs/tomes/06-behavior.md
@@ -668,14 +668,43 @@ Native x86 oracle для тех же GOG DLL выполняет конструк
 
 Статический разбор глобального Control interface показывает aggregate getters
 `1/2` (`FUN_1002b410`, RVA `0x2b410`) и setter `1` (`FUN_1002ba30`, RVA
-`0x2ba30`) для устройств tag `19`. Для конечных значений getter `1` вычисляет
-`sum(base * multiplier) / sum(base)`, а getter `2` — `sum(base)`. При встрече
-отрицательного base selector `1` сразу возвращает `1.0`, а selector
-`2` — этот base. Если подходящих записей нет или сумма base неположительна,
-getter возвращает неуспех без записи результата. Setter пишет multiplier `+0x4c`
-только устройствам tag `19` с положительным selector-0 значением; пустой набор
-возвращает успех. Это вывод статического анализа для конечных входных значений,
-без отдельного native execution oracle для глобальных selectors.
+`0x2ba30`) для текущего descriptor tag `19`. Getter `1` складывает ответы
+виртуального selector `0x200` в числитель и selector `0` в знаменатель; getter
+`2` возвращает сумму selector `0`. Для обычного factory tag `19` эти ответы
+равны `coefficient * multiplier` и `coefficient`, то есть отношение сводится к
+`sum(coefficient * multiplier) / sum(coefficient)`. У factory tag `9` selector
+`0` умножает коэффициент на отдельное поле `+0x11c`, тогда как selector `0x200`
+использует коэффициент и multiplier; эта особая база меняет знаменатель.
+Обработчик factory tag `9` расположен в Control RVA `0x255c0`, а его конструктор
+RVA `0x25460` задаёт `+0x11c = 1.0`. При встрече отрицательного ответа selector
+`0` getter `1` сразу возвращает `1.0`, а getter `2` — этот ответ. Если подходящих
+записей нет или сумма базы неположительна, getter возвращает неуспех без записи
+результата. Setter пишет multiplier `+0x4c` только устройствам с текущим
+descriptor tag `19` и положительным selector-0 ответом; пустой набор возвращает
+успех. Фильтр использует **текущий descriptor tag**, который может измениться
+при `INTO`, а виртуальный вызов остаётся методом исходного factory-класса.
+
+Этот путь проверяется native x86 oracle на оригинальной `Control.dll` указанной
+выше: искусственные factory/descriptor пары `9`, `15` и `19` покрывают setter,
+отрицательные ответы, округление и тег `9` с scale `0.5`. Для factory tag `25`
+его vtable slot `+0x10` статически указывает на общий getter RVA `0x21d00`, но
+отдельный aggregate oracle этот класс не запускал. Rust хранит начальный scale
+factory `9` и предоставляет `query_loaded_mission_control_resource` для selector
+`1`/`2` и `set_loaded_mission_control_multiplier` для setter-а `1`. Вызовы
+сначала проверяют живой `ObjectHandle`, затем обращаются к таблице этого объекта
+из полной загрузки миссии. Синтетические тесты проверяют границы пустой таблицы,
+нулевого знаменателя, неподдержанных factory tags и чисел за диапазоном
+нормального `f32`; лицензированный тест сверяет реальные descriptor tags и
+получает для `min_l_n1.dat` сумму `16` и отношение `1` до setter-а.
+
+В этом API пока реализованы только getter selectors `1`/`2` и setter `1`.
+Отдельный native setter selector `17`, tag-specific методы прочих factory tags,
+их внешние эффекты и вызов из регулярного шага Behavior здесь не моделируются.
+Числа должны оставаться конечными и нормальными либо точным нулём; произведения
+и отношения за поддерживаемым диапазоном `f32` возвращают явную ошибку, а не
+подменяются нулём или `None`. При проверке диапазона Rust оценивает операцию в
+`f64`, затем выполняет её в `f32`; это ограниченная проверка диапазона, а не
+эмуляция полного x87 accumulator-а.
 
 Отдельная ветка того же GOG `AniMesh.dll` показывает, когда создаётся Behavior
 для host object. В `FUN_10002ff0` (RVA `0x2ff0`, SHA-256
@@ -703,8 +732,21 @@ Provider interface направляет selector `1` и ключ в Control RVA
 читается текущее type-1 значение выбранной строки. Затем selector умножает
 сначала provider на коэффициент, после чего на множитель: `provider * base *
 multiplier`. Коэффициент приходит из CTLD; NDP связывает ключ с описанной
-строкой, а текущее значение provider нельзя заменить предположением о состоянии
-мира.
+строкой. Native loader создаёт для этой строки отдельное runtime-состояние: у
+`Control.dll` (та же сборка, SHA-256
+`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`)
+`FUN_1000b240` (RVA `0xb240`) строит 11 слов строки provider и ставит её
+selector-1 поле `+0x14` в `1.0`. `FUN_10008b10` (RVA `0x8b10`) выбирает строки
+NDP, а `FUN_1000a100` (RVA `0xa100`) добавляет их в общую таблицу с шагом
+`0x2c`; getter `FUN_1000dc40` (RVA `0xdc40`) использует ключ устройства как
+индекс этой таблицы. Для корня загружаются все строки. `INTO` не добавляет
+строк, а примонтированный `EXTO` пропускает свою первую строку. Пустая
+таблица такого `EXTO` не содержит строки, которую native loader должен
+пропустить, поэтому Rust оставляет provider lookup недоступным; sidecar с одной
+строкой даёт пустой вклад. Если mount узел не разрешился, строки этого `EXTO`
+в таблицу не попадают. Это отдельная
+последовательность provider-строк: её длина берётся из NDP, она не дополняется
+до числа узлов MSH и не участвует во второй перенумерации ключа.
 
 Так этот селектор включён в цепочку добычи руды оригинала. В той же сборке
 `Behavior.dll` (SHA-256
@@ -713,29 +755,95 @@ multiplier`. Коэффициент приходит из CTLD; NDP связыв
 `FUN_100198e0` (RVA `0x198e0`) суммирует успешные запросы IID `0x204` с selector
 `0xe00`. В парной `Control.dll` выше `FUN_1002bb40` (RVA `0x2bb40`) для типа
 `0x1a` вызывает selector `0x300`, описанный в этом разделе. Затем Behavior query
-`0x1002` (RVA `0xa490`) умножает полученную сумму на текущее значение block
-`+0x820`, поле `+0x58` `Transfer_Ore_OffBoard` (имя — RVA `0x22e20`, default
-5.0 — RVA `0x22d90`; config selector 2 загружает блок через RVA `0x0a1a0`).
-Отдельный query `0x1005` (RVA `0xa490`) возвращает поле `+0x60`
-`Transfer_Power_Out` (имя — RVA `0x22e20`, default 100.0 — RVA `0x22d90`;
-setter — RVA `0xaa40`). Rust helper пока описывает один Control selector `0x300`
-при явно переданных входах; он не реализует эту сумму, Behavior-умножение или
-подключение к игровому циклу.
+`0x1002` (RVA `0xa490`) умножает полученную сумму на поле `+0x58`
+`Transfer_Ore_OffBoard` блока `+0x820`; отдельный selector `0x1005` возвращает
+`+0x60` `Transfer_Power_Out`. Имена регистрируются в RVA `0x22e20`, а конструктор
+RVA `0x22d90` задаёт начальные значения 5.0 и 100.0. Восемнадцать точных class
+codes выбирают записи `.var` из `behpsp.res`: например, `0x80000004` выбирает
+`prof_mine.var`, `0x80000002` — `prof_generator.var`, а три кода bunker-класса
+выбирают `prof_bunker.var`. Таблицу этих соответствий задаёт mapper
+`FUN_10008a80` (RVA `0x8a80`) в Behavior.dll SHA-256
+`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`.
+
+Установленные соответствия mapper-а:
+
+| Class flags | Запись `behpsp.res` |
+| --- | --- |
+| `0x80000004` | `prof_mine.var` |
+| `0x80000008` | `prof_storage.var` |
+| `0x80000002` | `prof_generator.var` |
+| `0x80000010` | `prof_plant.var` |
+| `0x80000040` | `prof_angar.var` |
+| `0x80000200` | `prof_mtp.var` |
+| `0x80000400` | `prof_institute.var` |
+| `0x80010000`, `0x80020000`, `0x80040000` | `prof_bunker.var` |
+| `0x80100000`, `0x80200000` | `prof_tower.var` |
+| `0x01002000` | `prof_trn.var` |
+| `0x01004000` | `prof_bld.var` |
+| `0x01008000` | `prof_war.var` |
+| `0x01010000` | `prof_hq.var` |
+| `0x01020000` | `prof_hero.var` |
+| `0x20000000` | `prof_animal.var` |
+
+У бинарной строки `.var` есть имя, индекс типа, размер и две области данных.
+Native parser RVA `0x49fa0` читает запись, binder RVA `0x49090` связывает её с
+зарегистрированным полем, а apply-loop RVA `0x49170` копирует в поле именно
+вторую область. В профиле используются точные C-string имена
+`Transfer_Ore_OffBoard` и `Transfer_Power_Out`; регистр учитывается, первый
+совпавший ряд побеждает. Rust ограничивает чтение исходной записи NRes её
+границами и сохраняет значения как исходные 32-битные слова у соответствующего
+`ObjectHandle`. Разбор профиля для полной миссии завершается до создания нового
+мира: отсутствие или повреждение профиля известного класса прерывает загрузку,
+не подменяя предыдущую миссию. Если mapper не знает class code, остаются
+конструкторские значения 5.0 и 100.0; это не догадка о неизвестном профиле.
+Preview не загружает профили.
+
+При вычислении `0x1002` native `FUN_100186b0` (RVA `0x186b0`) добавляет в список
+только текущие Control descriptor-и tag `26`, после чего
+`FUN_100198e0` (RVA `0x198e0`) суммирует их успешные `0xe00` запросы. FParkan
+делает то же для загруженной таблицы в её исходном порядке и затем умножает
+сумму на профильный `Transfer_Ore_OffBoard`. Записи tag `5`, `10` и `21` в общей
+таблице в этот список не попадают. Запрос `0xe00` проходит по ключу устройства
+в исходную provider-таблицу и пока поддержан только для текущего descriptor
+tag `26` с factory tag `26`; для него результат равен
+`provider * fixed_words[11] * multiplier`. Лицензированный тест загружает
+оригинальные CTL/NDP и полную миссию с этим Unit DAT. В установленном
+`min_l_n1.dat` class word равен `0x80000004`, поэтому исходный прогон выбирает
+`prof_mine.var`. Для проверки другого отображения второй прогон оставляет тот же
+TMA и компоненты, но во временном VFS заменяет слово класса заголовка DAT на
+`0x80000002`; это тестовая подмена, а не содержимое лицензированного файла.
+Профиль mine даёт `Transfer_Power_Out` 0.0 и `Transfer_Ore_OffBoard` 1.0;
+оригинальный профиль генератора — 10.0 и 0.0 соответственно. Для исходного
+tag-26 ряда получается `1.0` provider × `1.0` coefficient × `1.0` multiplier;
+профиль mine умножает эту сумму на `1.0`, поэтому selector `0x1002` возвращает
+`1.0`. Эти запросы используют начальные provider-значения после конструкторов,
+а не результаты живого игрового тика.
+
+Поведение provider-строк меняется и после загрузки: например,
+`Control.dll!FUN_10010f30` (RVA `0x10f30`) обновляет и ограничивает текущее
+значение, а соседние процедуры распространяют его между связанными строками.
+Эти изменения пока не отражены в Rust-снимке. Поэтому запрос Control `0xe00` и
+Behavior selector `0x1002`, который его суммирует, используют исходное состояние
+полной загрузки. Selector `0x1005` прямо возвращает загруженную ставку профиля.
+Ни один из них пока не исполняет Control tick или последующие изменения профиля.
 
 На x87 control word `0x007f` каждое умножение округляет мантиссу до 24 бит,
 но промежуточная степень может выйти за диапазон `f32` и вернуться в него при
-следующем умножении. Rust helper поэтому принимает явные текущие значения
-provider и multiplier, проверяет tag, ключ и строку NDP, сохраняет порядок
-операций, но поддерживает только конечные нормализованные значения или ноль на
-входе, промежуточном и конечном этапах. Остальные случаи за этим численным
-диапазоном он отклоняет; полный x87 accumulator здесь не эмулируется.
+следующем умножении. Native oracle проверяет такой порядок для getter-а
+`0x300`. Rust запрос сохраняет тот же порядок, но поддерживает только конечные
+нормализованные значения или ноль на входе, промежуточном и конечном этапах.
+Остальные случаи за этим численным диапазоном он отклоняет; полный x87
+accumulator здесь не эмулируется.
 
 Лицензированный тест на Unit DAT `UNITS/BUILDS/MINE/min_l_n1.dat` проходит через
-компонент `fr_l_mine.ctl` и sidecar `fr_l_mine.ndp`: у найденного tag-26
-дескриптора ключ равен `2` из `22` строк, а raw коэффициент — `0x3f800000`.
-Тест передаёт helper-у искусственные текущие значения `1.0` только для проверки
-записи и привязки ключа; этот Unit DAT не является наблюдением живого Control
-tick-а.
+`fr_l_mine.ctl` и `fr_l_mine.ndp`: у найденного tag-26 descriptor ключ равен
+`2` в своей записи, raw коэффициент — `0x3f800000`. Корневой NDP содержит 22
+строки, sidecar примонтированного `EXTO` — 4; в общую provider-таблицу входит
+25 строк после пропуска локальной строки `0`. Тест также сравнивает порядок
+всех source-row индексов с порядком строк самих sidecar таблиц. Он вызывает
+Rust query по восстановленному native правилу адресации, а не getter оригинальной
+DLL на полной миссии. Значение `1.0` подтверждает начальное состояние по native
+конструктору, но не наблюдение живого Control tick-а.
 
 ### Control system и physical model