AzerothAI/docs/hardcore-replacement.md

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.