diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/appendices/knowledge-boundaries.md | 108 | ||||
| -rw-r--r-- | docs/reference/tma.md | 12 | ||||
| -rw-r--r-- | docs/tomes/03-resources.md | 36 | ||||
| -rw-r--r-- | docs/tomes/06-behavior.md | 248 |
4 files changed, 387 insertions, 17 deletions
diff --git a/docs/appendices/knowledge-boundaries.md b/docs/appendices/knowledge-boundaries.md index 873497c..27cf74a 100644 --- a/docs/appendices/knowledge-boundaries.md +++ b/docs/appendices/knowledge-boundaries.md @@ -130,7 +130,7 @@ host construction phases. Не проверена другая лицензир непустым `Init`. Вызов `Behavior.dll!FUN_10019e80` (RVA `0x19e80`, SHA-256 `ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`) исполнялся на синтетических интерфейсах. Путь членства в реальных distributor-списках -теперь связан с полями TMA и Unit DAT: `World3D!CreateObject` передаёт selector +связан с полями TMA и Unit DAT: `World3D!CreateObject` передаёт selector и class word через дескриптор в Behavior (RVA `0x7e55`, `0x7e62`), а `Behavior.dll!FUN_10005e60` (RVA `0x5e60`) проверяет высокий бит registration key, AI и distributor. Selector из первого DWORD после имени ресурса выбирает @@ -169,6 +169,50 @@ Behavior (`Behavior.dll`, RVA `0x3600`) вызывает `World3D!stdGetGameMode с реальными интерфейсами ArealMap, нужными `FUN_10019e80`; полный Behavior tick flow и общий dispatcher событий также остаются открытыми. +Начальные свойства `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 class 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 и проверки режима/состояния. Обработчик выбора миссии @@ -203,6 +247,68 @@ CTLD и связанные resources структурно читаются, coun известны. Не названы все секции, shape types, coefficients и точный contact solver. То же относится к редким MSH auxiliary streams и части CTPT/NDPR flags. +Одна цепочка 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 `9`, `15`, +`19` и `25`: остаются прежними слот, ключ, ID компонента, множитель и класс, +а коэффициенты копируются из новой записи. Искусственный 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, а не +трактоваться как пустой список. + +Глобальные Control selectors `1/2` и setter selector `1` по tag `19` описаны +там же только по статическому разбору `Control.dll`; их вызовы отдельно не +исполнялись. Проекция полного mission load недоступна для неполного списка +typed records, Control resource у non-geometric prototype и некоторых +неразрешённых EXTO node mappings; preview и объекты без Unit DAT root её не +строят. Её соответствие полной загрузке игры для всех типов компонентов и +factory paths ещё не установлено. Не восстановлен и жизненный цикл множителя +`+0x4c` после конструктора и переопределения; также неизвестно, когда эти +объекты создаются при отложенной загрузке. + +Для `Control.dll` (SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) tag-26 +getter selector `0x300` восстановлен локально: RVA `0x21d00` читает provider по +ключу `fixed_words[1]`, затем умножает provider, CTLD coefficient `fixed_words[11]` +и поле объекта `+0x4c` именно в таком порядке. Rust helper принимает текущие +provider и multiplier извне; он не восстанавливает их жизненный цикл или весь +Control tick. В x86 oracle при x87 control word `0x007f` проверены порядок, +signed zero, отрицательные входы, расширенный промежуточный диапазон и +subnormal return. Helper ограничивает себя normal-or-zero значениями, поэтому +явно отклоняет промежуточные случаи, где результат выходит за поддерживаемый +диапазон f32, даже если позднее умножение вернуло бы его в диапазон. Это +ограничение поддержки Rust helper-а, а не неверный native-результат. + +В Unit DAT fixture `UNITS/BUILDS/MINE/min_l_n1.dat` проверена реальная связка +`fr_l_mine.ctl` + `fr_l_mine.ndp`: tag `26`, ключ `2` в таблице из `22` строк, +коэффициент `1.0`. Это не запись живого resource-device значения в миссии. + Закрывающий эксперимент: трассировать `LoadControlSystem`, `LoadPhysicalModel`, `CreateCollManager` и создание collision objects; связать каждый изменяемый field с созданным shape, contact или реакцией на движение. diff --git a/docs/reference/tma.md b/docs/reference/tma.md index 2a84d6d..8eb6f66 100644 --- a/docs/reference/tma.md +++ b/docs/reference/tma.md @@ -92,3 +92,15 @@ slot `+0x40` в путь выбора AI в Behavior. Поэтому Rust сох `Property` состоит из четырёх raw `u32` и имени. Typed views разрешены только для доказанных property names и consumers. + +Для свойств объекта `MisLoad.dll!FUN_10003ab0` (RVA `0x3ab0`) переставляет +дисковые слова в runtime-запись, а `FUN_100040b0` (RVA `0x40b0`) проходит её +таблицу в порядке runtime-дескрипторов. Поиск имени учитывает длину и байты с +точным регистром и использует первое совпадение. В подтверждённом пути +дисковое `raw_value[1]` становится первым DWORD аргумента setter-а, поэтому +значение передаётся как биты, без промежуточного float-преобразования. +Например, Behavior регистрирует `CurrentOre` под кодом `5`; его setter кладёт +полученные биты в основное слово свойства `0x02000100`. `MaximumOre` с кодом +`4` читает дополнительное слово той же записи, а setter этого дескриптора +ничего не меняет. Подтверждение классов и native getter/setter находится в +[главе о Behavior](../tomes/06-behavior.md#начальные-свойства-запасов-руды). diff --git a/docs/tomes/03-resources.md b/docs/tomes/03-resources.md index 29fef77..a349a79 100644 --- a/docs/tomes/03-resources.md +++ b/docs/tomes/03-resources.md @@ -448,21 +448,28 @@ struct UnitDatRecord112 { char archive_name[32]; // +0x00 char resource_name[32]; // +0x20 uint32_t kind; // +0x40, в корпусе всегда 1 - int32_t parent_or_link; // +0x44 + int32_t parent_or_link; // +0x44, context-dependent local index char description[32]; // +0x48 uint32_t tail0; // +0x68, opaque - uint32_t tail1; // +0x6C, opaque + uint32_t tail1; // +0x6C, immediate_child_count }; #pragma pack(pop) ``` Во всех проверенных records `archive_name == "objects.rlb"` и `kind == 1`. -Поле `parent_or_link` встречается как `-1`, `0`, `1` и другие небольшие индексы -и связывает компоненты составного unit; точная предметная классификация ссылки -ещё не закрыта. `description` -- человекочитаемое описание компонента. В Части 2 -есть поля `description[32]`, полностью заполненные без NUL; это валидная bounded -string длиной 32 байта. Требование обязательного terminator применяется только -к полям, где оно доказано форматом. `tail0` и `tail1` нельзя нормализовать. +`tail1` задаёт `immediate_child_count` — число непосредственных дочерних +записей при построении дерева Unit DAT; оно не opaque. Поле `parent_or_link` +встречается как `-1`, `0`, `1` и другие небольшие индексы. В подтверждённой +цепочке Unit DAT → AniMesh → Control оно становится локальным индексом. Для +`INTO` индекс задаёт устройство Control относительно первого устройства +родительского компонента, а `EXTO` обрабатывается отдельной ветвью. Поэтому +поле нельзя трактовать как универсальный parent ID или одинаковую ссылку для +всех registry types. Детали передачи описаны в [главе о Behavior и Control](06-behavior.md). +`tail0` сохраняется как raw DWORD без установленной семантики. `description` -- +человекочитаемое описание компонента. В Части 2 есть поля `description[32]`, +полностью заполненные без NUL; это валидная bounded string длиной 32 байта. +Требование обязательного terminator применяется только к полям, где оно доказано +форматом. Проверено 425 файлов / 5 219 records Части 1 и 676 файлов / 8 145 records Части 2. Все соответствуют формуле размера, `kind == 1` и @@ -470,10 +477,15 @@ string длиной 32 байта. Требование обязательног При построении mission prototype graph FParkan сохраняет для каждого root упорядоченный список этих raw records. Список передаётся в -`MissionObjectDraft` без преобразования `kind`, `parent_or_link`, description -или tails в предполагаемые роли. Так runtime уже располагает исходными данными -составного unit для будущих Control/physics/AniMesh consumers, но не выдаёт -структурное сходство за доказанную семантику. +`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 c00705b..0bd00df 100644 --- a/docs/tomes/06-behavior.md +++ b/docs/tomes/06-behavior.md @@ -255,6 +255,56 @@ Rust хранит этот небольшой начальный список с опирается на уже созданный `ObjectHandle`. Регулярный обмен ресурсами пока остаётся отдельным этапом, потому что для него нужны интерфейсы игровых объектов. +### Начальные свойства запасов руды + +Behavior хранит `CurrentOre` и `MaximumOre` в одной записи свойства с ключом +`0x02000100`: текущее количество лежит в основном float-слове, предел — в +дополнительном DWORD. В TMA это не означает, что оба значения свободно задаются +файлом. При загрузке `MisLoad.dll` ищет первое свойство с точным, чувствительным +к регистру совпадением имени и передаёт его второе raw-слово в setter. В +Behavior дескриптор `CurrentOre` записывает это слово в основное значение; +дескриптор `MaximumOre` читает дополнительное слово, но его setter ничего не +меняет. + +Оба дескриптора регистрируются как коды `4` и `5`. Это коды обработчика, а не +позиции в таблице дескрипторов: исходная DLL корректно работает и после +перестановки строк, потому что callback выбирает обработчик по коду строки. +Поэтому начальное состояние можно описать так, сохраняя биты без пересчёта +через `float`: + +```text +current = first_exact("CurrentOre").raw_value[1] ?? class_default_current +maximum = class_default_maximum +``` + +Класс задаёт значения по умолчанию в Behavior RVA `0x8790`: + +| Слово класса | `CurrentOre` | `MaximumOre` | +| --- | ---: | ---: | +| `0x80000004` | 0 | 500 | +| `0x80000008` | 0 | 4000 | +| `0x01002000` | 0 | 2000 | +| `0x01004000` | 2000 | 2000 | +| прочие слова в этой ветви | 0 | 0 | + +Вызов RVA `0x8790` на синтетической структуре подтвердил эти значения для +классов таблицы, включая `0x01008000`; он проверяет тело native initializer-а, +но не его полный жизненный цикл в игре. + +В полной загрузке Rust сохраняет эти два raw-значения рядом с исходным TMA ID +и `ObjectHandle` каждого объекта с Unit DAT; список участников распределителя +для этого не требуется. Это важно для объектов, у которых есть компонент +Behavior, но нет членства в ресурсном distributor. Preview намеренно не создаёт +начальное состояние. Лицензированная AutoDemo показывает восемь объектов с +Unit DAT, включая объекты класса `0x01008000` вне списков distributor; в этом +снимке TMA `CurrentOre` равен нулю у всех восьми. Нативный x86 oracle отдельно +проверяет ненулевое raw-слово, чтение предела, отсутствие записи в `MaximumOre` +и переставленные строки дескрипторов. + +Эта модель покрывает именно начальную загрузку полных TMA-объектов. Она не +утверждает, что уже восстановлены все пути создания Behavior, отложенное +создание объектов или внешняя подмена class defaults конфигурацией. + ### Регулярная передача ресурсов Resource Distributor работает со списком зарегистрированных объектов. За один @@ -492,10 +542,200 @@ component как ordered raw-string/resource provenance, но не для при этим строкам смысловых имён до трассировки private update methods. Runtime сохраняет ordered raw Unit DAT records рядом с каждым mission object -draft. Это создаёт проверяемую границу передачи данных от loader-а к будущему -Control consumer-у: никакой компонент пока не получает имя `Control` только -по `kind`, `parent_or_link` или description; semantic binding появится лишь -после trace private update/load methods. +draft. Теперь подтверждена связь Unit DAT с descriptor-ом AniMesh, который +передаётся в Control: порядок узлов задаётся деревом immediate-child counts, +а `parent_or_link` попадает в descriptor как локальное поле. Его смысл зависит +от registry type и состояния Control manager-а; в частности, для `INTO` это +локальный индекс устройства, а `EXTO` проходит отдельную ветвь. + +### От Unit DAT к Control descriptor + +В GOG `ArealMap.dll` (SHA-256 +`a25f9254ebb339d70e2e07c8121950191e9584ca0858d8e9c2e2b6c671edf6ea`) +`FUN_10016a10` (RVA `0x16a10`) читает запись Unit DAT в дерево узлов по +`0x78` байт: перед сырыми полями узла находятся указатель и количество детей, +а байты файла копируются начиная с node `+0x0c`. `FUN_10015290` (RVA +`0x15290`) передаёт каждый непосредственный узел корня в `FUN_10014b90` +(RVA `0x14b90`) с начальным parent ID `0`. + +Для узла с ненулевым raw kind `FUN_10014b90` формирует descriptor размером +`0x4c`: две строки ресурса копируются из node `+0x0c` и `+0x2c`, поле +descriptor `+0x40` получает parent ID, `+0x44` — DWORD node `+0x50`, а +`+0x48` начинается со значения `-1`. Из-за смещения raw-полей на `0x0c` +node `+0x50` — это ровно `parent_or_link` по смещению `0x44` в записи Unit +DAT. Затем `ArealMap` посылает owner-у событие `6 / 0x80000020` через vtable +slot `+0x34`. + +В `AniMesh.dll` (SHA-256 +`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`) +dispatcher `FUN_10001370` (RVA `0x1370`) передаёт это событие в +`FUN_10003760` (RVA `0x3760`). Тот выбирает следующий свободный ID, записывает +его в descriptor `+0x48` и сохраняет descriptor в списке компонентов. +Вернувшись после virtual call, `FUN_10014b90` передаёт этот ID как parent ID +рекурсивного обхода детей. Поэтому родительская связь Control descriptor-а +строится по фактически назначенному ID в обходе дерева, а локальный индекс +устройства приходит из `parent_or_link`. + +У этого обхода есть ранний выход: если raw kind в node `+0x4c` равен нулю, +узел и его дети пропускаются. AniMesh начинает со служебного root ID `0`, но +из-за пропусков и других записей назначенный ID нельзя в общем случае считать +равным индексу узла или номеру его записи в Unit DAT. + +Для registry type `INTO` и других не-`EXTO` значений `FUN_10003760` разрешает +parent ID через Control IID `0x202`, virtual slot `+0x44`, только если parent ID +не равен `-1` и интерфейс IID `0x202` доступен. `Control.dll` +`FUN_1002ecc0` (RVA `0x2ecc0`) возвращает индекс первого устройства, чьё поле +`+0x08` равно этому ID, или `-1`, если совпадения нет; AniMesh прибавляет +возвращённое значение к локальному индексу `+0x44` без отдельной проверки +`-1`. Если parent ID равен `-1` или IID `0x202` недоступен, используется сам +локальный индекс без смещения. Отсутствие устройства с parent ID — отдельный +случай: native path даёт индекс на единицу меньше локального, и Rust-проекции +нужно проверить это поведение явно. `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 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) +`FUN_10008b10` (RVA `0x8b10`) выбирает путь по полю descriptor `+0xc8`. +Значение `-1` запускает цикл по typed records; фабрика `FUN_1002d4b0` (RVA +`0x2d4b0`) создаёт по устройству на запись и сохраняет их порядок. Иное +значение вызывает `FUN_1002d890` (RVA `0x2d890`) только один раз; цикл по +typed-record count в этой ветви отсутствует. Следовательно, подтверждённый +override path применяет первую typed record и не добавляет новый объект. +Так модуль меняет характеристики уже существующего слота, не увеличивая число +устройств. Неизвестный tag в Rust CTLD parser приводит к `Unsupported` и может +оставить typed-record list неполным. Native factory имеет отдельный default +путь `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`, то есть +`FUN_10021d50` с флагом инициализации `0`. Этот вызов не создаёт объект и не +заменяет класс или vtable. Он сохраняет уже существующий ключ `+0x04`; сохраняет +текущее значение multiplier `+0x4c` (которое могло измениться после +конструктора); и копирует коэффициенты из CTLD в блок `+0x54`. Поле `+0x50` +обновляется лишь когда слово записи `+0x18` не равно `-1`. Сопоставленные +записи значений прибавляются к текущим полям объекта `+0x1c/+0x20`, а не +сбрасывают их. Поэтому «переопределение» здесь означает обновить часть данных +того же устройства, с ограничениями конкретного метода. + +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. + +Отдельная ветка того же GOG `AniMesh.dll` показывает, когда создаётся Behavior +для host object. В `FUN_10002ff0` (RVA `0x2ff0`, SHA-256 +`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`) вызывающая +сторона запрашивает IID `0x204` и сохраняет интерфейс в поле `+0x168`. Затем +отдельный импорт `GetQueue()` возвращает объект очереди; вызов метода через его +vtable slot `+0x30` даёт результат, который проверяется на ненулевое значение. +Только при ненулевом результате host class `3` вызывает +`CreateBehaviour(0, 0, self)` (RVA `0x34bd`); class `4` передаёт в +`CreateBehaviour` адреса полей prototype `+0x140` и `+0x160` (RVA `0x3426`). +Семантика метода slot `+0x30` здесь не установлена. Это подтверждает только +такую ветку и эти два класса; другие фабрики, нулевой результат и отложенные +spawn сюда не входят. + +### Один запрос Control для ресурсного устройства + +В CTLD запись tag `26` задаёт ресурсный множитель, но текущее значение +поставщика живёт в runtime state Control. GOG `Control.dll` (SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) +`FUN_10021d00` (RVA `0x21d00`) реализует getter selector `0x300`. Его фиксированное +слово `+0x2c` становится `fixed_words[11]` при копировании записи RVA `0x21d50`; +`fixed_words[1]` — ключ строки NDP. В объекте Control getter использует ключ +`+0x04`, provider interface `+0x44`, множитель `+0x4c` и коэффициент `+0x54`. +Provider interface направляет selector `1` и ключ в Control RVA `0xdc40`, где +читается текущее type-1 значение выбранной строки. Затем selector умножает +сначала provider на коэффициент, после чего на множитель: `provider * base * +multiplier`. Коэффициент приходит из CTLD; NDP связывает ключ с описанной +строкой, а текущее значение provider нельзя заменить предположением о состоянии +мира. + +Так этот селектор включён в цепочку добычи руды оригинала. В той же сборке +`Behavior.dll` (SHA-256 +`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`) +`FUN_100186b0` (RVA `0x186b0`) перечисляет устройства типа `0x1a`, а +`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-умножение или +подключение к игровому циклу. + +На x87 control word `0x007f` каждое умножение округляет мантиссу до 24 бит, +но промежуточная степень может выйти за диапазон `f32` и вернуться в него при +следующем умножении. Rust helper поэтому принимает явные текущие значения +provider и multiplier, проверяет tag, ключ и строку NDP, сохраняет порядок +операций, но поддерживает только конечные нормализованные значения или ноль на +входе, промежуточном и конечном этапах. Остальные случаи за этим численным +диапазоном он отклоняет; полный 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-а. ### Control system и physical model |