diff options
Diffstat (limited to 'docs/tomes')
| -rw-r--r-- | docs/tomes/03-resources.md | 11 | ||||
| -rw-r--r-- | docs/tomes/06-behavior.md | 209 |
2 files changed, 190 insertions, 30 deletions
diff --git a/docs/tomes/03-resources.md b/docs/tomes/03-resources.md index a11ad55..a349a79 100644 --- a/docs/tomes/03-resources.md +++ b/docs/tomes/03-resources.md @@ -477,8 +477,15 @@ struct UnitDatRecord112 { При построении mission prototype graph FParkan сохраняет для каждого root упорядоченный список этих raw records. Список передаётся в -`MissionObjectDraft` с исходными `kind`, `parent_or_link`, description и tails; -эти данные пока не объединяются в таблицу эффективных устройств Control. +`MissionObjectDraft` с исходными `kind`, `parent_or_link`, description и tails. +Во время полного mission load runtime использует дерево и подготовленные CTL +resources, чтобы построить для такого объекта упорядоченную базовую таблицу +Control: корневые строки добавляются, дочерний `INTO` может обновить выбранную +строку или добавить записи при sentinel `-1`, а `EXTO` добавляет строки с +переведёнными ключами глобальной MSH-иерархии. Результат хранит исходный factory +tag и provenance; неизвестные tag-specific callbacks он не выполняет. Preview +режим эту таблицу не строит, а неполная typed-record list оставляет состояние +явно unavailable. Каждый graph edge от `UnitDatRoot` к effective component и далее к его MSH dependency также несёт `unit_component_index`. Это индекс исходной записи в diff --git a/docs/tomes/06-behavior.md b/docs/tomes/06-behavior.md index 9d7b01e..bcb7320 100644 --- a/docs/tomes/06-behavior.md +++ b/docs/tomes/06-behavior.md @@ -593,6 +593,28 @@ parent ID через Control IID `0x202`, virtual slot `+0x44`, только е нужно проверить это поведение явно. `EXTO` проходит отдельную ветвь, поэтому это правило нельзя распространять на все registry types. +Ветка `EXTO` заполняет другие поля. В `FUN_10003760` RVA `0x3760` и mount +`C4`, и target `C8` сначала равны `-1`. Ветка `EXTO` вычисляет mount и +записывает его только в `C4`; `C8` остаётся `-1`. Поэтому Control добавляет +все typed records такого компонента в конец общей таблицы. Raw +`parent_or_link` здесь выбирает mount-узел, а не строку Control. + +`AniMesh.dll` (SHA-256 +`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`) +собирает глобальную нумерацию MSH-узлов: обычная корневая модель добавляет все +`N` узлов, `EXTO`-дочерняя модель добавляет `N - 1`, начиная со своего узла `1`, +а `INTO`-компонент не добавляет узлов. `FUN_1000a460` (RVA `0xa460`) выполняет +эту загрузку MSH; `FUN_10005780` (RVA `0x5780`) находит первый глобальный узел +с заданным component ID. Если у `EXTO`-модели только один узел, она не добавляет +глобальных узлов, и поиск первого узла возвращает `-1`. + +При добавлении `EXTO` Control отдельно переводит ключи CTLD в пространство +глобальной MSH-иерархии: нулевой ключ заменяется mount-узлом `C4`; ненулевой +ключ сдвигается относительно первого глобального узла компонента только при +`C4 != -1`. Например, если компонент начинается с глобального узла `22`, его +исходный ключ `1` становится `22`. Этот ключ выбирает модельный узел, а не +строку Control. Записи корня остаются в исходном виде. + ### Как Control добавляет и переопределяет устройства В `Control.dll` (SHA-256 @@ -609,6 +631,19 @@ override path применяет первую typed record и не добавл путь `0x20800`, поэтому такой результат парсера сам по себе не доказывает отказ оригинального loader-а и не позволяет объявить Rust merge полным. +FParkan строит базовую проекцию этой таблицы во время полного mission load для +объектов с Unit DAT. Корневые typed records добавляются в исходном порядке; +`EXTO` тоже добавляет все свои записи с remapped MSH-ключами; `INTO` обновляет +одну строку по `C8`, а при sentinel `-1` добавляет весь список. Preview таблицу +не создаёт. Проекция хранит исходный factory tag, текущий typed record и их +provenance, но не исполняет все tag-specific callbacks и не заменяет полный +Control runtime. Лицензированный `UNITS/BUILDS/MINE/min_l_n1.dat` подтверждает +10 исходных устройств, четыре `INTO`-override по индексам `0..3` и добавление +одной дочерней записи `EXTO` с ключом `22`, всего 11 устройств. Это результат +Rust full-loader теста на оригинальных ресурсах. Ветви C4/C8 и добавление +`EXTO` подтверждены статически по native ASM; отдельный native full-load oracle +для всей таблицы не запускался. + Для tag `19` фабрика создаёт объект с его исходными классом и vtable. Базовый конструктор `FUN_100218b0` задаёт multiplier `+0x4c = 1.0`. Override через `FUN_1002d890` вызывает у выбранного объекта vtable slot `+0x1c`, то есть @@ -621,16 +656,55 @@ override path применяет первую typed record и не добавл сбрасывают их. Поэтому «переопределение» здесь означает обновить часть данных того же устройства, с ограничениями конкретного метода. +Native x86 oracle для тех же GOG DLL выполняет конструкторы и этот общий setter +на уже созданных получателях factory tags `9`, `15`, `19` и `25` (размеры +объектов `0x120`, `0x98`, `0x94` и `0xa4`). У всех проверенных vtable slot +`+0x1c` указывает на RVA `0x21d50`; тест подтверждает, что override сохраняет +существующий слот, класс/vtable, ключ, component ID и multiplier `2.5`, копируя +новые коэффициенты. Slot `+0x24` у tag `9` указывает на отдельный обработчик +`0x25600`, а у остальных трёх — на no-op `0xbcd0`. Tag `9` проверяется с +нулевым pointer `+0x3c` и записью без map rows: FX host намеренно не подключён, +поэтому его поведение этим опытом не подтверждено. + Статический разбор глобального 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 @@ -658,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 @@ -668,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 |