feat(runtime): recompute loaded Control owner profiles
Docs Deploy / Build and Deploy MkDocs (push) Successful in 1m5s
Docs Deploy / Build and Deploy MkDocs (push) Successful in 1m5s
This commit is contained in:
5 files changed
+1145
-109
No files matched your search
@@ -569,23 +569,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).
|
||||
Полный 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.
|
||||
|
||||
Остаётся сравнить этот полный mine load с original loader при тех же входных
|
||||
данных и продолжить трассировку `LoadControlSystem`, `LoadPhysicalModel`,
|
||||
`CreateCollManager` и collision objects, если потребуется связать profile words
|
||||
с shapes, contacts или реакцией на движение.
|
||||
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
|
||||
|
||||
|
||||
@@ -1105,15 +1105,143 @@ 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-ом. Имена и физические единицы полей остаются неизвестны.
|
||||
Теперь полный 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
|
||||
|
||||
|
||||
Reference in new issue
Block a user