# AdventureBot generation The GM/console command `clientless generate` creates complete new native player characters on an existing normal bot account. No source player is cloned and no authentication account/password is created or changed. The native realm-character counter is updated for that account after a successful character commit. ## Commands ``` clientless generate create clientless generate create clientless generate list clientless generate profile clientless generate login clientless generate logout clientless generate equip clientless generate retire ``` The short create form defaults to level60, any faction/archetype, persistent, and a time-based seed. When specifying options, supply all five optional values. Count is1–10 per request, level10–85 (also limited by server maximum), faction is `any`, `alliance` or `horde`, and persistence is `persistent` or `temporary`. Each character is committed separately. A failed batch reports its actual completed count and retains already completed characters. Available archetypes: `warrior`, `paladin`, `hunter`, `rogue`, `priest`, `death_knight` (minimum55), `shaman`, `mage`, `warlock`, `druid`, or `any`. Native race/class data and account expansion restrictions determine eligible combinations. Both factions can use the administrative bot-account pool; this is not a normal client's character-creation request. `equip` refreshes the equipment of an idle online generator-owned bot using its stored archetype and seed. Native checks still apply, casting/combat/transit are rejected, and replaced items remain in bags. It requires sufficient bag space; an error can stop an online refresh partway through. The initial offline create pipeline is the atomic operation. Creation leaves bots offline. Explicit login uses the existing AdventureBot Lua controller. Initially they perform a local social intent for one hour at their home. Enable the existing daily planner with `clientless adventure schedule on` when desired. Rotation and automatic population targeting are not activated by this change. ## Identity and profile Names use curated cultural syllable combinations for the supported races and sexes. They contain no numbers, bot markers or numeric collision suffixes. Native name validation, reserved-name checks, character cache/database checks, and reservation of hand-written named Lua profiles apply. An exhausted pool fails cleanly instead of manufacturing a non-roleplay name. Profiles include a racial origin, vocation, background, two coherent primary professions, personality values and regional/activity affinities. The stored seed makes choices reproducible against unchanged catalogs and name availability. Existing name collisions legitimately advance the random stream. Equipment varies within a set of similar high-scoring legal options. Generated Lua is stored in the character database, avoiding runtime writes to source-controlled profile files. The ordinary sandbox/parser loads it with source `generated:`. Existing hand-written named Lua profiles retain precedence; ordinary non-generated characters keep the generic fallback. `identity.background` and `identity.vocation` are also available in the parsed profile. Generated strings are Lua-escaped, then escaped separately for SQL. Home points come from enabled, faction-compatible social tavern/settlement locations nearest the native racial starting region. Mature goblins and worgen use mainland orc/human home regions, rather than phased introductory maps. Death knights also choose racial mainland homes. Map relocation happens before native talent calculation, so introductory map609 does not reduce their talent budget. This is administrative creation, not a claim that these bots played or completed introductory quests. ## Native preparation `ClientlessCharacterFactory` is generic infrastructure with preparation and transaction-extension callbacks. It has no AdventureBot policy dependency. It uses native `Player::Create`, validated random appearance, level/skill setup, new player/item GUID allocators and native `SaveToDB`. Requested levels are initialized as birth state through native stat/talent/taxi/glyph initialization, avoiding earned-level reward mails/hooks before the character transaction. Network-active accounts, privileged accounts, unavailable names and the configured per-realm character limit are rejected. The AdventureBot layer supplies: - Native class-trainer spells, using the same read-only `CanTeachSpell` predicate as ordinary native teaching; weapon/armor proficiencies are race/class/level checked. Owned weapon skills are raised to their native level cap. - A solo damage specialization and valid talent allocation through native talent prerequisites, tiers, ranks and primary-tree gates. Arms uses the existing explicit build, other archetypes use a legal tier-ordered baseline. These generic builds are not claimed to be optimized raid/PvP builds. - Coherent primary profession pairs, trained to their legal native rank/cap; all four available secondary professions through existing supply preparation. Before world insertion, effect44 learning casts cannot be relied on to apply their target effects. The factory therefore initializes validated skill ranks with native SkillRaceClass/SkillTiers caps and `Player::SetSkill`. This helper refuses online players; ordinary live supply learning keeps its native casts. This does not teach every profession recipe or synthesize quest rewards. - Four native Embersilk Bags and class/stat/level-matching equipment. Candidate items are normal/uncommon/rare; native use/equip checks remain authoritative. Armor transitions at40 are respected. Temporary, holiday, reputation-bound, restricted-map/area and random-affix equipment is excluded. Caster/physical stat affinity and mana-only/triggered utility effects are checked, so a warrior does not receive a mana-restoration trinket. Identical equipped entries are not duplicated, in addition to native unique-equipment checks. Initial items are retained in bags rather than destroyed. - Existing daily/post-combat supply restocking upon login. Consumables are native items and continue to use the existing actual item/cooldown logic. No mounts, pets or optimized class rotations are introduced here. Existing non-warrior combat limitations remain. Being fully trained is distinct from having class-specific automated combat/support AI. ## Persistence and future rotation Apply `sql/custom/characters/2026_10_28_00_adventure_generator.sql` before using commands. The additive migration is idempotent. Native character state, inventory, professions, Lua profile, homebind and generated ownership are committed in one character-database transaction. Cache publication and create hooks happen only after confirmed success. Failure before/at commit does not publish a ready bot. The registry explicitly records ownership, seed, archetype, creation time, persistence and state. Existing characters such as Arthoran are not adopted. Only offline temporary generator-owned characters may be retired. Retirement marks metadata only; the native character, items and profile remain available for audit. Generator login refuses retired entries. Persistent characters are protected. There is no automatic deletion, replacement, new-account allocation or restart autologin. A later rotating population controller must define those policies and account/name capacity management explicitly. ## Verification Production-code adapter tests cover factory transaction failure/publication, account/name/security/character-cap gates, retirement ownership protections, command bounds, cultural naming, real Lua profile execution, personality/skill coherence, string escaping and equipment/armor eligibility. Compilation and adapters do not establish visible in-game behavior. Live-created character identities, gear, profession/talent/spell rows and login/profile results are recorded in the task checkpoint after native server checks. Live checkpoint (2026-10-28): four level60 characters are online: Aelion29 (night elf warrior), Zanzan30 (troll warrior), Lenara31 (worgen mage), Aldren32 (forsaken death knight). Their generated profiles were reloaded after a server restart, and native equipment refresh was saved for all four. Earlier temporary fixtures27/28 remain archived and offline. Existing inventory ownership for Allitester21 and Arthoran26 matched the pre-generation snapshot. All62 clientless test scripts passed. See checkpoints/2026-10-28-generator/ for native data/logs.