Files
AzerothAI/docs/hardcore-replacement.md
2026-09-24 05:33:45 +12:00

62 lines
3.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Hardcore population replacement
The game-side ALE lifecycle guard closes an identity permanently after death.
It preserves character data and the AzerothAI memorial, removes the character
from the random-bot manager, and refreshes a persistent login veto. Zaku and
protected identities are excluded. GUID, account and name must all match the
installation registry; human accounts are never included.
The installer promotes unused manual-summoning reserve accounts into the native
autonomous pool. The native random-bot manager maintains its configured population target using
unused factory-created characters. Replacements start at level 1 (Death Knights at level 55), with their
own names and AzerothAI recipes/memories assigned when observed. This does not
reset or resurrect a dead character. Duplicate death events are harmless.
The reserve is finite: this deployment began with 450 unused level-1 characters.
This release does not create additional accounts or extend the factory reserve
when it is exhausted. The population will fall below target if no eligible
characters remain. Check `azerothai_lifecycle` state counts before extending it.
Death Knights are eligible and count toward their race’s faction, within the same
25-per-faction cap. Their approved starting level is 55. Normal gameplay can still level a replacement after its initial entry.
The guard allocates new arrivals against actual living faction counts, targeting
25 Alliance and 25 Horde, including protected residents. It holds excess-faction
reserves and excess returning residents offline without retiring them. Returning
residents retain their progress and get priority over unused reserves. New activations record `entry_level=1` or `entry_level=55` for Death Knights; subsequent leveling is allowed.
Native factory-created newcomers are enrolled only from verified RNDBOT accounts
and only when fresh and at their class starting level.
## Installation
1. Build the updated AzerothAI application and start its runtime.
2. Run `python3 deploy/playable/install-lifecycle.py --lab /path/to/lab` to review.
3. Stop `ac-worldserver`.
4. Repeat the command with `--apply`. It backs up auth, character and playerbot
databases, current Lua scripts, compose overrides and the dashboard state.
5. Recreate only the world container with `docker compose up -d --no-deps ac-worldserver`.
6. Restart the ALE relay to load priority delivery for permanent-death events.
The installed guard reads `acore_auth.azerothai_realm_rules.hardcore`, synchronized
from the dashboard setting by the operations agent (normally within one minute).
When disabled, future deaths use the native playerbot resurrection behavior:
identities, memories, gear, and party membership survive. Dead active residents
still occupy their faction slots, so a recoverable death cannot spawn a replacement
or bypass the 50-bot cap. Historical permanent retirements remain retired.
For an immediate mode switch, update the dashboard first and synchronize the
native rule before declaring the transition complete. Do not erase the registry.
## Verification and recovery
Verify the lifecycle startup line, absence of lifecycle errors, zero retired
GUIDs online, new reserve activations at level 1, and the native target count.
The dashboard active count excludes unmanaged prototype entries in live mode.
For rollback, stop the world and restore its prior Lua directory and compose
override from the printed backup directory, then recreate the world container.
The previous characters were never deleted. Database restoration is a separate
operator action: it also rolls back gameplay since the backup timestamp.
Run `python3 tests/lifecycle-lua.test.py` with `lupa` installed for isolated
retirement, replay, protection and replacement-entry checks. Run
`node scripts/test-core.mjs` for application tests.