57 lines
3.4 KiB
Markdown
57 lines
3.4 KiB
Markdown
# 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 guard is enabled by installing its Lua file, independently of the dashboard
|
||
hardcore toggle. Remove the guard and recreate the world before intentionally
|
||
switching back to non-hardcore play. Do not erase the registry to recycle deaths.
|
||
|
||
## 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.
|