152 lines
8.5 KiB
Markdown
152 lines
8.5 KiB
Markdown
# 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 <account> <count>
|
||
clientless generate create <account> <count> <level> <faction> <archetype> <persistence> <seed>
|
||
clientless generate list
|
||
clientless generate profile <guid>
|
||
clientless generate login <guid>
|
||
clientless generate logout <guid>
|
||
clientless generate equip <guid>
|
||
clientless generate retire <guid>
|
||
```
|
||
|
||
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
|
||
<guid> 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:<guid>`. 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.
|