diff options
Diffstat (limited to 'docs/appendices')
| -rw-r--r-- | docs/appendices/knowledge-boundaries.md | 159 |
1 files changed, 158 insertions, 1 deletions
diff --git a/docs/appendices/knowledge-boundaries.md b/docs/appendices/knowledge-boundaries.md index 873497c..3744d84 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,119 @@ 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, а не +трактоваться как пустой список. + +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 и +внешние эффекты их методов не включены. Для 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 ещё не +установлено. 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` доступными. + +Rust query обращается к загруженному объекту и поддерживает `0xe00` только для +текущего descriptor tag `26` с factory tag `26`; другие активные typed tags и +factory paths остаются явными границами. Snapshot показывает состояние сразу +после native-конструкторов, но он не обновляется при Control tick-е. Native +`FUN_10010f30` (RVA `0x10f30`) изменяет и ограничивает provider amount, а +связанные callbacks переносят его между строками; их общий переход в Rust ещё +не реализован. Поэтому вызов нельзя считать живым ресурсным симулятором. +Behavior selectors `0x1002` и `0x1005` используют значения выбранного +профиля из `behpsp.res`, разобранного до создания нового мира. `0x1002` складывает +только текущие descriptor tag `26` запросы `0xe00`, затем применяет +`Transfer_Ore_OffBoard`; `0x1005` возвращает `Transfer_Power_Out`. Это начальный +снимок: он не отражает последующие изменения provider-строк, Control tick-а или +профиля. Полная загрузка сохраняет результат у `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 значения во время игры. + Закрывающий эксперимент: трассировать `LoadControlSystem`, `LoadPhysicalModel`, `CreateCollManager` и создание collision objects; связать каждый изменяемый field с созданным shape, contact или реакцией на движение. |