Проверенная runtime-база PoliticalWorldAPI до WBML-0005

✅ Runtime-доказательство WorldBox 0.51.2 build 719 PoliticalWorldAPI 1.14.0

Если ты только начинаешь делать аддоны для Political World, лучше начать с этой страницы.

Здесь специально разделяются три вещи, которые очень легко перепутать:

исходники, которые мы прочитали
поведение, которое мы реально воспроизвели в игре
поведение, которое ещё не проверено

Это важно: изученный creator-source Political World обозначает себя как API 1.9.0, а установленный runtime, который тестировал Lab, — как 1.14.0. Это связанные источники информации, но это не одна и та же версия.

На каком окружении всё проверялось

Все runtime-утверждения WBML-0001…WBML-0005 ниже относятся к точному стеку:

WorldBox:          0.51.2
build:             719
git:               build-719@5dec
NeoModLoader:      1.2.0.1
PoliticalWorldAPI: 1.14.0

Успешный результат на этом стеке нельзя автоматически превращать в обещание для всех будущих версий WorldBox или Political World.

Что уже реально проверено

1. Данные аддона у королевства переживают полный перезапуск процесса

WBML-0001 записал значения, сохранил мир, полностью закрыл WorldBox, запустил новый процесс, загрузил тот же сейв и прочитал значения без повторной записи.

Проверено:

int
Unicode string
bool
float
приватный тег аддона у королевства
общий тег королевства

См. Addon Data Save/Load Probe.

2. Проверенное состояние королевства не протекает между двумя сейвами

WBML-0002 использовал строгую последовательность:

Мир A → Мир B → Мир A → Мир B

и уникальный токен текущего прогона. Каждый сейв вернул собственные значения и не показал текущую сигнатуру другого мира.

Это доказывает именно проверенный same-process путь изоляции. Это не означает автоматически «любые данные всегда изолированы при любых перезапусках».

См. World Isolation Probe.

3. Party-private typed data переживает save/load и полный перезапуск

WBML-0003 расширил проверку persistence на данные конкретной партии:

Get/SetPartyInt
Get/SetPartyString
Get/SetPartyBool
Get/SetPartyFloat

Та же партия по стабильному ID вернула все четыре значения после полного перезапуска WorldBox.

Также проверено, что данные читаются, пока партия деактивирована, и остаются на месте после реактивации.

См. Persistence & Party Lifecycle Suite.

4. Event Bus проверен именно в runtime

WBML-0004 проверял Event Bus в игре, а не полагался только на более старый source snapshot.

Важные результаты runtime:

GetEventIds() вернул 23 ID
на custom/unknown event ID можно подписаться
party.renamed передал протестированные имена через OldValue/NewValue
payload-объекты разных подписчиков изолированы друг от друга
ошибка одного callback не остановила здоровый callback
рекурсивный dispatch остановился на глубине 16
100 последовательных тестовых dispatch дали 100 callback

33 ms в stress-проверке — только наблюдение одного прогона, а не гарантия производительности.

См. Event Bus Runtime Suite.

5. Actions, Conditions и Effects проверены как единая цепочка API

WBML-0005 проверил регистрацию, validation, запросы, conditions, выполнение, operation results, выбранные effect helpers и unregister.

Особенно важное отличие runtime от первоначального предположения теста:

RegisterAction(тот же ID)
→ принимается
→ старое определение заменяется

После проверки replacement Lab сразу вернул canonical definition и продолжил остальные тесты.

См. Actions / Conditions / Effects Suite.

Уже найденные ловушки

Старый DTO/info-объект не обязан оставаться актуальным

Во время WBML-0005 support партии изменился между фазами. Исправленный probe перед проверкой снова получил партию по стабильному party ID.

Правило для новичка:

Если логика зависит от текущего политического состояния, запроси текущее состояние заново. Не считай старый PartyInfo или похожий объект вечным снимком истины.

У единственной активной партии support ведёт себя особым образом

В одном из ранних прогонов WBML-0005 попытка выставить support единственной активной партии ниже 100 привела к нормализации в 100. Попытка вернуть старое меньшее значение тем же setter снова дала 100.

Поэтому финальный suite вообще не выполняет точную mutation support, если у государства меньше двух активных партий.

Статус:

👁 Observed: single-active-party path нормализуется в 100
🧪 Не проверено: точная mutation/restoration при >=2 активных партиях

Cleanup тоже может сломать эксперимент

WBML-0005-fix3 правильно пропустил опасную mutation support, но старый FINAL cleanup всё ещё попытался «восстановить» старый snapshot. Именно cleanup-вызов setter и нормализовал support в 100.

Этот прогон не был принят как финальный. В fix4 правило «не трогать support» действует до самого конца.

Правило:

Setup, сам тест, восстановление и финальная уборка — всё это части одного эксперимента и всё должно проходить одинаковую проверку безопасности.

Что означает PARTIAL PASS

Suite может завершиться так:

FAIL=0
SKIP>0
SUITE RESULT: PARTIAL PASS

Это не означает, что вся подсистема «непонятна».

Это означает:

все реально выполненные assertions прошли;
некоторые явно названные ветки не выполнялись;
непроверенными остаются именно эти SKIP-ветки.

Например, WBML-0005 закрылся с 90 PASS / 0 FAIL / 3 SKIP, потому что в мире не было государства с двумя активными партиями. Ветка точного изменения support осталась непроверенной, но выполненные тесты actions/conditions/effects от этого не теряют доказательство.

Что читать дальше

Если тебе нужно писать аддон, а не изучать всю историю лаборатории:

Если будущий runtime будет вести себя иначе, не надо молча переписывать старый факт. Запиши новую версию окружения и воспроизведи отличие отдельным probe.