test(runtime): verify native resource distributor tick
Docs Deploy / Build and Deploy MkDocs (push) Successful in 39s

This commit is contained in:
Valentin Popov committed 2026-10-20 06:35:38 +04:00
1 parent 89a0d1da61
commit e4645b1d62
4 files changed
+709 -6

No files matched your search

+31 -3
View File
@@ -203,9 +203,37 @@ SuperAI для записей кланов, затем обновляет Behavi
Это полезное начало сценария, но ещё не целая игровая жизнь AI. Текущий runtime
не воспроизводит аргумент обратного вызова в `AI+0x3fc`, защиту от повторного
входа `AI+0x78`, одноразовую метку `AI+0x8a8` или обновления Behavior на игровых
тиках. Он также не подменяет очередь оригинала: вызывающая сторона сама
передаёт время, а локальный генератор Rust пока учитывает только случайные
числа этого восстановленного шага.
тиках. При этом один конкретный шаг Behavior — распределение ресурсов — уже
исполнен на исходной DLL с искусственными объектами; FParkan пока не вызывает
его, потому что игровой мир Rust ещё не предоставляет нужные ресурсные
интерфейсы. Runtime также не подменяет очередь оригинала: вызывающая сторона
сама передаёт время, а локальный генератор Rust пока учитывает только случайные
числа восстановленного стартового шага.
### Регулярная передача ресурсов
Resource Distributor работает со списком зарегистрированных объектов. За один
шаг он сначала проходит список и собирает нужные значения, а затем проходит его
ещё раз и применяет результат. Во втором проходе объект ищется заново, поэтому
его состояние или ответ getter-а может измениться между чтением и записью.
Нулевой временной шаг ничего не делает; некоторые состояния объекта также
пропускают строку ещё до запросов ресурсных интерфейсов.
В синтетическом примере исходного кода два объекта с ключами `41` и `42`
обрабатываются в порядке `41, 42, 41, 42`: производитель сначала сообщает
скорость `4`, затем `1`, а получатель со значением `6` заканчивает шаг со
значением `7`. Это показывает, почему одного результата чтения недостаточно:
алгоритм снова получает величины при применении. Сценарий был запущен прямо из
исходной `Behavior.dll`, но объекты и ответы интерфейсов заданы тестом; это ещё
не воспроизведение реальной миссии.
Пока мы знаем точные границы интерфейсных запросов и некоторые ветви классов
объектов, но не все доменные значения полей записи и не происхождение реальных
строк списка. Загрузчик FParkan не должен создавать такие строки из похожих
полей миссии: сначала нужно доказать путь регистрации и связать его с типами
ресурсных объектов. Технические идентификаторы и численные векторы приведены
в [приложении о сценарной машине](../appendices/script-vm.md), а оставшиеся
вопросы перечислены в [границах знания](../appendices/knowledge-boundaries.md).
Первый часто встречающийся table entry с side effect — `Handler(2)` (176
records в corpus). Он берёт active instruction, разрешает семь slots через