diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/appendices/knowledge-boundaries.md | 123 | ||||
| -rw-r--r-- | docs/appendices/script-vm.md | 233 | ||||
| -rw-r--r-- | docs/appendices/ui-shell.md | 60 | ||||
| -rw-r--r-- | docs/tomes/06-behavior.md | 117 |
4 files changed, 424 insertions, 109 deletions
diff --git a/docs/appendices/knowledge-boundaries.md b/docs/appendices/knowledge-boundaries.md index 3d97927..53244c7 100644 --- a/docs/appendices/knowledge-boundaries.md +++ b/docs/appendices/knowledge-boundaries.md @@ -478,20 +478,35 @@ Control выставлен flag `0x102`, слово флагов ANI `+0x14` и пересчитывается при каждом принятом активном вызове. Проверены также точное равенство с ненулевым RNG, расход RNG при принудительном `+0xd4` и сохранение RNG/счётчика в неактивной ветви. Движение и очереди исключены условиями этих -векторов; активация `+0xe0` задана явно. Отдельный вектор -класса `4` исполняет событие `4` через `0x31ae0` → `0x314f0`, проверяя -активность, начальные часы `time - 100`, округление DWORD в `f32` и одну -начальную команду. Геометрические callbacks подставлены явно, таблицы -устройств и shapes пусты; полный загрузочный путь не проверен. Источник времени -и доставка прослежены статически: +векторов; активация `+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`. AniMesh RVA `0x1370` передаёт часы Control; общий -обработчик Control RVA `0x7830` численно преобразует unsigned DWORD в `f32` -перед primary slot `+0x58`. Фабрика выбирает RVA `0xcbb0` для класса `9` и -RVA `0xbcf0` для остальных. Это подтверждает статическую цепочку вызовов, но не -её исполнение на миссии: связывание интерфейсов, активация устройств и shapes, -остальные ветви `0xbcf0` и +второй обход `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). @@ -569,23 +584,52 @@ resource-device значения во время игры. и mirror-варианты передают свой transform-вектор setter-у; это отдельная граница, как и более поздние placement/tick. -Полный Rust loader теперь вызывает FAC0 при построении -`build_control_device_projection` и публикует результат в -`MissionControlOwnerProfile::load_projection`. Игнорируемый corpus-тест -`full_load_builds_effective_control_device_table_for_mine_unit_dat` на лицензированном -`min_l_n1.dat` проверяет 11 устройств, все 25 соответствий provider ordinal -модели и упорядоченные значения `row +0x20`. Его агрегаты — -`0x470833fc/0x4897e712/0x4d9452cb` для `+0x530/+0x534/+0x538`; исходный и -начальный mutable word `26` равны `0x7f7fffff`. Это подтверждает Rust full-load -результат на оригинальных ресурсах, но не совпадение с полным нативным load -оригинала. Поведение позже при placement/tick и физический смысл raw-полей -остаётся неизвестным. Точные RVA, owner layout и векторы приведены в -[описании изолированного прохода FAC0](script-vm.md#изолированный-проход-fac0). - -Остаётся сравнить этот полный mine load с original loader при тех же входных -данных и продолжить трассировку `LoadControlSystem`, `LoadPhysicalModel`, -`CreateCollManager` и collision objects, если потребуется связать profile words -с shapes, contacts или реакцией на движение. +Полный 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 @@ -600,14 +644,19 @@ Native interoperability подтверждается только успешны Граница shell подтверждена exports `createShell/getIShell`, `IGUIServer`, верхнеуровневым UI-pass и файлами `ui/*.cfg`, `DATA/TextRes.cfg`, -`gamefont.rlb` и `sprites.lib`. RsLi framing библиотек закрыт, но widget tree, -layout rules, glyph metrics, sprite command semantics, focus/navigation и HUD -state machine пока не восстановлены до field-level спецификации. - -Закрывающий эксперимент: трассировать загрузку `shell_ctrls.cfg`, -`menu_resources.cfg`, `cursor.cfg`, `game_resources.cfg` и `hq.cfg`, сопоставить -GUI object factories и снять command/event captures для меню, HUD, briefing и -диалогов. +`gamefont.rlb` и `sprites.lib`. Для полной GOG-сборки подтверждены раздельные +форматы: `gamefont.rlb` читается общим RsLi reader, но его native consumer этим +не установлен; для меню подтверждена цепочка `menu_resources.cfg` → NRes +`font.lib` → native lookup `MENU_FONT` с получением реального font-объекта. +`menu_resources.cfg` и шесть вариантов `MENU_FONT`/`GAME_FONT` сопоставлены с +NRes-записями в [разборе shell и шрифтов](ui-shell.md). Остаются неизвестными +glyph metrics и drawing, выбор 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 diff --git a/docs/appendices/script-vm.md b/docs/appendices/script-vm.md index 38722a2..3de442d 100644 --- a/docs/appendices/script-vm.md +++ b/docs/appendices/script-vm.md @@ -1095,25 +1095,166 @@ backing. Значения `[2, 3, 5]` относятся только к нем `World3D::FUN_10007cb0` (RVA `0x7cb0`) до своего возврата посылает Agent event `0` через primary vtable slot `+0x38`. Agent RVA `0x1a80` сначала вызывает базовый обработчик `0x17df0`, затем рассылает компонентам event `4` с null -payload. Конструктор AniMesh задаёт `+0x158/+0x15c/+0x160` равными `1.0`. +payload. Позже та же функция `World3D+0x7cb0` повторяет slot `+0x38` с DWORD +времени из `DATWorld+0x32a38` (`0x7e6e`); `World3D+0x7ea0` передаёт туда же +время в `0x80a9`. Setter `World3D+0x5140` записывает входной DWORD в эту ячейку. +Нулевой вызов связывает интерфейсы, а ненулевой `NumericTime` запускает отдельную +ветвь активации. Конструктор AniMesh задаёт `+0x158/+0x15c/+0x160` равными `1.0`. Обработчик модели `0x75b0/0x6fc0` привязывает интерфейсы и матрицу, Effect RVA `0x3d30` и Control RVA `0x1ce00` сохраняют host/service указатели, а Control `0x1fe00` меняет только локальный collision-флаг. Эти ветви не вызывают AniMesh -scale setter `0x14770` и не пишут поля масштаба. После них Control проходит -`0x31b00 -> 0x314f0 -> 0x7830 -> 0xf940`, то есть в FAC0 входит с constructor -scales `[1, 1, 1]`. Это подтверждено только для обычной начальной загрузки и -rebind; отдельные AddNewObject/mirror scale setters и более поздние placement/ -tick пути в этот вывод не входят. - -Теперь полный Rust loader вызывает FAC0 в `build_control_device_projection` -после сборки provider rows и устройств. Игнорируемый тест -`full_load_builds_effective_control_device_table_for_mine_unit_dat` прогнан на -лицензированном `min_l_n1.dat`: он проверяет 11 устройств, сопоставление всех -25 provider rows и весь упорядоченный вектор `row +0x20`. Агрегаты mine равны -`+0x530 = 0x470833fc`, `+0x534 = 0x4897e712`, `+0x538 = 0x4d9452cb`; исходное и -начальное mutable word `26` оба равны `0x7f7fffff`. Это измеренный результат -Rust loader-а на оригинальных ресурсах, но не сравнение полного load результата -с оригинальным loader-ом. Имена и физические единицы полей остаются неизвестны. +scale setter `0x14770` и не пишут поля масштаба. При загрузке AniMesh получает +Control secondary owner с QI selector `0xa` и сохраняет возвращённый base owner +в `Agent+0x158`: `AniMesh.dll+0x2ff0` делает этот вызов в RVA `0x32ee..0x3300`, +а `Control.dll+0x76f0` для selector `0xa` вычитает `0x14` из `ECX` и возвращает +указатель. Диспетчер AniMesh RVA `0x1afb..0x1b0d` посылает через `Agent+0x158` +событие `4` в slot `+0x08`. Его base-owner vtable — Control RVA `0x3d298`, и +slot ведёт прямо в `0x314f0`; при нулевом payload исходный обработчик проходит +`0x7830 -> 0xf940`, поэтому FAC0 входит с constructor scales `[1, 1, 1]`. +Встречающиеся рядом переходники относятся к другим интерфейсам: Control owner +`+4` с таблицей `0x3d254` проходит через `0x31ae0` (adjust `-4`), а owner `+8` +с таблицей `0x3d1fc` — через `0x31b00` (adjust `-8`). Последний путь не является +вызовом через `Agent+0x158`. Это подтверждено только для обычной начальной +загрузки и rebind; отдельные AddNewObject/mirror scale setters и более поздние +placement/tick пути в этот вывод не входят. + +Теперь полный Rust loader вызывает FAC0 и затем FCA0 в +`build_control_device_projection_with_class`, после сборки provider rows и устройств. +`MissionControlOwnerProfile::load_projection` и `fca0_projection` хранят +отдельные статусы этих проходов. Игнорируемый тест +`full_load_builds_effective_control_device_table_for_mine_unit_dat` на +лицензированном `min_l_n1.dat` проверяет 11 устройств, 25 provider rows, весь +упорядоченный вектор `row +0x20`, три FAC0 агрегата и результат FCA0. Агрегаты +mine равны `+0x530 = 0x470833fc`, `+0x534 = 0x4897e712`, +`+0x538 = 0x4d9452cb`; исходное и начальное mutable word `26` оба равны +`0x7f7fffff`. Девять слов FCA0 по индексам `[0,1,2,6,7,8,9,10,11]` равны +`[40000000,40000000,40000000,00000000,00000000,00000000,00000000,00000000,00000000]`. +Это измеренный результат Rust loader-а на оригинальных ресурсах, но не +сравнение полного load результата с оригинальным loader-ом. Имена и физические +единицы полей остаются неизвестны. + +#### Изолированный проход FCA0 + +`Control.dll` SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e` +вызывает `FUN_1000fca0` (RVA `0x0fca0`) после `FUN_1000f940` и `FUN_1000fac0` +в каноническом обработчике event `4/null`. Входной класс Control читается из +`owner +0x50`. Первая проверка FCA0 (`0xfca6`) немедленно возвращается при +классе `9`; после этой проверки для такого класса нет чтений или записей +профиля, таблицы либо модели. Это класс владельца, а не factory tag отдельного +устройства. Все известные классы, отличные от `9`, включая `0`, входят в общий +путь; отсутствие класса в Rust проекции выдаёт `MissingNativeControlClass` и не +означает, что его нет в оригинальном объекте. `Fac0Unavailable` относится +только к этому общему, не-классу-9 пути: класс `9` завершает FCA0 до проверки +FAC0. + +На каноническом Unit DAT пути host получает `QueryInterface(0x204)` и передаёт +результат в `owner +0x38`. Проверенная цепочка через Agent и CBuilding приводит +к интерфейсу `owner +0x0c`; его vtable `0x3d1b4` имеет count slot `+0x0c -> +0x8830`, query slot `+0x18 -> 0x2bb40` и getter текущего descriptor tag +`+0x20 -> 0x2c390`. Этот интерфейс уже привязан до FAC0/FCA0. + +Функция `0x2bb40` выбирает E00 reader `0x100` для текущего tag `5` и reader +`0x300` для текущего tag `26`. У factory `5` vtable `0x3cdf8`, у factory `26` +vtable `0x3ce38`; обе таблицы указывают на общий `FUN_10021d00` в slot `+0x10` +и `FUN_10021d50` в slot `+0x1c`. Factory `26` в dispatch `0x2d4b0` также +использует конструктор `0x20800`, как и factory `5`. Поэтому все четыре пары +current tag/factory tag `(5,5)`, `(5,26)`, `(26,5)` и `(26,26)` используют +доказанные методы. E00 для текущего tag `5` считает +`coefficient[0] * provider.current_type1`; он не использует `M` по `+0x4c` и +descriptor word `8`. Текущий tag `26` тем же общим reader-ом дополнительно +умножает на `M`. Это правило не меняет отдельные callbacks бюджета или запись +factory-26 selector `0x500`. + +FCA0 передаёт в owner query порядковый номер `i`; query `0x2bb40` находит +устройство `i` и вызывает его reader. Уже reader `FUN_10021d00` получает provider +key из поля устройства `+0x04`. Provider getter `FUN_1000dc40` (RVA `0x0dc40`) +получает `this = owner +4`, читает таблицу по `owner +0x55c`, а ключ выбирает +строку `table + key*0x2c`; текущее type-1 значение находится по `+0x14` строки. +Индекс устройства и ключ provider row — разные значения с разными задачами. + +Конструктор owner `FUN_10006bf0` (RVA `0x6bf0`) задаёт scalar `+0x1a8 = 1.0` +и вызывает `FUN_10014260`, который записывает `1.0` в `+0x354/+0x358`. +Проверенные ветви канонического event `4/null` и FAC0 не меняют эти три поля +до FCA0. Это подтверждённые defaults начального прохода; значения после +activation, update или иных host writes здесь не проверялись. + +Для любого не-класса-9 пути начинается нулевая сумма. Устройства посещаются в +обратном порядке; только текущий descriptor tag `5` отправляется в selector +`0xe00`. При успешном native query его `f32`-результат прибавляется к сумме и +сразу сохраняется обратно в `f32` stack slot: + +```text +sum = 0.0f +for i = device_count - 1 down to 0: + if current_tag(i) == 5 and query(i, 0xe00) succeeds: + sum = f32(sum + e00(i)) +``` + +Затем из `+0x354/+0x358` вычисляется mean и `weight = mean * sum`. Отношение +`r = current[26] / original[26]` задаёт два сохранённых в `f32` коэффициента: +`factorA = (r + 1) * 0.5` и `factorB = r * 0.75 + 0.25`. Упрощённая запись ниже +сохраняет порядок зависимостей, но не показывает границы x87 spill: + +```text +for i in 6..9: + value = owner[0x1a8] * original[i] + value = value * weight + value = value * factorA + cap = original[i] + if cap < abs(value): + value = -cap if value < 0 else cap + current[i] = value + +for i in 9..12: + value = original[i] * weight + value = value * factorB + current[i] = value + value + +for i in 0..3: + current[i] = original[i] + original[i] +``` + +В первом триплете scalar умножается на слова `6..8`, затем результат умножается +на `weight` и `factorA`; промежуточные значения слов `6` и `7` сохраняются в +f32 slots между операциями, а слово `8` дольше остаётся в x87. Во втором +триплете сначала умножаются исходное слово и `weight`, затем `factorB`, затем +значение удваивается; первые два промежуточных произведения сохраняются, третье +остаётся в x87. После этих триплетов слова `0..2` удваиваются из исходного блока. +Точные spill-границы видны в RVA `0xfca0..0xfef9`. Native-векторы исполнялись +при x87 control word `0x007f`. + +Ограничитель срабатывает, когда исходный cap с сохранённым знаком меньше +`abs(value)`. Тогда ветвь проверяет `value < 0`: при отрицательном значении +результат равен `-cap`, иначе — `cap`; в `else` входят и `+0`, и `-0`. +Поскольку cap сохраняет знак оригинального слова, отрицательная граница может +развернуть знак результата. + +Построенный helper считает из копии, уже подготовленной FAC0; исходный массив +профиля остаётся отдельным. Его результат публикуется только при полном успехе, +поэтому ошибка FCA0 не оставляет частично записанных слов. В публичной модели +`load_projection` остаётся результатом FAC0, а `fca0_projection` хранит только +статус FCA0. Rust ограничивает эту арифметику конечными normal-or-zero входами +и промежуточными значениями: NaN, бесконечности, subnormal и промежуточные +результаты вне поддерживаемого диапазона f32 отклоняются. Это граница модели +Rust, а не доказательство того, что оригинал не принимает такие биты. + +Оригинальная FCA0 и методы DLL дали следующий canonical-default x86-вектор на +синтетической backing-памяти: класс `3`, E00 `[6, -0.75]`, scalar и оба mean +равны `1`, `current[26]/original[26] = 6/4`. Слова +`[0,1,2,6,7,8,9,10,11]` после прохода равны: + +```text +40200000 c0a00000 40c00000 3f800000 40000000 41200000 41e70000 c22d4000 40e70000 +``` + +Этот вектор подтверждает функцию на оригинальной DLL и выбранных getter-ах, но +не выполняет полный native Unit DAT loader или игровой цикл. Licensed mine-тест +отдельно проверяет Rust full-load: class `3`, `fca0_projection = Ok(())`, все +11 устройств и 25 provider rows; слова `[0,1,2,6,7,8,9,10,11]` равны +`40000000 40000000 40000000 00000000 00000000 00000000 00000000 00000000 00000000`. +FAC0 агрегаты и строки сохраняются. Поздние динамические scalar/mean, activation, +Control tick, placement и сравнение полного native load остаются открытыми. #### Входной класс Control при загрузке Unit DAT @@ -1172,26 +1313,46 @@ Runtime сохраняет класс и источник выбора, не з #### Активация и начальные часы -Для Control класса `4` oracle вызывает исходный конструктор RVA `0x31490` -и обработчик интерфейса RVA `0x31ae0` → `0x314f0` с событием `4` и ненулевым -DWORD времени. Он выставляет `+0xe0` по условию `class != 0`, копирует матрицу -хоста в три transform-поля и численно преобразует беззнаковое время в `f32`. -Поля `+0xe4`, `+0xe8` и `+0xec` получают `time - 100`, а командные часы -`+0xd8` и `+0xdc` — `time`. Это разные базовые значения: - -| Вход DWORD | Абсолютное `f32` | `+0xe4`, `+0xe8`, `+0xec` | -|---|---|---| -| `1000` | `1000` | `900` | -| `33554433` | `33554432` | `33554332` | - -Первый вызов при старом `+0xe4 == 0` добавляет начальную команду в очередь; -повторный вызов в этом векторе сохраняет одну запись. Хост явно подставляет -identity transform, единичный масштаб и нулевую геометрию. Oracle проверяет -аргументы и порядок этих callbacks, а функции Control и изменения его часов -остаются исходными. Таблицы устройств, shapes и дорожек пусты: их активация, -полный object loader и ветвь события `4` с нулевым payload здесь не исполнены. -Нулевой payload статически выбирает отдельную фазу связывания интерфейсов, -поэтому его нельзя считать обычным ненулевым временем активации. +Для Control класса `4` oracle вызывает исходный конструктор RVA `0x31490` и +обработчик `0x314f0` через интерфейс owner `+4`: его slot `+0x08` проходит через +переходник `0x31ae0`, который корректирует `ECX` на `-4`. Это ABI-вектор +отдельного интерфейса. Статически восстановленная цепочка AniMesh показывает, +что `Agent+0x158` вызывает primary slot `+0x08` напрямую. Оба пути ведут в +обработчик с событием `4` и числовым временем; native oracle исполняет только +путь owner `+4`. + +Обработчик RVA `0x314f0` получает unsigned DWORD, дополняет его нулевым старшим +словом до qword и выполняет `FILD` (`0x318d9`). Затем `FLD ST0`/`FSUB 100` +(`0x318e4..0x318e6`) численно вычитают `100` из ещё точного значения времени; +это не беззнаковое вычитание и не переполнение при времени меньше `100`. После этого +`FST` сохраняет baseline в `+0xe4`, `+0xe8`, `+0xec`. Оставшееся исходное целое +отдельно сохраняется в командные часы `+0xd8` и `+0xdc`. Поэтому правила таковы: +`baseline = f32(f64(time) - 100.0)` и `absolute = f32(time)`, где `time` — +исходный unsigned DWORD. Операция не равна `f32(time) - 100.0f`. + +| Вход DWORD | Абсолютное `+0xd8/+0xdc` (значение; bits) | Baseline `+0xe4/+0xe8/+0xec` (значение; bits) | Очередь `+0x370` после вызова | +|---|---|---|---| +| `100` | `100`; `0x42c80000` | `0`; `0x00000000` | `1` | +| `101` | `101`; `0x42ca0000` | `1`; `0x3f800000` | `2` | +| `1000` | `1000`; `0x447a0000` | `900`; `0x44610000` | `2` | +| `33554433` | `33554432`; `0x4c000000` | `33554332`; `0x4bffffce` | `2` | +| `16777217` | `16777216`; `0x4b800000` | `16777117`; `0x4b7fff9d` | `2` | +| `16777219` | `16777220`; `0x4b800002` | `16777119`; `0x4b7fff9f` | `2` | + +Первые два времени показывают, что обработчик смотрит на старое `+0xe4 == 0`, а +не на отдельный признак активации: вызов при `100` оставляет baseline нулевым, +поэтому следующий вызов при `101` снова добавляет начальную команду. Два больших +вектора отличают исходный порядок x87 от вычитания после преждевременного +округления абсолютного времени. Часы и callbacks проверены в отдельном x86 +процессе с control word `0x007f`; контрольные слова сохраняются и +восстанавливаются. + +Хост явно подставляет identity transform, единичный масштаб и нулевую геометрию. +Oracle проверяет аргументы и порядок этих callbacks, а функции Control и запись +его часов остаются исходными. Этот синтетический owner подтверждает ABI и +арифметику часов, но не полный Unit DAT loader, host callbacks и матрицу из +миссии или первоначальную активацию в игре. Таблицы устройств, shapes и дорожек +пусты; ветвь события `4` с нулевым payload в этом fixture не вызывается. Период ресурсного обновления — поле `+8` глобального объекта настроек RVA `0x42478`. Инициализатор RVA `0x6350` и reset-метод RVA `0x6420` задают diff --git a/docs/appendices/ui-shell.md b/docs/appendices/ui-shell.md index d236e14..7a5b7d1 100644 --- a/docs/appendices/ui-shell.md +++ b/docs/appendices/ui-shell.md @@ -26,10 +26,56 @@ Win32 messages `sprites.lib` и `Palettes.lib`. Конфигурации задают controls/resources/cursor, overlays и HQ; `TextRes.cfg` связывает символические ключи с текстом. -`gamefont.rlb` содержит две LZSS-записи (`0x040`), `sprites.lib` — 24 записи -raw Deflate (`0x100`). `sprites.lib::INTERF8.TEX` использует известный -`deflate_eof_plus_one` quirk. UI обязан пользоваться общим RsLi reader, а не -отдельной похожей распаковкой. +В demo `gamefont.rlb` содержит две LZSS-записи (`0x040`); `sprites.lib` +содержит 24 записи raw Deflate (`0x100`) и известный `deflate_eof_plus_one` +quirk для `INTERF8.TEX`. В полной GOG-сборке меню отдельно связывает +`ui/menu_resources.cfg` с `ui/font.lib`, архивом NRes. Поэтому `gamefont.rlb` +не задаёт единственный путь шрифта. Оба контейнера уже читаются общими +[RsLi](../reference/rsli.md)- и [NRes](../reference/nres.md)-readers проекта; +будущая UI-подсистема должна пользоваться ими, а не добавлять свою распаковку. + +В `menu_resources.cfg` ресурс `fonts` указывает `ui\\font.lib` с `libtype=multi` +и `type=2`; это поля CFG, а не FourCC записей NRes. У девяти записей +`font.lib` `type_id` равен `0x544E4F46` (`FONT`). Значение подстановки в +`font-substitute` — строковое имя: этот CFG alias (`MENU_FONT` или `GAME_FONT`) +связывает роль шрифта с его именем, но сам не является именем записи архива. +Числовые ссылки находятся отдельно, в объекте `fonts`. В проверенной паре CFG и +архива эти ссылки совпадают с исходными порядковыми номерами записей NRes +(`EntryId`), а не с `sort_index`: + +| Размер CFG | Строковый alias `font-substitute` | Ссылка `fonts` | `EntryId` и запись NRes | +| --- | --- | --- | --- | +| `640x480` | `MENU_FONT` | `8` | `8`, `mf_640.tft` | +| `640x480` | `GAME_FONT` | `6` | `6`, `gf_640.tft` | +| `800x600` | `MENU_FONT` | `5` | `5`, `mf_800.tft` | +| `800x600` | `GAME_FONT` | `3` | `3`, `gf_800.tft` | +| `1024x768` | `MENU_FONT` | `2` | `2`, `mf_1024.tft` | +| `1024x768` | `GAME_FONT` | `0` | `0`, `gf_1024.tft` | + +Пример из этой CFG: `font-substitute` связывает `MENU_FONT` со строкой +`MENU_FONT_1024x768`, а объект `fonts` связывает уже это имя с числом `2`. +Такое сопоставление относится только к этой конфигурации и архиву, а не является +универсальным правилом native selector. Строка `1024x768` не доказывает выбор +этого варианта при фактическом экране `1280x1024`. + +Проверены оригинальные `menu_resources.cfg` (SHA-256 +`508C3783EAF112023E46BF4617424FBB57C393BCEF328CE1B925549B0069EF97`) и +`font.lib` (440392 bytes, SHA-256 +`E4AF5D1F0BF0464574DE654DE378766090681F610705CE53539DF9041E045D1C`). +Шесть сопоставленных payload начинаются с `Tfnt`; это подтверждает сигнатуру +данных, но не значение последующих полей. + +Связка подтверждена и в оригинальном коде. В `iron3d.dll` SHA-256 +`D1DC4EA8535E2069B0A05C9E8BE2724DD438BA44CCA7A83007D8B2E50F9E35FA` shell +читает `shell_ctrls.cfg` в RVA `0x7410`, а инициализация в `0x78c0` читает и +регистрирует `menu_resources.cfg` в слоте `0` ResourceManager. `services.dll` SHA-256 +`D3619DEEB4D598B16099E0263E15F9C3213F0FAA7208DC093328CFBA93FDC0EA`, RVA +`0x92a0`, разбирает `font-substitute`, размерные значения и запись ресурса +`type=2`. Затем `iron3d.dll` запрашивает `MENU_FONT` в RVA `0x1eb20`, ищет ресурс +в `0x1ed06` и разыменовывает результат в `0x1ed3e`; прямая x86-трасса на +последнем участке подтвердила ненулевой объект. Это подтверждает получение +реального font-объекта, но не конкретной NRes-записи при `1280x1024`, её +отрисовку или паритет шрифтов. Ключ ресурса, legacy path, локализованный текст и исходные bytes — четыре разные идентичности. Archive keys остаются ASCII-casefold; `TextRes.cfg`, @@ -50,9 +96,9 @@ viewport, scale/letterbox policy, mouse-to-layout transform, clipping и z-order. Cursor, sprite и hit-test обязаны применять одно преобразование. Font contract включает glyph image, advance, bearing/offset, line height и -fallback glyph. Binary glyph metrics `gamefont.rlb` пока не восстановлены: -payload читается lossless через RsLi, а семантика устанавливается по consumer -trace. +fallback glyph. Содержимое `gamefont.rlb` и `Tfnt` payload записей `.tft` +сохраняется без потери bytes через общие readers (`RsLi` и `NRes`), но семантика +метрик и глифов ещё не восстановлена по consumer trace. Нормализованное событие проходит modal widget, затем shell command map; лишь разрешённая gameplay-команда превращается в World3D manual event. Held state и diff --git a/docs/tomes/06-behavior.md b/docs/tomes/06-behavior.md index cd8a0ba..48f4405 100644 --- a/docs/tomes/06-behavior.md +++ b/docs/tomes/06-behavior.md @@ -717,33 +717,89 @@ Rust full-loader теста на оригинальных ресурсах. Ве `None`, без дочернего fallback или синтетических нулей. Точные native writes и открытые вопросы о смысле полей приведены в [техническом разборе загрузки CTLD](../appendices/script-vm.md#профиль-владельца-control-при-загрузке-ctld). -Изолированный x86-вектор подтвердил общий проход `Control.dll!FUN_1000fca0` -(RVA `0x0fac0`): расчёт начинает с исходного profile word 26, а затем пишет -производное значение в изменяемую копию и заполняет три поля-накопителя -владельца, а также `+0x20` каждой строки provider. Для этого выбираются два -сырых слова `Slot68` через `Node38` state 0 / LOD 0, учитываются cache tag 27 и -устройства таблицы. -Смысл слов `Slot68` и итоговых чисел не установлен; мы не называем их массой -или площадью. - -Rust повторяет эту формулу изолированным helper-ом, и его тест совпадает с -оригинальным кодом на синтетических векторах при x87 control word `0x007f`. -В обычной цепочке загрузки AniMesh начинает с масштабов `[1, 1, 1]`, а вызванные -до FAC0 обработчики привязки модели, FX и collision-компонентов эти поля не -меняют. Поэтому загрузчик использует подтверждённые значения конструктора, а -не scale из TMA. Теперь `build_control_device_projection` выполняет FAC0 после -сборки provider rows и списка устройств и публикует результат вместе с копией -профиля владельца. +Изолированный x86-вектор подтвердил общий проход `Control.dll!FUN_1000fac0` +(RVA `0x0fac0`): этот шаг FAC0 начинает с исходного profile word 26, затем +заполняет три накопителя владельца и поле `+0x20` provider rows. Для него +выбираются два сырых слова `Slot68` через `Node38` state 0 / LOD 0, учитываются +cache tag 27 и устройства таблицы. Смысл `Slot68` и итоговых чисел не +установлен; мы не называем их массой или площадью. + +Для обычной начальной загрузки AniMesh создаёт scale `[1, 1, 1]`. Проверенные +обработчики модели, FX и столкновений до FAC0 его не меняют. Поэтому первый +проход получает значения конструктора, а не scale, записанный в TMA. Отдельные +маршруты создания и последующее размещение объекта остаются другими путями. + +### Начальная FCA0-проекция профиля + +После FAC0 оригинальная Control выполняет второй проход FCA0 и обновляет только +выбранные слова отдельной изменяемой копии. Условие раннего выхода проверяет +**класс владельца Control**: класс `9` сразу пропускает FCA0. Это не тег +фабрики отдельного устройства `9`: в +лицензированном mine-профиле есть устройство с factory tag `9`, но класс +владельца равен `3`, поэтому FCA0 выполняется. Любой известный класс, отличный +от `9`, включая `0`, идёт по общему пути. Если Rust не смог вывести класс из +ресурсной цепочки, он возвращает отдельный статус; это означает отсутствие +проекции в Rust, а не отсутствие класса в оригинальной DLL. + +На начальном пути конструктор задаёт scalar и два средних значения как `1.0`. +Устройства читаются с конца списка; +в сумму попадают только записи с текущим descriptor tag `5`. Их `0xe00` +значение использует ключ устройства и `current_type1` соответствующей строки +provider. Читатели фабрик `5` и `26` общие; для текущего tag `5` формула +`coefficient[0] * provider.current_type1` не использует ни multiplier `M`, ни +descriptor word `8`. Ветки current tag `26` дополнительно умножают на `M`, но +не участвуют в сумме FCA0, которая фильтрует текущий tag `5`. + +Упрощённая карта зависимостей показывает, почему важен порядок обхода и какие +слова меняются; строки формул сами по себе не задают порядок native-вычислений: + +```text +sum = 0 +for index in reverse(0..device_count): + if current_tag(index) == 5: + sum = f32(sum + query_e00(index)) + +mean = (mean_a + mean_b) * 0.5 +weight = mean * sum +r = current[26] / original[26] +A = (r + 1) * 0.5 +B = r * 0.75 + 0.25 +current[0..3] = 2 * original[0..3] +current[6..9] = native_signed_cap(original[6..9] * scalar * weight * A) +current[9..12] = 2 * (original[9..12] * weight * B) +``` + +Порядок x87 операций и spill границы приведены в техническом описании. Нативный +ограничитель срабатывает, когда исходный cap с сохранённым знаком меньше +`abs(value)`. Тогда проверяется `value < 0`: отрицательное значение даёт `-cap`, +иначе возвращается `cap`; ветвь `else` включает `+0` и `-0`. Поэтому +отрицательный cap способен изменить знак выхода. +Здесь в query передаётся порядковый номер устройства; его getter уже сам +использует ключ устройства для выбора строки provider. Точный порядок чтений, +промежуточных записей и проверки приведён в +[техническом разборе FCA0](../appendices/script-vm.md#изолированный-проход-fca0). + +Rust хранит исходные слова отдельно, считает кандидата из копии после FAC0 и +публикует слова FCA0 только после полного успеха. Статус `load_projection` +остаётся результатом FAC0, а `fca0_projection` отдельно сообщает исход +следующего прохода; ошибка FCA0 сохраняет уже подготовленную FAC0-копию. +Обычный путь подтверждён при x87 control word `0x007f` для конечных normal-or-zero +входов и промежуточных значений. Реализация не утверждает поддержку +денормализованных, NaN, бесконечных или выходящих за диапазон промежуточных +значений. + +Оригинальная FCA0 и выбранные getters совпали на изолированном x86-векторе; +точные raw bits, module hash, вызовы и ABI приведены в технической главе. Игнорируемый corpus-тест полного загрузчика на оригинальном -`UNITS/BUILDS/MINE/min_l_n1.dat` подтверждает сопоставление всех 25 provider -rows с начальными узлами и проекцию 11 устройств. Для профиля mine получены -агрегаты `+0x530 = 0x470833fc`, `+0x534 = 0x4897e712` и -`+0x538 = 0x4d9452cb`; тест сверяет также все 25 значений строк. Это результат -Rust loader-а на лицензированных данных, а не сравнение с полным native load -оригинала. Смысл слов `Slot68` и итоговых чисел по-прежнему неизвестен. Точные -входы, вектор и границы приведены в -[техническом разборе загрузки CTLD](../appendices/script-vm.md#изолированный-проход-fac0). +`UNITS/BUILDS/MINE/min_l_n1.dat` теперь проверяет class `3`, успешный статус FCA0, +все 11 устройств, 25 provider rows, FAC0 snapshots и девять выходных слов. +Для mine-профиля первый триплет FCA0 даёт `[2, 2, 2]`, два следующих — нули; +не все целевые слова обязаны отличаться от исходных. Тест также сохраняет все +11 устройств, 25 provider rows и результаты FAC0. Это проверка Rust loader-а +на оригинальных лицензированных ресурсах, а не сравнение полного native Unit +DAT load или gameplay. Поздние изменения means/scalar, activation, tick и +placement остаются отдельными открытыми вопросами. Для tag `19` фабрика создаёт объект с его исходными классом и vtable. Базовый конструктор `FUN_100218b0` задаёт multiplier `+0x4c = 1.0`. Override через @@ -940,10 +996,13 @@ Preview не загружает профили. `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`. Лицензированный тест загружает +таблице в этот список не попадают. Это фильтр самого `0x1002`, а не ограничение +доступности общего Control-запроса `0xe00`: он поддержан для текущих descriptor +tags `5` и `26` с factory tags `5` и `26`. Owner query получает порядковый +номер устройства; getter использует ключ этого устройства, чтобы выбрать строку +provider. Для current tag `5` значение равно `coefficient[0] * provider`, без +множителя `M` и descriptor word `8`; для current tag `26` результат равен +`provider * coefficient[0] * M`. Лицензированный тест загружает оригинальные CTL/NDP и полную миссию с этим Unit DAT. В установленном `min_l_n1.dat` class word равен `0x80000004`, поэтому исходный прогон выбирает `prof_mine.var`. Для проверки другого отображения второй прогон оставляет тот же |