diff options
Diffstat (limited to 'docs/appendices')
| -rw-r--r-- | docs/appendices/knowledge-boundaries.md | 63 | ||||
| -rw-r--r-- | docs/appendices/script-vm.md | 304 |
2 files changed, 331 insertions, 36 deletions
diff --git a/docs/appendices/knowledge-boundaries.md b/docs/appendices/knowledge-boundaries.md index fa1af94..d4a620f 100644 --- a/docs/appendices/knowledge-boundaries.md +++ b/docs/appendices/knowledge-boundaries.md @@ -323,16 +323,63 @@ sequence определяется NDP: она не дополняется по sidecar недоступен, запрос `0xe00` сообщает это отдельно, оставляя независимые агрегатные selectors `1/2` доступными. +Поля `parent_index`, Control flags и начальный stage count для NDP-строк +проецируются из AniMesh по глобальному ordinal; точные правила, native ABI +векторы и лицензированная root/`EXTO` fixture описаны в +[техническом подразделе](script-vm.md#начальная-msh-часть-строки-provider). +Проверки подтверждают только начальный снимок: сборка runtime parent-ов +остаётся статическим выводом по RVA `AniMesh.dll+0xa460`, а последующие +изменения в полном Control/animation tick-е не проверялись. + +Для provider-строки Rust также хранит одно `initial_amount_bits`. Нативный +`Control.dll` `FUN_1000f940` (RVA `0xf940`) кладёт результат selector `3` в +текущее и обработанное значения строки; при подтверждённых единичных множителях +это raw `max_volume` NDP. Последующее обновление меняет оба native поля, поэтому +снимок не моделирует вместимость или изменяемый Control amount. + 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 selector `0x1002` остаётся отдельной задачей: его множитель -`Transfer_Ore_OffBoard` приходит из блока `+0x820`, но источник фактических -текущих настроек для полного runtime-пути пока не подтверждён. +factory paths остаются явными границами. Этот запрос возвращает начальный +type-1 provider value (`1.0`); дальнейшее изменение provider amount в Rust не +реализовано. +Native oracle проверил изолированные пути распределения, обновления класса `4`, +стадийную арифметику `0x11220`, обход дочерних provider-строк `0x11130` и +visibility transition `0x11920` с исходными AniMesh callbacks. Эти сценарии +используют синтетические NDP/Node38-строки; они подтверждают локальные переходы +и порядок вызовов, но не полную загрузку или выполнение Control на миссии. Вызовы +`0x11220` используют `updateEffects = false`, что исключает ветвь Control FX и +`0x11af0`; в отдельном сценарии класса `9` `0xfca0` возвращается сразу после +смены видимости, поэтому связанное с ним движение не проверено. Хотя у строки +Control выставлен flag `0x102`, слово флагов ANI `+0x14` и производные байты +`+0x111..+0x113` изначально равны нулю. Вызовы AniMesh `0x93c0` и `0xa2a0` обновляют производную геометрию и +видимость, это отдельная непроверенная граница, а не FX callbacks. Активную +clock-ветвь не запускали; внешний источник времени и порядок вызовов в игре +остаются незакрытыми. Источник контактного коэффициента прослежен статически, +но не исполнен. Подробные векторы и статические границы приведены в +[техническом подразделе о provider-состоянии Control](script-vm.md#изменение-provider-состояния-control). + +Отдельный API `advance_loaded_mission_resources` принимает явное время очереди +и обновляет представленные поля `CurrentOre`, строк распределителя и Control +selector `1`. API не подключён к игровому циклу и не обновляет Control amount, +профили, special object-state gate или жизненный цикл объектов. Если обязательный +запрос позднего объекта не поддержан, транзакция возвращает ошибку без применения +подготовленных изменений. AutoDemo-тест подтверждает связь настоящих профилей с +этим шагом, но не полный паритет миссии; отдельный aggregate getter Behavior RVA +`0xa490` в oracle не исполнен. + +Behavior selectors `0x1002` и `0x1005` используют значения выбранного +профиля из `behpsp.res`, разобранного до создания нового мира. `0x1002` складывает +только текущие descriptor tag `26` запросы `0xe00`, затем применяет +`Transfer_Ore_OffBoard`; `0x1005` возвращает `Transfer_Power_Out`. Это начальный +снимок профиля и provider-строк. Полная загрузка сохраняет результат у +`ObjectHandle` и возвращает +ошибку, если известный код класса не имеет корректной записи; класс, +отсутствующий в таблице выбора, сохраняет начальные значения конструктора. +Preview и объекты без полного Unit DAT не получают профильное состояние. +Native oracle подтвердил соответствия кода класса выбранной записи, разбор +`.var` и применение второй области данных; +оригинальный aggregate getter Behavior RVA `0xa490` остаётся статически +исследованным, но не исполнен в oracle. В x86 oracle при x87 control word `0x007f` проверены порядок, signed zero, отрицательные входы, расширенный промежуточный диапазон и subnormal return. diff --git a/docs/appendices/script-vm.md b/docs/appendices/script-vm.md index c15b208..0f5994b 100644 --- a/docs/appendices/script-vm.md +++ b/docs/appendices/script-vm.md @@ -373,10 +373,17 @@ nearest-even `FISTP qword`, младший DWORD, преобразование D deadline `+0x14` по формуле `время + 3*64 + jitter`, где `jitter` лежит в `0..63` и получен одним шагом глобального MSVCRT LCG. В этой ветви она также обнуляет пять слов `+0x30..+0x40`. При повторном вызове до deadline ненулевой -`+0x10` оставляет deadline прежним, не расходует новое случайное число и не -очищает эти слова. Поведение после истечения deadline этим опытом не проверено. -Если само время очереди равно нулю, `+0x10` остаётся нулевым, и повторный вызов -снова проходит ветвь начальной подготовки. +`+0x10` оставляет срок прежним, не расходует новое случайное число и не +очищает эти слова. Если само время очереди равно нулю, `+0x10` остаётся +нулевым, и повторный вызов снова проходит ветвь начальной подготовки. После +срока scheduler продолжает при нулевом deadline или при беззнаковом +`now > deadline`; равенство ненулевому deadline ещё ждёт. Он считает +`u32(now - first_time)` с переполнением по модулю `2^32`, переводит миллисекунды в секунды через x87 +`FILD`/`FMUL`/`FSTP` и планирует следующий срок от текущего времени. Шаг +интервала равен `3 * 64 + jitter`: один шаг LCG `state = state * 214013 + +2531011` выдаёт значение `random = (state >> 16) & 0x7fff`, а +`jitter = ((random & 0xff) * 64) >> 8`. Native oracle проверяет +равенство и проход срока, обёртку и большие интервалы с округлением времени. Путь host callback в проверенной паре DLL теперь статически известен. В `iron3d.dll` функция `FUN_1005ff40` (RVA `0x5ff40`) сначала вызывает @@ -400,9 +407,11 @@ callback-точку входа и порядок внутри неё, но не bundle, но остальные потребители исходного глобального RNG не моделируются. В Rust также нет значения аргумента в `AI+0x3fc`, recursion guard `AI+0x78` или одноразового latch `AI+0x8a8`. Поэтому это связанный начальный поднабор, а -не полная активация SuperAI. Восстановленный ниже distributor tick проверен на -исходной DLL, но пока не подключён к Rust игровому циклу: у runtime нет -ArealMap-объектов и интерфейсов, которые нужны этому вызову. При +не полная активация SuperAI. После полной загрузки узкая Rust-реализация +вызывается явно через `advance_loaded_mission_resources(engine, queue_time_ms)`; +runtime не читает системную очередь, а приложение пока не вызывает API из +игрового цикла. Шаг использует разрешённые handles и представленные snapshots +профилей и Control, поэтому не воспроизводит отсутствующие в них callbacks. При ошибке ограниченного `Init` Rust отклоняет полную загрузку и сохраняет прежний мир и состояние генератора; такая политика отката принадлежит Rust loader-у. @@ -428,9 +437,33 @@ DWORD по смещению `+0x14` как `f32`; если выходной ук пока не получило доменного имени. Идентификаторы и границы вызовов не задают полную семантику свойств. -Изолированный x86 oracle вызывает исходный tick с подменой только IAT-слота -`GetSystemArealMap`; синтетические vtables записывают последовательность -вызовов и ответы. Для смешанного примера два прохода нашли объекты в порядке +Раздача считает доступный за этот шаг объём `A`, полный спрос `D` и взвешенный +спрос `W = Σ(demand × share)`. Из них выводятся коэффициенты приоритетной доли +`P`, остатка `R` и расхода `C`. В таблице ниже показан исходный порядок +проверок: он важен, когда нестандартные доли дают `W > D`. + +| Первое совпавшее условие (при `A > 0`, `D > 0`) | `P` | `R` | `C` | +| --- | ---: | ---: | ---: | +| `A ≤ W` | `A / W` | `0` | `1` | +| `W < A < D` | `1` | `(A − W) / (D − W)` | `1` | +| `A ≥ D` | `1` | `1` | `D / A` | + +При нулевом доступном количестве или спросе native path не выделяет +положительное значение. Строка с долей `share` получает коэффициент +`(1 − share) × R + share × P`, который сочетается с её спросом или доступной +вместимостью. `C` задаёт долю отбора руды у источников; для источников энергии +этот коэффициент вычисляется, но native-код не применяет его к производству. +У объектов в ветви приёма руды (не источников руды) native-код ограничивает `CurrentOre`: +если `MaximumOre − CurrentOre < 0.01`, значение становится `MaximumOre`. +Сравнение строгое: при разнице ровно `0.01` значение не меняется. +В x86-коде это константа `0x3c23d70a`; сравнение и округление проверены при +игровом x87 control word `0x007f`. + +Изолированный x86 oracle вызывает исходный scheduler RVA `0x1adb0`, который +сам вызывает исходный tick RVA `0x19e80`. Для синтетического времени он +подменяет IAT-слот `GetQueue`; tick подменяет `GetSystemArealMap`, а синтетические +vtables записывают последовательность вызовов и ответы. Для смешанного примера +два прохода нашли объекты в порядке `41,42,41,42`. Производитель руды с начальным значением `1` и скоростью `4` вернул при следующем чтении скорость `1`; получатель с начальным значением `6` получил `7`, а агрегаты distributor равны `[0,1,1,0.375,6]`. При запасе @@ -441,11 +474,13 @@ selector `1` на интерфейсе получателя становится `0x3f2aaaab`). Эти векторы проверяют арифметику исходной функции, но не распределение реальной карты. -Полная загрузка Rust теперь собирает этот список из runtime `ObjectHandle` и -сохраняет веса вместе с пятью исходными DWORD хвоста каждой записи. Членство -строится только для полного режима; preview остаётся статическим. Это пока не -даёт ресурсных полей и интерфейсов ArealMap для `FUN_10019e80`, а -`step_headless` по-прежнему шагает только `World`. +Полная загрузка Rust собирает этот список из runtime `ObjectHandle` и сохраняет +веса и поля строк, а также начальные ore-свойства объектов. Членство строится +только для полного режима; preview остаётся статическим. Явный API +`advance_loaded_mission_resources` использует очередь времени, расписание, +профили и представленные Control-таблицы, чтобы исполнить этот ограниченный +шаг над загруженным состоянием. `step_headless` по-прежнему шагает только +`World`. ### Добавление и нормализация долей @@ -506,11 +541,14 @@ if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE } exit $LASTEXITCODE ``` -Native oracle Add, normalize и distributor tick компилируется и запускается -так: +Изолированный x86 oracle оригинальных Behavior, ArealMap и Control +компилируется и запускается так: ```powershell $env:FPARKAN_ORIGINAL_BEHAVIOR_DLL = 'C:\GOG Games\Parkan - Iron Strategy\Behavior.dll' +$env:FPARKAN_ORIGINAL_CONTROL_DLL = 'C:\GOG Games\Parkan - Iron Strategy\Control.dll' +$env:FPARKAN_ORIGINAL_AREALMAP_DLL = 'C:\GOG Games\Parkan - Iron Strategy\ArealMap.dll' +$env:FPARKAN_ORIGINAL_BEHAVIOR_PROFILE_RES = 'C:\GOG Games\Parkan - Iron Strategy\behpsp.res' New-Item -ItemType Directory -Force -Path target\behavior-distributor-native-oracle | Out-Null & "$env:WINDIR\Microsoft.NET\Framework\v4.0.30319\csc.exe" /nologo /platform:x86 /out:target\behavior-distributor-native-oracle\BehaviorDistributorTickOracle.exe crates\fparkan-runtime\tests\behavior_distributor_tick_native_oracle.cs if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE } @@ -520,17 +558,27 @@ exit $LASTEXITCODE Oracle проверяет SHA-256 оригинального `Behavior.dll`: `ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`. Harness -явно устанавливает x87 CW `0x007f` для вызовов Add (`0x1aac0`) и normalize -(`0x1ac90`), проверяет CW до и после каждого вызова и восстанавливает прежнее -значение перед tick suite. Для этих двух методов подменяется только bounded -вставка синтетического vector; их машинный код не патчится. Для tick helper -подменяет только IAT-слот `GetSystemArealMap` и вызывает RVA `0x19e80`. -Проверяются нулевой -шаг, обе ветви селекторов скорости, пропуск состояния `0xfffe`, missing lookup, -динамическое повторное чтение `0x1002`, ограниченный запас руды, разные веса, -достаточное и недостаточное значение мощности. Это синтетические ArealMap -объекты; исполнение оригинальной функции проверяет векторы oracle, но не -подменяет сравнение Rust и интеграционную проверку миссии в игре. +явно устанавливает x87 CW `0x007f` для Add (`0x1aac0`), normalize (`0x1ac90`) +и scheduler/tick (`0x1adb0`/`0x19e80`), проверяя слово перед набором вызовов +и восстанавливая прежнее значение после каждого набора. Для Add и normalize +подменяется только bounded вставка синтетического vector; их машинный код не +патчится. Scheduler и tick тоже исполняются оригинальными: подменяются лишь +IAT-слоты `GetQueue` и `GetSystemArealMap`, а synthetic vtables задают часы и +ответы объектов. Проверяются равенство и проход срока, переполнение времени +и точные `f32`-биты elapsed seconds (`1 → 0x3a83126f`, `1001 → 0x3f8020c5`, +`16777217 → 0x46831270`, `16777219 → 0x46831271`, `u32::MAX → 0x4a83126f`). +Tick-векторы проверяют нулевой шаг, обе ветви селекторов скорости, пропуск +состояния `0xfffe`, отсутствующий объект, повторное чтение `0x1002`, ограниченный +запас руды, порог `0.01`, ветви дефицита/частичного/избыточного предложения и +равенство спросу, разные веса и достаточную/недостаточную мощность. Тот же +harness проверяет в оригинальном Control пропорциональное и последовательное +распределение provider amount, коэффициент класса `4` с интервалом `2`, а также +неактивную временную ветвь с входами `0.5`, `1` и `2`. Вызовы Control используют +синтетические строки и хостовые callbacks; ArealMap тоже получает синтетические +объекты. Harness сверяет SHA-256 всех трёх DLL; ArealMap загружается из +изолированной временной рабочей папки, которую процесс затем удаляет. Эти тесты +проверяют отдельные native-пути, но не полный Control update и не паритет Rust с +игрой. Caller oracle проверяет AutoDemo пару `(500.2857, 751.8217)`, четыре режима x87 на tie-векторах, границу `10000` и младший DWORD. AI oracle отдельно @@ -557,6 +605,206 @@ tie-векторов подтверждает реакцию `FISTP`, но не форме инструкции. Всё остальное содержимое `.scr` сохраняется reader-ом, но остаётся вне этого исполнения. +### Изменение provider-состояния Control + +Для `Control.dll` (SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) native +oracle вызывает оригинальные `FUN_10010ba0` (RVA `0x10ba0`), `FUN_10010f30` +(RVA `0x10f30`) и selector-3 provider getter через vtable `0x3d254`, RVA +`0xdc40`. Пропорциональный режим проверен на максимумах `[30, 60, 50]`, текущих +значениях `[10, 20, 0]` и добавке `22`, результат `[14, 28, 10]`; отдельный +вектор подтверждает последовательное заполнение вперёд и вычитание с конца. +Проверены ограничение строк, снятие признака истощения при пополнении и порядок +обратных вызовов. При x87 control word `0x007f` для `[2^24, 2]` с запросом `-1` +получены значения `[16777214, 1.99999976]` и итог `16777216`: округление +вычисленного изменения даёт `-2`. Oracle задаёт внешнюю публикацию результата +обратным вызовом; provider строки не имеют родительских узлов и не проходят +отдельный жизненный цикл истощения корневого объекта. + +Для `FUN_10012a40` (RVA `0x12a40`) нативный вектор задаёт класс `4`, интервал +`2`, коэффициент `+0x1a4` равный `1` и текущее значение `10.000001`; результат +равен `8.000001`, вспомогательное поле — `-2`, нормализованное поле имеет биты +`0x3da3d70c`. Происхождение коэффициента подтверждено только статическим +трассированием: `FUN_1001a450` (RVA `0x1a450`) запрашивает интерфейс IID `0x0d`, +вызывает его slot `+0x24`, читает DWORD по смещению `+0x0c` в полученной записи +и сохраняет его в поле объекта `+0x1a4`. Поэтому нативный вектор проверяет +арифметику `FUN_10012a40` с заданным коэффициентом, а не исполнение контактного +пути или его игровой источник. + +`FUN_1000bcf0` (RVA `0xbcf0`) получает абсолютное значение времени. Oracle +исполняет только безопасную начальную ветвь при `+0xe0 = 0`: вход `0.5` +обновляет `+0xe8`, а входы `1` и `2` синхронизируют `+0xe4`, `+0xec`, `+0xd8` и +`+0xdc` без callbacks. Активную ветвь этот тест не запускал. Статический код +показывает gate по `+0xe0`; при условии `randomized_deadline < +0xe4` или +`+0xd4 != 0` вычисляет `dt = (+0xe4 - +0xec) * 0.001`. x87 выполняет `FSUB`, +затем `FMUL` с binary32-константой `0.001` (`0x3a83126f`), после чего результат +сохраняется в `f32`. Код вызывает `FUN_10012a40`, затем `FUN_1002d340` и +присваивает `+0xec = +0xe4`. В соседней ветви update packet queue обрабатывается +через `FUN_10012ce0`. Активную clock-ветвь oracle не запускал: внешний источник +времени и полный порядок вызовов в игре не установлены. Rust продолжает читать +начальные provider snapshots и не моделирует эти изменения. + +#### Родители, стадии и видимость provider-узлов + +`Control.dll` с SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e` проверен +прямыми вызовами исходных `FUN_10011220` (RVA `0x11220`) и +`FUN_10011130` (RVA `0x11130`). При расчёте стадии `FUN_10011220` может взять +долю родителя по флагу `0x04` или стадию родителя по `0x08`. Для стадии с +числом вариантов `count` при проверенных долях `0..1` расчёт имеет вид +`stage = min(count, count - ceil(f32(count * ratio)))`. Нативное ограничение +применяется к результату вычитания как к беззнаковому 32-битному значению; +здесь проверены конечные доли `0..1`. Для отдельного ряда из трёх стадий коэффициенты +`[0.1, 0.4, 0.5, 1, 0]` дали внутренние значения `[2, 1, 1, 0, 3]`; последнее +значение равно служебному sentinel `count` и означает истощение. В callback +`AniMesh.dll!FUN_10005810` передаётся только видимое значение +`min(stage, count - 1)`. + +После перехода родительского ряда `FUN_10011130` находит более поздние строки +с его индексом в поле parent. Обход идёт в глубину: сначала ребёнок и всё его +поддерево, затем следующий ребёнок. Рост стадии или истощение родителя снимает +количество с дочерних строк; защитные флаги `0x40` и `0x100` меняют часть +обработки флагов, но не останавливают снятие количества и обход потомков в +проверенных входах. Нативный тест задал родителя с дочерними рядами, снял их +количество и проверил порядок вызовов и значение stage snapshot. + +Переход между обычной стадией и sentinel `stage == count` вызывает +`Control.dll!FUN_10011920`, только если у строки не установлен флаг `0x02`. +Функция читает геометрию уже выбранной видимой стадии через +`AniMesh.dll!FUN_100051f0`. +Selectors `F` и `10` возвращают одну общую ячейку; второй запрос перезаписывает +значение первого. Это влияет на агрегаты: один синтетический узел при состоянии `0` +давал пару `[42, 330]`, а другой слот для состояния `2` — `[102, 570]`. В одном +тестовом цикле hide/show использовали один и тот же слот, поэтому агрегаты +вернулись к исходным; во втором цикл скрывал состояние `2`, а показывал состояние +`0`, и полученные значения уже не были взаимными противоположностями. Отрицательные +агрегаты во втором векторе — специально выбранные синтетические числа, а не +утверждение о допустимом состоянии игры. + +Эти вызовы исполнены в x86 oracle с Control SHA выше и AniMesh SHA-256 +`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`. Таблицы +NDP, Node38 и объект хоста синтетические; слот lifecycle проходит через исходный +`FUN_10005500`, а переход видимой стадии — через исходный `FUN_10005810`. Вызовы +`FUN_10011220` сделаны с `updateEffects = false`, поэтому ветвь Control FX, +включая `FUN_10011af0`, ими исключена. В отдельном visibility-сценарии класс `9` +заставляет `FUN_1000fca0` вернуться сразу после смены видимости, так что связанное +с ним движение также не проверено. Одна строка Control имеет flags `0x102`, но +слово флагов ANI `+0x14` и производные байты `+0x111..+0x113` изначально равны +нулю; поэтому вызовы +`AniMesh.dll!FUN_100093c0` и `FUN_1000a2a0` (пересчёт производной геометрии и +видимости) не покрыты. Эти результаты подтверждают локальные переходы и порядок +callbacks, но не полный Control update реальной миссии. Активная clock-ветвь, +внешний источник времени и полный игровой порядок вызовов пока не установлены. + +### Начальная MSH-часть строки provider + +`AniMesh.dll` (SHA-256 +`65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`) +строит глобальную MSH-таблицу в `FUN_1000a460` (RVA `0xa460`). Для каждого +узла корневой модели добавляется его исходная запись; mounted `EXTO` начинает +с узла `1`; `INTO` в эту таблицу не добавляет. При чтении Node38 поле +`parent_or_link` — это беззнаковое `u16` из байтов `+2`, а не готовый индекс +глобальной таблицы. + +Статические инструкции `0xa474..0xa49f` дают основу родительского индекса. +Для корня база равна нулю; для `EXTO` она равна старому размеру глобальной +таблицы минус один. Само значение трактуется так: + +```text +raw == 0 -> mount_node +raw == 0xffff -> parent_base - 1 +иначе -> parent_base + u32(raw) +``` + +Только `0xffff` служит sentinel-ом: остальные слова, включая `0xfffe`, +прибавляются как беззнаковые `u16`. Для примонтированного `EXTO` с базой `21` +слово `1` даёт parent `22`, а `0xffff` даёт `20`. `mount_node` выбирается из +уже построенной иерархии компонентов. Эта формула восстановлена по машинным +инструкциям загрузчика: `ADD EDI,EAX` в RVA `0xa7e3` прибавляет нормализованное +значение к базе перед записью parent по `0xa7e7`. Это не исполнение полного +загрузочного пути оригинальной игры. + +`Control.dll` (SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) +`FUN_1000f940` (RVA `0xf940`) получает три поля из AniMesh для того же +глобального ordinal. В x86 ABI oracle оригинального `AniMesh.dll` +`FUN_100051f0` (RVA `0x51f0`) с selector `0x0d` копирует runtime parent из +строки `+0x18` в общий scratch `DAT_10025e88` и возвращает адрес этой копии; +selector `0x0e` так же возвращает копию hdr0 Node38, а не адрес исходной записи. +Тест устанавливает raw parent words `[3, 0, 1]`, но runtime parents `[-1, 22, 7]`, +и проверяет, что selector D читает именно последние. hdr0 `[0x8201, 0x0180, +0x0400]` читается через полный 32-битный результат, поэтому старшие биты не +теряются. + +Control переводит проверенные маски hdr0 в поле строки `+0x28`: + +| Node38 hdr0 | Control bit | +| --- | --- | +| `hdr0 & 0x0200` | `0x01` | +| `hdr0 & 0x0100` | `0x02` | +| `hdr0 & 0x0400` | `0x04` | +| `(hdr0 & 1) != 0 && (hdr0 & 0x0080) == 0` | `0x08` | + +`FUN_10005840` (RVA `0x5840`) возвращает число подряд присутствующих slots +состояний `0..2`: `[present, absent, present] -> 1`, +`[absent, present, present] -> 0`, `[present, present, present] -> 3`. +Пустой префикс в начальной строке Control становится одной доступной стадией, +поэтому Rust хранит `max(1, prefix_length)`. Slot проверяется через штатный +`selected_slot` с `Group(0)` (native LOD0), а не подсчётом всех ненулевых words. + +Runtime временно собирает mesh-состояния в порядке AniMesh, затем сопоставляет +их с уже упорядоченными NDP provider-строками по общему ordinal. Избыточная NDP +строка или отсутствующий MSH asset получают `initial_mesh_state = None`; +совпадение по `(component_index, source_row_index)` не выполняется. Состояние +также не меняет существующий `0xe00` query: он читает начальное type-1 поле +`+0x14` provider-строки, равное `1.0` после нативного конструктора. + +### Начальное количество строки provider + +В `Control.dll` SHA-256 +`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e` +`FUN_1000f940` (RVA `0xf940`) получает для каждой строки selector `3` через +provider getter `FUN_1000dc40` (RVA `0xdc40`). Getter берёт `max_volume` из +NDP descriptor и последовательно умножает его на поля владельца `+0x660` и +`+0x548`. Конструктор `FUN_10006bf0` (RVA `0x6bf0`) задаёт оба множителя как +`1.0`. Инициализатор записывает результат в поля строки `+0x08` и `+0x0c`, а +type-1 поле `+0x14` остаётся `1.0`. Второе поле не является постоянной +вместимостью: `FUN_10011220` (RVA `0x11220`) копирует туда текущее `+0x08` при +завершении обновления. + +Native oracle вызывает оригинальные `f940`, `dc40`, `b240` и AniMesh getters +`FUN_100051f0`/`FUN_10005840` на тестовой памяти; подменён только callback +владельца. При unity множителях строки с `max_volume` `[30, 60, 50, 0]` +получили начальные количества с теми же битами, включая нулевую строку, а +callback-и пришли в порядке `[0, 1, 2, 3]`. Отдельный прогон с синтетическими +множителями `1.5` и `0.5` подтвердил формулу для этих входов, но не порядок +операций или загрузку игрового объекта; порядок `max_volume * +0x660 * +0x548` +виден в машинных инструкциях getter-а. На начальном пути Unit DAT множители +единичные: `ArealMap.dll` (SHA-256 +`a25f9254ebb339d70e2e07c8121950191e9584ca0858d8e9c2e2b6c671edf6ea`) в RVA +`0x15290` передаёт в `CreateObject` три значения `1.0`. Вызов World3D +`AddObjectToGame` (`World3D.dll`, SHA-256 +`17e4a3089b2583a8cf2356c9db0390b1aba138356a09130d79b4e7e4791da61e`, RVA +`0x7ea0`) не применяет transform scale; отдельный `AddNewObjectToGame` в RVA +`0x8310` имеет ветку установки scale. AniMesh constructor (`AniMesh.dll`, +SHA-256 `65659bf67f20e5be77d67a5b2f59968f61b94293143807fa59ca451c560c4f7e`, +RVA `0x68a0`) читает три DLL scale globals, которые после LoadLibrary в oracle +равны `1.0`. В Rust одна `initial_amount_bits` запись +сохраняет это общее начальное количество; полный update, который меняет +amount и обработанное предыдущее значение, пока не моделируется. + +Licensed full-load regression `full_load_builds_effective_control_device_table_for_mine_unit_dat` +проверяет значения настоящего `min_l_n1.dat`: корневой provider row `0` даёт +`1.0`, а row `1` примонтированного `EXTO` (общий ordinal `22`) даёт `6000.0`. +Проверка использует исходные CTL/NDP/MSH и не делает выводов о динамическом +изменении этих строк. + +Native-часть этих ABI проверок воспроизводит +`behavior_distributor_tick_native_oracle.cs` на синтетически выделенной памяти +и оригинальном DLL с указанным SHA. Она подтверждает getters и layout, но не +создание реальных AniMesh rows при полной загрузке; licensed runtime test +отдельно проверяет реальные Node38 literals root/`EXTO` на `min_l_n1.dat`. + ### Аргументы и обратный вызов Handler(30) `resolve_handler30_with_values` сохраняет восстановленное ABI типов объявлений, |