Documentation
This document describes the standalone database-free fake-player module for HF5 and Salvation.
## 1. Purpose and core guarantees
- Building requires Java 25.
- `FakePlayer` extends the core `Player`, so the client sees it as a regular character and it uses the core movement, geodata, Party, casting, private-store, and network-packet systems.
- Profiles, skills, equipment, consumables, loot, and store balances exist only in memory. The module contains no DAO, `DatabaseFactory`, JDBC, or SQL.
- Persistence of fake characters, effects, inventory, and skills is disabled. After restart, state is rebuilt from INI, XML, and TXT data.
- Professions 0–3 are supported: classId `0–57`, `88–118`, `123–136`.
- Solo farmers and organized Party groups are two independent spawn systems.
## 2. Layout, build, and startup
Default paths relative to the GameServer working directory:
Purpose | Path
Main configuration | `config/mods/fakeplayers.ini`
Gameplay XML/TXT | `data/stats/services/fakeplayers/`
Module | `libs/l2e-fakeplayers.jar`
## 3. Complete `fakeplayers.ini` reference
### 3.1 Startup and scheduler
`FakeEngineEnabled` | `True` | Master switch. With `False`, only `fakeplayers.ini` is read; XML, TXT, and XSD files are not opened, and runtime integrations do not start. The GM handler remains available for status and `//fakes_reload`.
`FakeEngineSpawnOnLoad` | `True` | Automatically starts enabled solo locations and groups after startup.
`FakeEquipmentStarterMaxLevel` | `8` | Highest regular-fake level that uses the core character-creation set instead of `equipment.xml`. Valid range: `0..server maximum level`; `0` enables XML equipment from level 1. Traders are unaffected.
`FakeClanlessMaxLevel` | `20` | Inclusive highest level at which clan assignment is forbidden. With `20`, levels 1–20 always remain clanless and level 21 becomes eligible. `0` disables the restriction. If any member of an XML party is restricted, its whole roster remains clanless to preserve one consistent party affiliation.
`FakeCommunityStatisticsPlayers` | `True` | Includes active fakes in the Community Board online counter and the PvP, PK, PC Bang, Adena, and online-time rankings. Fake and real-player results are merged only in memory; fake data is never written to the database.
`FakeCommunityStatisticsClans` | `True` | Includes active fake clans in the Community Board clan count and clan ranking. Only clans whose current leader is a fake are included.
`FakeStatisticsPvpMin` / `FakeStatisticsPvpMax` | `0 / 30` | Inclusive random initial PvP-kill range for every fake.
`FakeStatisticsPkMin` / `FakeStatisticsPkMax` | `0 / 30` | Inclusive random initial PK-kill range for every fake.
`FakeStatisticsPcBangMin` / `FakeStatisticsPcBangMax` | `0 / 10000` | Random PC Bang points. Applied only with `PcBangPointEnable=True` and capped by the core `MaxPcBangPoints`.
`FakeStatisticsOnlineMinutesPerLevelMin` / `FakeStatisticsOnlineMinutesPerLevelMax` | `5 / 60` | Simulated session-minute range per level. The result is multiplied by the fake's level and selected independently, so equal-level characters do not receive identical online time. The normal timer keeps increasing it after spawn.
`FakeSchedulerTickMillis` | `100` | Stepping-manager period. Minimum `25` ms.
`FakeSchedulerBatchSize` | `50` | Maximum controllers per AI batch. Minimum `1`; the baseline value is designed for 500 fakes.
`FakeSchedulerCompetitiveBatchSize` | `32` | Priority quota for active PvP-event and Olympiad fakes before the background round-robin lane, `1..FakeSchedulerBatchSize`. This creates neither a separate thread nor an extra time budget: both lanes share one `FakeSchedulerMaxBatchMillis`, one scan/geo/pathfinding budget, and a competitive fake is not processed again as background in the same batch.
`FakeSchedulerMaxBatchMillis` | `20` | Time budget of one batch. Range `1..FakeSchedulerTickMillis`.
`FakeSchedulerSpawnBatchSize` | `2` | Maximum new fakes per spawn batch; minimum `1`.
### 3.1.1 PvP event auto-fill
`FakeEventAutoFillEnabled` | `True` | Supplements a PvP event with already spawned eligible fakes when registration closes. No actor is created and no database is used; traders and fakes in town mode are never borrowed. On a team event, an entire active XML party may be transferred into one event team and solo fakes balance the remaining slots. Every participant is checked against `validLevels`, `validProffs`, `excludedClasses`, and the other core event requirements. If any XML-party member is ineligible, the party is incomplete, or it cannot fit one team, the complete group is skipped.
`FakeEventAutoFillMinimumRealPlayers` | `1` | Minimum number of real participants required to enable auto-fill. `0` permits an entirely simulated event.
`FakeEventAutoFillMinimumParticipants` | `10` | Minimum desired participant count for solo modes and the lower bound for team modes. The team target is additionally determined by `FakeEventAutoFillPartiesPerTeam`.
`FakeEventAutoFillPartiesPerTeam` | `3` | Desired number of standard parties in each team. The target roster is `team count × value × PartyLimit`; when that exceeds map `maxAllPlayers`, the largest balanced roster permitted by the map is used.
`FakeEventAutoFillMaximumFakes` | `54` | Safety ceiling for fakes added to one event; `0` effectively disables additions. `54` permits three complete parties in both teams when the map allows it.
`FakeEventPhysicalOffensiveSkillChance` | `35` | Chance to attempt an offensive physical skill in one active PvP-event combat decision, `0..100`. If no suitable skill is available or it is on reuse, AI immediately falls through to movement or a regular weapon attack. Ordinary PvP and Olympiad use a separate behavior option.
`FakeEventPhysicalDebuffSkillChance` | `15` | Chance to attempt physical control/debuff in one event decision, `0..100`. Together with the preceding option, this prevents tanks, Blade Dancers, Sword Singers, archers, and other physical classes from endlessly rotating skills instead of using weapon attacks.
`FakeEventPatrolDistanceMin` / `FakeEventPatrolDistanceMax` | `1000 / 2000` | Range of one random move inside the active event zone when no enemy or mandatory objective is available. Event-zone bounds, geodata, and closed doors are checked before movement; an unreachable point is discarded.
`FakeEventPatrolIntervalMinMillis` / `FakeEventPatrolIntervalMaxMillis` | `3000 / 7000` | Random interval between successful patrol moves. A failed point is retried sooner, and a newly visible enemy interrupts patrol immediately.
`FakeEventAutoFillTypes` | PvP event list | Allowed Java implementation names separated by commas, semicolons, or spaces. The defaults cover ordinary and objective PvP modes: Death Match, Last Hero, TvT, TvT Round, Korean Style, both PvP Zone modes, Capture The Flag, Base Capture, Domination, and Treasure Hunt. CTF/Base/Domination/Treasure use the dedicated flag, base, capture-zone, and chest event AI.
Regular events are filled when registration closes. Global `SoloPvpZoneEvent`/`TeamPvpZoneEvent` modes are filled after the first real player enters; with `MinimumRealPlayers=0`, they may be filled immediately after startup. In team mode, an XML party is assigned atomically to one team and solo fakes are then assigned to the least populated teams. Prophet and Hierophant are never selected. A borrowed XML party may contain at most one healer; the total healer count in each event team is capped by its resulting party count, which keeps every party at zero or one healer. The total participant count is a multiple of the team count; if map capacity or the eligible fake pool is smaller than the target, the closest smaller balanced roster is used instead of creating unequal teams. A fake validates enemies through `event.canAttack`, assists its temporary leader, never attacks its team, and can heal, cleanse, recharge, and buff eligible allies. Single-target and mass resurrection are centrally blocked during an event: death, respawn, and delayed return remain exclusively owned by the event itself. XML parties are not borrowed for solo events, where every other registered participant is an enemy. AI waits during preparation and refreshes its core AFK activity once per second during combat, so it is not removed before the match ends. Only after the actual return teleport does the fake restore its permanent buffs and resume normal farming.
Before using an HP, CP, or MP potion, a fake checks the core `event.canUsePotion`. If the current event rules prohibit potions, the fake does not use them.
A dedicated event-AI takes over when combat starts. In Death Match, Last Hero, TvT, TvT Round, and PvP Zone modes a fake searches for rule-approved enemies across the whole event map instead of being restricted to the normal farm scan radius. A distant target is retained until direct geodata visibility is reached and core PathFinding is used to approach it. Entering the nominal attack range while a wall still hides the target no longer completes navigation: routing continues until real geodata visibility is obtained. A newly selected hidden enemy interrupts an old patrol or other unrelated movement and immediately becomes the route target. After a failed route that target is temporarily excluded so the fake does not repeatedly run into the same wall. With no available target, leaders periodically patrol random reachable points within `1000..2000` inside the active zone while temporary Party members follow their leader. Target scans continue during patrol, and a newly found enemy interrupts movement immediately. CTF can take and return a flag while free allies escort their carrier; Base Capture attacks the base or uses the capture skill; Domination occupies the active zone; Treasure Hunt searches for and opens live chests. In Korean Style only the selected duelists move and fight while the other participants stay out of the round. A nearby visible enemy temporarily takes priority over a non-urgent objective. Lucky Creatures and Monster Attack are recognized as PvE modes and are intentionally absent from the default auto-fill list.
### 3.1.2 Safe Olympiad integration
`FakeOlympiadAutoFillEnabled` | `False` | Master switch for filling core Olympiad queues with already spawned solo fakes. Disabled by default.
`FakeOlympiadNonClassedEnabled` | `True` | Enables synthetic opponents in non-classed one-versus-one matches.
`FakeOlympiadClassedEnabled` | `True` | Enables synthetic opponents in classed one-versus-one matches. The fake base class must exactly match the waiting real player's base class.
`FakeOlympiadTeamsEnabled` | `True` | Enables a synthetic roster in three-versus-three matches. It always contains exactly three fakes and at most one healer.
`FakeOlympiadAutoFillMinimumRealPlayers` | `1` | Minimum real players in a 1v1 queue or real teams in `TEAMS` before filling.
`FakeOlympiadAutoFillMaximumFakes` | `1` | Shared maximum temporary registrations for `NON_CLASSED` and `CLASSED`.
`FakeOlympiadAutoFillMaximumTeamFakes` | `3` | Separate team-Olympiad fake limit. It must be at least three while `FakeOlympiadTeamsEnabled` is enabled.
`FakeOlympiadRealPlayerKillPoints` | `1` | Fixed points only after an actual fake death. When the complete fake team is killed, each surviving real team member receives the value once. Timeout/default wins and draws grant nothing. `0` disables the award; larger values are capped by core `AltOlyMaxPoints`.
`FakeOlympiadRegistrationTimeoutMillis` | `300000` | Maximum queue wait. Only a fake not yet selected for a match is removed on timeout; a formed or active match is never interrupted.
A real player waiting in `NON_CLASSED` receives a suitable fake directly. `CLASSED` is filled only with a free fake whose `baseClass` matches exactly. In `TEAMS`, one registered real roster of three receives a separate roster of three fakes; mixed rosters and fake-versus-fake matches are rejected by core matchmaking. A candidate must be a solo fake in FARM mode, outside a Party, alive, free from trading/event/other Olympiad activity, and satisfy the live `ClassRegisterParams`. Noblesse remains required unless `AllowRegWithouNobleStatus=True`.
Fake registration is temporary and never calls `Olympiad.addNoble`; its stats exist only in the match object. A fake never gains or loses points, and a match containing it is not inserted into the fight-result table or used for hero selection. Real stats receive the outcome and consume a weekly match of the correct type. Losing to a fake removes no points, and no item reward, achievement, or quest callback is triggered.
Every synthetic participant accepts its arena teleport invitation automatically while real players still confirm normally. After transfer, each fake receives five skills from the live `SupportType.OLYMPIAD` group: the magical or physical set from current `supportMagic.xml`; the same set is applied to a living summon. During the countdown the fake summons its servitor, casts self buffs, and moves into working range once doors open without attacking early. An opponent hidden by geodata is retained as a navigation target both before the start and during active combat; the fake builds a route but cannot attack before the core starts the match. In team matches a healer/support identifies allies by matching `gameId` and `olympiadSide`, then heals, cleanses, restores MP, and buffs them even after core dissolves the normal Party. Mass party heal is not attempted without a real Party; targeted healing is used instead. HP, CP, and MP potions are disabled, while shots, arrows, and bolts remain active. Resurrection is disabled for the complete Olympiad cycle. Permanent buffs and FARM mode are restored after return.
### 3.2 Target search and validation
`FakeBehaviorTargetMode` | `MONSTERS` | Base targets: `MONSTERS`, `PLAYERS`, or `BOTH`. Retaliation and permitted PvP take priority over this mode.
`FakeBehaviorExcludedNpcIds` | `18793` | NPC template IDs that cannot be selected, accepted through assist, or attacked in retaliation. Separators are comma, semicolon, or whitespace; an empty value disables the list.
`FakeBehaviorScanRadius` | `2000` | Search radius around the current position; must be positive. Scanning runs when there is no usable locked target.
`FakeBehaviorScanHeight` | `600` | Maximum vertical difference to a candidate; must be positive.
`FakeBehaviorScanIntervalMillis` | `1000` | Rescan interval with no target or an unavailable target; `100..1000` ms.
`FakeBehaviorScanBatchLimit` | `50` | Shared world-scan limit per batch; not below `FakeSchedulerBatchSize`.
`FakeBehaviorGeoChecksPerBatch` | `250` | Target-visibility check budget; not below `batchSize × (geoCandidatesPerScan + 1)`.
`FakeBehaviorGeoCandidatesPerScan` | `4` | Number of nearest candidates retained for GeoEngine checks; minimum `1`.
`FakeBehaviorMovementGeoChecksPerBatch` | `50` | Movement-geodata check budget; not below `FakeSchedulerBatchSize`.
`FakeBehaviorPathFindingEnabled` | `True` | Enables bounded obstacle navigation to an eligible hidden target: a farm monster, the party leader's assist target, a PvP-event enemy, or an Olympiad opponent. Requires `PathFindBoost=True` in `main/geodata.ini`.
`FakeBehaviorPathFindsPerBatch` | `2` | New background PathFinding-route limit per AI batch; minimum `1`.
`FakeBehaviorCompetitivePathFindsPerBatch` | `8` | Separate event/Olympiad route-start limit per batch, `1..FakeSchedulerCompetitiveBatchSize`. Background farming cannot consume it.
`FakeBehaviorPathFindMaxDistance` | `2000` | Maximum distance to an invisible monster; `1..FakeBehaviorScanRadius`.
`FakeBehaviorPathFindRetryMillis` | `5000` | Backoff before retrying an unreachable target; minimum `1000` ms.
`FakeBehaviorPathFindTimeoutMillis` | `15000` | Time allowed to reach direct geodata visibility; from the retry value through `60000` ms.
`FakeBehaviorTargetValidationIntervalMillis` | `1000` | Visibility revalidation interval for a locked target; `100..1000` ms.
### 3.3 Movement and combat
`FakeBehaviorLeashRadius` | `2500` | Global target-validity limit around the farm center; not below the scan radius. XML `distance` additionally defines the specific spawn boundary: minimum 500 for solo and 1000 for group. |
`FakeBehaviorMeleeRange` | `80` | Preferred range for a regular melee attack.
`FakeBehaviorPoleSkillMaxRange` | `180` | Hard distance limit from the primary target for mass pole/AURA skills; minimum `1`.
`FakeBehaviorPveWarriorOffensiveSkillChance` | `25` | PvE offensive-skill chance for WARRIOR/TANK/FARMER/ARCHER/HYBRID_SUPPORT, `0..100`; PvP/Olympiad and events have separate options. DAGGER uses a separate physical loop. An equipped bow/crossbow activates ARCHER behavior regardless of the original role. A ready regular PvE shot takes priority over a skill.
`FakeBehaviorPveWarriorDebuffSkillChance` | `12` | Physical PvE debuff chance, `0..100`.
`FakeBehaviorPvpWarriorOffensiveSkillChance` | `35` | Offensive-skill chance for a physical role against a player in ordinary PvP and Olympiad, `0..100`. An unavailable, invalid, or cooling-down skill immediately falls through to movement or a regular weapon attack.
`FakeBehaviorPvpWarriorDebuffSkillChance` | `15` | Physical control/debuff chance in ordinary PvP and Olympiad, `0..100`. A PvP event uses `FakeEventPhysicalDebuffSkillChance` instead.
After an accepted offensive skill, a physical class queues its regular weapon attack as the cast follow-up. The transition runs directly on the core `EVT_FINISH_CASTING`; a controller fallback preserves the hit for instant skills or when the core action queue is occupied. Completion of a combat approach also clears the remaining `actionIntervalMillis` delay, so the hit or skill begins on the next task-manager tick instead of waiting for the full common interval.
A polearm user opens combat with a regular weapon attack and only adds area skills after autoattack is established. Orc Mystic, Shaman, Overlord, Warcryer, Dominator, and Doom Cryer use the same physical opening in PvP events, then alternate weapon hits, offensive skills, and debuffs. Optional party buffs from healer/support/hybrid-support no longer preempt an already selected enemy or active combat; healing, cleanse, and MP restoration keep their priority.
`FakeBehaviorPveMageDebuffSkillChance` | `10` | Magical PvE debuff chance; regular nukes remain preferred, `0..100`.
`FakeBehaviorRangedRange` | `900` | Fallback desired archer/mage distance; the actual skill cast range takes priority.
`FakeBehaviorKiteDistance` | `350` | Fallback kite-step length.
`FakeBehaviorFormationRange` | `500` | Party follow/formation radius around the leader.
`FakeBehaviorWanderRadius` | `900` | Maximum random patrol step without a target, additionally constrained by the farm area.
`FakeBehaviorWanderIntervalMillis` | `10000` | Base patrol interval; minimum `1000` ms.
`FakeBehaviorWanderJitterMillis` | `5000` | Non-negative random addition to the patrol interval.
`FakeBehaviorActionIntervalMillis` | `650` | Minimum combat-decision interval for one controller; minimum `100` ms. The 650 ms default modestly increases activity from the previous 750 ms without increasing world-scan frequency.
`FakeBehaviorBuffCheckIntervalMillis` | `3000` | Class buff/aura/party-buff check interval; minimum `100` ms.
`FakeBehaviorFormationUpdateIntervalMillis` | `1500` | Follow/formation update interval; minimum `100` ms.
`FakeBehaviorRespawnDelayMillis` | `10000` | Solo recovery delay after death; minimum `1000` ms, followed by travel to town.
`FakeBehaviorPartyReviveWaitMinMillis` | `10000` | Minimum resurrection wait for a group member; minimum `1000` ms.
`FakeBehaviorPartyReviveWaitMaxMillis` | `20000` | Maximum wait; not below the minimum. On expiry, the member recovers in town.
### 3.4 Party, healing, and support
`FakeBehaviorHealBelow` | `70` | HP percentage for a single-target heal/emergency action; `0..100`. The individual skill's XML `hpBelow` also applies.
`FakeBehaviorSupportMpBelow` | `35` | MP percentage for recharge/support; `0..100`.
`FakeBehaviorMassHealMembers` | `2` | Minimum wounded living members for mass heal; at least `2`.
`FakeBehaviorMassResurrectMembers` | `2` | Minimum dead members for mass resurrection; at least `2`.
`FakeBehaviorDamageTrackerCapacity` | `8` | Fixed number of remembered attackers per fake; `1..32`.
`FakeBehaviorDamageMemoryMillis` | `15000` | TTL for recorded damage/defensive assist; minimum `1000` ms.
`FakeBehaviorSummonAssist` | `True` | Makes an existing summon attack its owner's current target.
`FakeBehaviorPartyAssist` | `True` | XML-group members follow the leader's published target.
`FakeBehaviorProtectHealer` | `True` | The healer's attacker, or the support's attacker when there is no healer, becomes the group's defensive priority.
`FakeBehaviorRealPlayerPartyAcceptChance` | `3` | Chance for a solo fake to accept a real player's Party invitation, `0..100`.
`FakeBehaviorRealPlayerPartyInviteCooldownMillis` | `300000` | Delay between invitation decisions; minimum `1000` ms.
`FakeBehaviorRealPlayerPartyCheckIntervalMillis` | `2000` | Party-state check with a real leader; minimum `250` ms.
`FakeBehaviorRealPlayerPartyLeaveTolerance` | `500` | Extra range beyond farm/formation range before leaving Party; non-negative.
### 3.5 PvP response
`FakeBehaviorEngageFlaggedPlayers` | `True` | Enables proactive attacks on flagged/PK candidates. Retaliation against a real player who already dealt damage is handled separately.
`FakeBehaviorFlaggedPlayerRadius` | `1200` | Special PvP scan radius; `100..FakeBehaviorLeashRadius`.
`FakeBehaviorFlaggedPlayerScanIntervalMillis` | `1000` | PvP scan interval; `100..1000` ms.
`FakeBehaviorFlaggedPlayerMaxLevelDifference` | `5` | Maximum number of levels by which a player may exceed the fake; non-negative.
`FakeBehaviorFlaggedPlayerSoloChance` | `50` | Solo-fake chance to attack a flagged/PK player 1–N levels higher, `0..100`. Equal or weaker targets are attacked with 100% probability.
`FakeBehaviorFlaggedPlayerPartyChance` | `100` | Equivalent chance for a fake Party leader, `0..100`.
`FakeBehaviorTargetOtherFakes` | `False` | Allows unrelated non-flagged fakes to become regular targets. Flagged/PK fakes and actual attackers use PvP rules regardless of this option; members of the same core Party or spawn group are always excluded.
`FakeBehaviorRespectAutoAttackable` | `False` | When `True`, also requires a positive core `isAutoAttackable` result; this may restrict simulated PvP.
### 3.6 Names and titles
`FakeIdentityTitleMinLevel` | `60` | Minimum level eligible for a random title; from `1` through the core server maximum.
`FakeIdentityTitleChance` | `35` | Title chance at or above that level, `0..100`. A fake receives noblesse before receiving a title.
### 3.7 Chat and dialogues
`FakeDialogueEnabled` | `True` | Master DialogueManager switch.
`FakeDialogueNearbyRadius` | `900` | Selection radius for an ALL responder and an autonomous conversation partner; every SHOUT is delivered globally.
`FakeDialogueReplyDelayMinMillis` | `1500` | Minimum reply delay to a player.
`FakeDialogueReplyDelayMaxMillis` | `5000` | Maximum reply delay; not below the minimum.
`FakeDialoguePlayerCooldownMillis` | `20000` | Per-real-sender cooldown against repeated replies.
`FakeDialogueFakeCooldownMillis` | `12000` | Per-answering-fake cooldown.
`FakeDialogueMaxPendingReplies` | `256` | Capacity of the bounded delayed-message queue.
`FakeDialogueMaxRepliesPerBatch` | `4` | Maximum messages sent in one dialogue tick.
`FakeDialogueFakeConversations` | `True` | Enables fake-to-fake conversation scenarios.
`FakeDialogueFakeConversationChance` | `35` | Chance to start an autonomous scenario at a check, `0..100`.
`FakeDialogueFakeConversationMinMillis` | `120000` | Minimum interval between conversation attempts.
`FakeDialogueFakeConversationMaxMillis` | `300000` | Maximum interval; not below the minimum.
`FakeDialoguePeriodicMessages` | `True` | Enables standalone periodic messages for a living-chat effect.
`FakeDialoguePeriodicMessageMinMillis` | `45000` | Minimum periodic-message interval.
`FakeDialoguePeriodicMessageMaxMillis` | `90000` | Maximum interval; not below the minimum.
A fake temporarily borrowed by a PvP event or Olympiad is not eligible for an autonomous conversation, periodic line, or public `ALL`/`SHOUT` reply. A public message queued earlier is dropped if the fake has entered either competitive mode before delivery. A directly addressed `TELL` reply remains allowed.
## 4. XML and TXT data
### 4.0 `clans.xml` and `crests/`
The `<clans enabled>` root controls fully in-memory fake-player clans. `<alliance id name crest>` defines a local numeric ID, displayed name, and fixed 8×12 8-bit BMP alliance crest. `<clan id name level reputation maxFakes allianceId crest>` defines the clan name, displayed level and reputation, fake-member limit, alliance reference, and fixed 16×12 8-bit BMP clan crest. `allianceId="0"` creates an independent clan. Reputation is applied through the normal `Clan` object in memory with `save=false`.
Crests live under `data/stats/services/fakeplayers/crests`; every file is referenced explicitly, so its clan/alliance mapping never changes across restarts. The loader strictly validates the L2-compatible BMP, pads its height from 12 to the engine-required 16 pixels, and uses the core's standard `DDSConverter` to produce DDS/DXT1: 256 bytes for a 16×16 clan texture and 192 bytes for an 8×16 alliance texture. The original visible crest area remains 16×12/8×12. The client crest ID is derived deterministically from the leading BMP catalog number in the safe ranges `51,000 + catalogId` for clans and `61,000 + catalogId` for alliances. The supplied data defines 26 clans: 16 belong to four alliances and 10 are independent, with 2,400 total fake slots. All four clans in one alliance share the same clan crest and alliance crest, producing one consistent combined emblem; independent clans keep distinct crests. A new solo fake randomly selects one remaining slot, preserving each `maxFakes` limit while leaving every clan/crest/alliance relationship stable. If total capacity is exhausted, extra fakes remain clanless and appear as `clans.unassigned` in `//fakes`.
`FakeClanManager` registers clans and crests in the standard holders only for the server process lifetime so normal `CharInfo`, pledge-info, and crest packets display them to clients. Creation, membership, leadership, and removal perform no INSERT/UPDATE/DELETE; despawn removes the transient member, while shutdown releases transient clans, crests, and IDs. Names must be unique, alphanumeric, and 2–16 characters long; level is `0..11`, reputation is non-negative, and `maxFakes` is positive. Before fake spawning, the loader validates alliance references, file existence, BMP signature, dimensions, and 8-bit depth.
### 4.1 `towns.xml`
Root `<towns enabled lootCapacity>` enables town behavior and limits the number of distinct accumulated loot types. Each `<town>` defines:
- `id` — reference to a town-behavior parameter set;
- `x/y/z`, `heading` — fallback point used only when the core cannot resolve the home spawn's MapRegion;
- `npcRadius`, `npcHeight` — NPC search bounds;
- `visitMinMillis/visitMaxMillis` — interval between visits;
- `stayMinMillis/stayMaxMillis` — visit duration;
- `moveMinMillis/moveMaxMillis` — pause between NPC movements;
- `storeChance`, `storeMinMillis/storeMaxMillis`, `maxStoreItems`, `priceMultiplier` — temporary SELL store.
All Min/Max pairs are ordered; percentages are within `0..100`, and radii/capacities are positive.
After the town list, seven `<peaceCombatZone id>` entries contain `<zone x y zMin zMax>` vertices. These are precise gremlin polygons for Human Fighter, Human Mystic, Elf, Dark Elf, Orc, Dwarf, and Kamael. When a fake is inside such a polygon, PEACE does not activate town mode or block PvE; only a monster inside the same polygon can be targeted. Players in PEACE never become targets, while all other peace zones keep the regular town behavior.
### 4.2 `spawn/single/*.xml` — solo system
The directory initially contains `01-10.xml`, `10-20.xml`, `20-30.xml`, `30-40.xml`, `40-50.xml`, `50-60.xml`, `60-70.xml`, `70-80.xml`, and `80-85.xml`. The loader accepts additional XML files named `<min>-<max>.xml` (for example, `86-100.xml`), while location IDs are checked for global uniqueness. The maximum level comes from the core server `MaxPlayerLevel` setting (`Config.PLAYER_MAXIMUM_LEVEL - 1`) and is not fixed by the fake-player system. Each file defines an independent lifecycle through its root `cycle`, `peaceMinutes`, and `battleMinutes`, so level ranges may use different farming and peace durations. With `cycle=false`, solo fakes from that file run continuously; with `cycle=true`, that file alternates active and peace phases. All lifecycles share the same scheduler and do not create separate threads.
`<location>`:
| Field | Meaning |
|---|---|
| `id` | Unique positive numeric ID. |
| `enabled`, `amount` | Switch and number of independent fakes. |
| `distance` | Farm/leash radius: at least 500 for a solo location and 1000 for a group spawn. |
| `spawnRadius` | Initial random placement; default `min(distance, 200)`. |
| `town` | Required reference to a visit-parameter set in `towns.xml`; the respawn town is resolved separately through MapRegion from the original coordinates. |
| `<coords x y z heading>` | Center; `heading=-1` is randomized. |
| `<class id>` | ClassIds separated by `;` or `,`; an empty list enables automatic level-based selection. |
| `<level min max>` | Inclusive `1..server maximum level` range; `max="server"` denotes the dynamic upper bound. |
Overrides `account`, `ai`, `female`, and `role` are allowed, as are nested `appearance`, `tactics`, `items`, `hennas`, `social`, and `skills`. HEALER, Prophet 17, and Hierophant 98 are forbidden in solo. Profiles receive IDs in the form `solo_loc_<location>_<index>`.
#### Geodata validation of spawn positions
Before character creation, `SpawnLocationSelector` validates the selected point. Solo uses the original `spawnRadius`; party uses `spawn.radius`; the larger farm `distance` is not used for placement. The check covers geodata availability, surface height (maximum correction 128), NSWE, and 24-coordinate-unit clearance around the point, including diagonals. The permitted floor difference in this area is 32. Solo/party placement also requires a direct geodata path from the XML center and back; a point behind a wall or on a disconnected floor is rejected.
If the preliminary point is unsuitable, at most 64 random attempts are made inside the original area. The center itself is then checked for solo/party. If no safe point exists, including when geodata is disabled or absent, the **exact original XML point including Z** is used without random displacement. The log receives `no geo-safe spawn found; using XML coordinates`. This explicit fallback cannot guarantee that the XML point itself is outside a wall.
A point trader preserves XML X/Y; only Z is corrected after a successful check, otherwise the original XYZ are used. A territory trader is placed inside its polygon and `zMin..zMax`. A polygon has no single spawn center: its fallback is the first XML `<zone>` vertex with its `zMin`, with a log warning.
Checks run only during spawning in the existing queue, without new threads, A*/PathFinding, or database access. The actual spawn coordinates are stored as home for the return from town and recovery after leaving the farm boundary. No new INI/XML parameters are introduced.
### 4.3 `spawn/group/*.xml` — Party system
The directory uses the same initial range files and also accepts additional `<min>-<max>.xml` files up to the server maximum level. All `<group>` elements are merged into one set, and group IDs are checked globally. `<group id enabled autoStart cycle peaceMinutes battleMinutes town partyId>` defines an independent lifecycle. With `cycle=false`, a group remains active until GM stop/shutdown. `<spawn x y z heading radius distance>` defines the shared area, `<wave delayMillis>` a delayed wave, and `<fake>` a member.
Required member parameters are `classId` and `level`; optional fields are `account`, `ai`, `female`, `role`, `town`, `partyId`, `partyLeader`, and the same nested profile overrides. A group must have 2–9 members and exactly one leader. Internal IDs are generated as `<groupId>_member_<n>`.
Clan affiliation is selected once per `partyId` and reserves slots for the complete roster: the entire group either shares one clan, uses clans belonging only to one common alliance, or remains wholly clanless. Levels 1 through `FakeClanlessMaxLevel` are forced to remain clanless; when such a profile belongs to an XML party, clanless mode applies to its complete roster without reserving clan slots. The mode and reservations survive temporary member despawn/respawn until shutdown, preventing a party from mixing unrelated alliances and independent clans. `//fakes` reports the distribution under `partyModes` and the active actors individually blocked by level under `levelRestricted`.
If a member is not resurrected within the INI-configured 10–20 seconds, it appears in town. The group returns to the spot with its leader once the leader is ready and no members remain dead.
### 4.4 `class-ai.xml`
`<classAi id parent role>` forms the profession tree. `parent` inherits tactics and skills; a child entry with the same `id + use` replaces its parent entry. Roles are `WARRIOR`, `ARCHER`, `DAGGER`, `MAGE`, `HEALER`, `SUPPORT`, `HYBRID_SUPPORT`, `TANK`, and `FARMER`. The Orc mystic branch uses `WARRIOR` before the first profession and `HYBRID_SUPPORT` from Orc Shaman onward: group support is preserved, while PvE offensive skills alternate with physical attacks according to warrior chances.
`<tactics>` fields are `preferredRange`, `movementIntervalMillis`, `kite`, `kiteTriggerRange`, `kiteStep`, `retreatToHealer`, `retreatHpBelow`, `retreatRange`, `flank`, and `flankDistance`. For ARCHER, `kite=true` enables retreat from a close target. Only a retreat that actually started or entered the movement queue blocks the next shot until movement finishes. The fake may attack after retreat; unavailable movement budget, cooldown, or a geodata-blocked retreat do not prevent stationary combat. The retreat threshold is capped at half the working distance so a short bow does not cause endless retreat.
An actually equipped bow/crossbow enables ranged combat for any original role, including Rogue, Elven Scout, and Assassin. Their original `preferredRange=80`, flank behavior, and dagger-skill priority do not apply to a bow. The working distance uses the real `getPhysicalAttackRange()` capped by the desired ARCHER/INI distance; AI does not increase weapon stats. An ARCHER profile switches to melee when no bow is equipped. Weapon requirements are checked on every skill attempt even when level has not changed.
As soon as the target is visible through geodata and within shot range, unnecessary approach, patrol, or bypass navigation stops. Regular shooting is delegated to the core PlayerAI as a stationary attack: movement remains controlled by the shared AI, without automatic point-blank pursuit. A ready regular shot has priority over an offensive skill in PvE; skills are allowed during reload according to warrior chances. PvP keeps skill priority. A physical attack already in progress is not interrupted by a new offensive skill or retreat in these branches.
The complete Orc mystic branch (`49`, `50`, `51`, `52`, `115`, `116`) uses a level-independent physical fallback: Orc Mystic, Orc Shaman, Overlord, Warcryer, Dominator, and Doomcryer. If an offensive skill is unlearned, on reuse, blocked by conditions/silence, lacks resources, or its cast request is rejected, AI approaches for a regular hit. Buffs, healing, and group support keep their priority. Offensive skills in this branch and archer skills use `doCast` after core checks; an unavailable skill is not queued as CAST for approach.
If `ATTACK` remains set without movement, an executing attack/cast, or queued actions, it is resubmitted to the core no more than once per second. Bow reload is respected, and attack/skill timers are not reset. These checks add no threads, per-character periodic tasks, database access, or configuration parameters.
`<skill>`:
- `id`, `level`, `minLevel`, `maxLevel`, `grant` — identity, availability, and level-acquisition mode; an omitted `maxLevel` or `maxLevel="server"` remains active through the server maximum;
- `use` — `OFFENSE`, `RARE_OFFENSE`, `AOE`, `CONTROL`, `RARE_CONTROL`, `DETECTION`, `HEAL`, `PERCENT_HEAL`, `MASS_HEAL`, `BUFF`, `PARTY_BUFF`, `SUPPORT`, `RESURRECT`, `MASS_RESURRECT`, `CLEANSE`, `EMERGENCY`, `ULTIMATE`, `SITUATION`, `CHARGE`, `SWEEP`, `SUMMON`, `AURA`, `PASSIVE`;
- `target` — `SELF`, `ENEMY`, `PARTY`, `SUMMON`;
- `priority`, `chance`, `reuseMillis`, `hpBelow`, `minRange/maxRange`, `effectAbsent`;
- `condition` — `NONE`, `SELF_HP`, `SELF_MP`, `SELF_CP`, `SELF_CHARGES`, `TARGET_HP`, `TARGET_MP`, `TARGET_CP`, `HEIGHT_DIFFERENCE`; bounds use `minCondition/maxCondition`;
- `weapons`, `armors` — allowed equipment types.
A larger `priority` is checked first but does not bypass chance/reuse/range/condition. With `grant=false`, the profession's actually available skill level is used; `grant=true` explicitly grants the configured level.
Skills outside the profession use a dedicated inherited block inside the required `<classAi>`:
```xml
<customSkills>
<active id="1234" level="1" minLevel="40" use="OFFENSE" target="ENEMY" priority="40" chance="35" />
<passive id="1235" level="1" minLevel="40" />
</customSkills>
```
`active` supports the same conditions, ranges, equipment requirements, chance, and AI reuse as a regular `<skill>`, but is always granted independently of the class skill tree. `passive` is also granted automatically, is applied by the core's normal stat system, and is deliberately excluded from the AI action list. When the actor leaves `minLevel/maxLevel`, the granted addition is removed and an identically numbered retail profession skill is restored when available. `level` is required and must exist in `SkillsParser`; an unknown ID/level stops loading before spawn.
When a combat mage crosses profession boundaries `20`, `40`, or `76`, the system deterministically selects a magical child profession from `class-ai.xml`, switches the core class template in memory, grants the available retail tree, and rebuilds the skill cache. Reaching level 40 from level 39 therefore replaces first-profession entries ending at `maxLevel="39"` with the selected second-profession skills instead of leaving the actor without attacks. Obsolete `Wind Strike`, `Ice Bolt`, and equivalent skills are not restored.
### 4.5 `equipment.xml`
At levels 1–`FakeEquipmentStarterMaxLevel` (8 by default), the system normally copies `PcTemplate.getInitialEquipment()`, the core character-creation set for the base profession. An `equipment.xml` range with `starterWeaponOverride="true"` replaces only the starter weapon with a random weapon from that range's weighted pool; the supplied data uses it for Orc Mystic (`49`). Java contains no exceptional classId list. Count, equip flag, enchantment, augmentation, and elements are preserved, while every item remains memory-only. Full weighted `equipment.xml` selection applies from the next level. Setting `FakeEquipmentStarterMaxLevel=0` disables the starter set completely.
Profession and level select exactly their XML pool. The supplied `equipment.xml` preserves the former sets: for example, Orc Mystic/Shaman and the crafting branch use physical one-handed maces, while the Overlord/Warcryer branches also include magical maces. These are now data rather than Java restrictions: changing the XML list immediately changes eligible equipment without a code edit.
Structure: `<class id>` → `<level min max starterWeaponOverride>` → independent weighted pools `<weapons>`, optional `<shields>`, `<armors>`, and `<jewels>`. `max="server"` extends the final range through the server maximum. `starterWeaponOverride` defaults to `false`; `chance` is a relative weight, not a percentage.
- `<weapon id chance enchant augmentationId>` and up to six `<element type value>` entries;
- `<shields>/<shield id chance enchant>` defines shields for tank and dwarf branches;
- `<armors>/<variant id chance>` and `<jewels>/<variant id chance>` contain `<item id count enchant equip augmentationId>`;
- a variant may contain `<hennas>/<henna symbolId>`, up to three.
For a non-stackable item, `count` means the number of separate `ItemInstance` objects: for example, `count="2"` on an earring or ring creates and equips two items in the left and right slots. A stackable item remains one stack with the configured count. Because fake equipment and loot exist only in memory, core `Player.onDieDropItem` handling is disabled for fakes; regular players are unaffected.
Issued items are tracked by MemoryInventory using `objectId`, so the same `itemId` on two non-stackable objects does not merge them. Left/right earrings and rings preserve their `locationSlot`, and each object is released separately when the fake is removed.
One weapon, one armor variant, and one jewel variant are selected. If the range declares `<shields>`, its variant is combined with the weapon exactly as configured in XML; there is no hidden profession or weapon-type check. Validation keeps only structural safety: a `<shield>` item must actually be a left-hand shield. The XML author owns weapon, armor, and shield compatibility. Arrows and bolts may exist in inventory but are equipped only when a bow or crossbow is actually worn.
### 4.6 `buff-sets.xml`
`<set id minLevel maxLevel>` must cover levels 1 through the core server maximum without gaps or overlap. `maxLevel="server"` denotes that dynamic maximum. An empty `set` disables permanent buffs for its range, so levels 1–5 remain without automatic buffs. `<buff id level priority>` creates a permanent effect until death. Class `BUFF`, `PARTY_BUFF`, and `AURA` also do not apply to level 1–5 fakes.
On an abnormal-type conflict, the higher abnormal level wins, followed by `priority`, skill level, and ID. Songs/dances are forbidden in permanent sets. The set is reapplied after death or a level change; there are no renewal tasks. A normal BUFF/PARTY_BUFF is not cast when it conflicts with a permanent effect.
### 4.7 `consumables.xml`
Root `startingAdena` defines virtual Adena for ordinary farmers (`0` by default), while `traderStartingAdena` provides a separate initial balance for persistent SELL/BUY traders (`10000000`). Ordinary fakes therefore begin without Adena and earn it from monsters, while buyers retain a working budget. Both balances are memory-only. `<consumable>` uses:
- `itemId`, `kind`: `SOULSHOT`, `SPIRITSHOT`, `BLESSED_SPIRITSHOT`, `BEAST_SOULSHOT`, `BLESSED_BEAST_SPIRITSHOT`, `ARROW`, `BOLT`, `POTION`, `OTHER`;
- `resource`: `NONE`, `HP`, `MP`, `CP`;
- `count`, `infinite`, `minLevel`, `maxLevel`; an omitted `maxLevel` or `maxLevel="server"` remains active through the server maximum;
- for potions: `useBelow`, `restorePercent`, `reuseMillis`.
The level-appropriate grade is placed in inventory. Infinite shots are logically recharged after attacks/casts, arrows/bolts are not consumed, and potions restore the resource directly while displaying the normal item animation. `BEAST_SOULSHOT` and `BLESSED_BEAST_SPIRITSHOT` belong to the summon: a visible stack is stored in the owner's MemoryInventory, but the core charges the summon directly and never consumes it.
### 4.8 `traders.xml`
Root is `<traders enabled spawnOnLoad races armorGrades weaponGrades unarmedChance>`. `races` defines the restricted default race pool. `armorGrades` and `weaponGrades` define allowed appearance-equipment grades (`NG,D,C` by default), while `unarmedChance` is the percentage chance to appear without a weapon.
There is no shared equipment tree at the `traders.xml` root. After `<point>` or `<territory>`, every `<store>` must contain its own `<equipment>` with `<weapons>`, `<armors>`, and `<jewels>` sections. There are no `<class>` or `<level>` nodes: the pool is physically owned by that store and cannot be selected by another trader. `weapons` contains weighted `<weapon id chance>` entries, while armor and jewelry use separate `<variant id chance>` entries; armor and jewelry variants of the same grade are combined during selection.
```xml
<store id="1" minLevel="15" maxLevel="19" type="SELL">
<point x="-14372" y="123575" z="-3112" heading="30535" />
<equipment>
<weapons>
<weapon id="4" chance="60" />
<weapon id="13" chance="40" />
</weapons>
<armors>
<variant id="1" chance="100">
<item id="23" count="1" equip="true" />
</variant>
</armors>
<jewels>
<variant id="1" chance="100">
<item id="909" count="1" equip="true" />
</variant>
</jewels>
</equipment>
<!-- store items or variants -->
</store>
```
Its `<pricing>` child fully controls baseline SELL pricing:
```xml
<pricing defaultMultiplier="1.0">
<equipment grade="NG" multiplier="1.0" minimumMultiplier="1.0" />
<equipment grade="D" multiplier="1.0" minimumMultiplier="0.9" />
<equipment grade="C" multiplier="1.3" minimumMultiplier="1.2" />
<equipment grade="B" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="A" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="S" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="S80" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="S84" multiplier="5.0" minimumMultiplier="5.0" />
</pricing>
```
`defaultMultiplier` applies to consumables, materials, and other items without an individual price. Weapons and armor use the `multiplier` for their grade. `minimumMultiplier` is the SELL-price floor for equipment and remains enforced even when an item has an override. Resolution order is: a positive item `price` is fixed; otherwise a positive item `priceMultiplier` overrides the baseline; otherwise `<pricing>` supplies the multiplier. The result is rounded from `referencePrice × multiplier` and is at least one Adena. BUY entries must still provide an explicit positive `price` and do not use the baseline SELL multipliers.
Each autonomous `<store id minLevel maxLevel races type budget>` creates one unique BUY or SELL store and uses exactly one placement method. A store-level `races` attribute is optional and overrides the root pool:
- `<point x y z heading>`;
- `<territory name heading>` with at least three `<zone x y zMin zMax>` vertices.
Level, race, and level-appropriate AI are selected without consulting solo/group spawns. Race is selected uniformly from the allowed pool, followed by a level-compatible profession; sex and appearance are random. For BUY and SELL traders, armor with jewelry is selected separately from the weapon and independently of character level: first an available grade from `armorGrades` is selected uniformly, then an outfit of that grade from the store's own `<store>/<equipment>`. A weapon is selected from `<store>/<equipment>/<weapons>` in `weaponGrades`, or omitted according to `unarmedChance`. Java no longer forbids particular weapon/armor types or race/class combinations: every such policy is defined by the concrete store contents. Only generic checks remain for item existence, configured grade, a visible armor outfit, and time-limited items.
The assortment is defined either by a compatible single `<items>` element or by the new block:
```xml
<variants>
<variant id="1" weight="1">
<item id="1463" count="8000" />
<item id="2510" count="8000" />
<item id="3948" count="8000" />
</variant>
<variant id="2" weight="2">
<item id="955" count="100" />
<item id="956" count="100" />
<item id="7124" count="100" />
</variant>
</variants>
```
`weight` is a relative weight, not a percentage. One variant is selected at server startup and manual reload; the others do not enter the active store but are fully validated. Variants of one store have unique numeric IDs and different item-ID sets. Every SELL variant contains at least three entries. `count` is the virtual stock or requested purchase volume, and `enchant` is the enchantment level. BUY requires a positive `price` and sufficient `budget`. For SELL, normally neither `price` nor `priceMultiplier` is needed because the common `<pricing>` rule applies. Item attributes are reserved for exceptions.
Arrows, normal HP potions, haste/alacrity/magic-haste potions, and bandages are forbidden in all SELL variants. The supplied rules preserve current live prices: D-grade equipment is `1.0x`, C is `1.3x`, and B/A/S/S80/S84 is `5x`; their floors are `0.9x`, `1.2x`, and `5x`, respectively. Repeated overrides were removed from finished equipment, while 51 intentional material/component overrides remain. Prices are checked by the loader when the item parser is available and again when the store is created.
The title is calculated from the actual selected assortment: shots have priority `[SHOTS]`; weapons/armor use `[WEAPONS]`, `[ARMOR]`, or `[EQUIPMENT]`; a scroll without shots/equipment uses `[SCROLLS]`. Therefore, a title mentioning shots, scrolls, or gear cannot appear without the corresponding item. The supplied file contains 202 stores; regular city stores have three variants, while a GM-created template may have one until it is expanded manually. Low-level towns have only 1–2 equipment SELL stores, while Giran/Goddard/Aden/Rune have more; shot grades and dropped equipment are tied to the specified towns and their farm locations.
### 4.9 `dialogues.xml`
- The file contains 100 intents with continuous IDs 1–100. Each `<intent id channels>` contains RU/EN `<trigger>` and `<response>` entries; channels are `TELL`, `ALL`, and `SHOUT`. Intents 42–100 extend replies to everyday questions and game conversations in shout.
- `<fallback language>/<response text>` is used when no exact trigger matches.
- `<conversation id language channel minLevel>` contains at least two `<line speaker delayMinMillis delayMaxMillis text>` entries.
- Substitutions: `{player}`, `{name}`, `{level}`, `{class}`.
Language is detected before trigger lookup. PM is addressed through the name index; local chat selects one eligible fake within `FakeDialogueNearbyRadius`. SHOUT receives one random active responder from the entire world regardless of coordinates. Replies and autonomous periodic SHOUT messages are delivered globally to all real players; cooldown still prevents a crowd from replying simultaneously. The listener only queues an event into a bounded queue and does not stall the network thread. `//fakes` status shows `received`, `matched`, `replies`, `sent`, `shouts`, `dropped`, and `periodic` counters.
### 4.10 TXT pools
| `names.txt` | One unique UTF-8 nickname per line, 1–16 valid characters. A name cannot repeat among active fakes or cached players. |
| `titles.txt` | One title per line; used according to the INI level and chance. |
| `sell-store-titles.txt` | Required sections `[SHOTS]`, `[SCROLLS]`, `[WEAPONS]`, `[ARMOR]`, `[EQUIPMENT]`, `[JEWELRY]`, `[RECIPES]`, `[MATERIALS]`, `[CONSUMABLES]`, `[OTHER]`, `[MIXED]`. |
| `buy-store-titles.txt` | The same required categories for BUY. |
Empty data lines, overlong values, and case-insensitive duplicates are rejected by the loader.
## 5. AI behavior
### Targeting and movement
World scanning normally runs without a usable locked target, but a hidden navigation target no longer suppresses searching until its timeout: once per `FakeBehaviorScanIntervalMillis` the AI opportunistically checks nearby candidates. Any visible valid target immediately replaces the hidden one, and the old movement is canceled without delaying the new attack. If the movement watchdog confirms that a route makes no progress, the current target is blocked for `FakeBehaviorPathFindRetryMillis`; the next scan may then select another hidden candidate and test its route. Chests, raid bosses, and their raid minions are rejected before GeoEngine and PathFinding; the ban also applies to the current target, Party/leader assist, healer defense, and retaliation. Visible candidates always take priority and are checked through GeoEngine within the batch budget. If none is visible, the nearest invisible monster within `FakeBehaviorPathFindMaxDistance` becomes a temporary navigation target: AI passes its real coordinates to the core PathFinding but starts no more than `FakeBehaviorPathFindsPerBatch` new routes. Once direct geodata visibility is restored, the target enters regular combat; on timeout or failure to start movement, the route is canceled and the target is blocked for `FakeBehaviorPathFindRetryMillis`. PvP targets are intentionally excluded from this bypass. The fake stays inside its XML farm area, returns home, patrols, follows the leader, and performs kite through the shared movement budget. Stuck `CAST`, `MOVING`, and `IDLE` states are controlled by timeout/recovery in `FakeController` and `TacticalMovement`.
During a PvP event or Olympiad, a target hidden by geodata is forcibly returned to navigation state before skill selection or autoattack. Even if that target was visible during the previous validation or came from a leader/event objective, the combat lane rechecks LOS and never attempts to cast through a wall. A full participant scan continues while routing: a newly visible legal opponent immediately replaces the hidden target, while a failed route temporarily blocks that opponent and permits another one to be selected. Competitive routes use the separate `FakeBehaviorCompetitivePathFindsPerBatch`, so background farmers cannot consume their PathFinding-start budget.
A solo farmer does not select a monster that another character or summon is actively attacking. The first solo fake briefly claims its selected target before the first hit, preventing several fakes processed in one batch from converging on the same monster. A claim is discarded when the owner changes or loses the target, dies, or reaches its timeout, and periodic cleanup requires no dedicated task. Missing HP alone never marks a monster as occupied: a damaged but genuinely abandoned monster remains eligible. This restriction does not apply to XML groups, Party assist, retaliation, PvP events, or Olympiad.
### Roles and skills
- WARRIOR/TANK/FARMER use basic attacks more often; PvE skill/debuff chances limit spam.
- DAGGER does not constantly circle a target: basic attacks take priority from the front. If the fake is already behind the target, it uses one available back/offensive skill and must return to a basic attack on its next action.
- ARCHER has infinite arrows/bolts, maintains range, and can use a regular shot. A close monster starts a mandatory kite cycle: a started retreat completes before the next attack and is not canceled by an early shot.
- MAGE uses the real range of an available nuke; debuffs are less frequent than regular offensive spells.
- HEALER/SUPPORT serve the Party first, then may attack with level-appropriate skills. Obsolete low-level attacks are filtered by XML ranges.
- FARMER remembers the corpse after spoil, approaches it, and uses `SWEEP` when the loot belongs to it or its Party.
`SkillEngine` checks skill knowledge/level, equipment, target, distance, geodata, MP/HP/CP/charges, effect absence, XML reuse, and core castability, then invokes `doCast`.
### Party and PvP
The leader publishes the primary target; the group assists the leader or protects an attacked healer/support. A healer selects mass heal when enough members are wounded, otherwise single-target heal; cleanse, recharge, resurrection, and party buffs also work. BD/SWS use available XML dances/songs only after checking that the effect is absent.
A real player who dealt damage to a fake receives priority regardless of `TargetMode` when level/peace/party/clan checks pass. A nearby flagged/PK target may be selected proactively. An equal or weaker player is attacked with certainty; chances apply to an allowed stronger player.
A solo fake has a small chance to accept a real player's Party and assist its target. The relationship ends when the leader logs out or leaves the allowed area.
### Death, town, and trading
After a delay, solo resolves the core town and respawn point through `MapRegionManager` using the home-spot coordinates, spends time moving among NPCs/trading, and returns to the farm spot. The `town` reference supplies timers, radii, and store settings but does not replace the resolved town; its coordinates are fallback. Party waits for resurrection first. Members who are not resurrected go to the resolved town; the entire group returns together with the leader. NPC movement uses a direct geodata line without PathFinding, while an obstacle is delegated to the core's bounded PathFinding.
Loot outside a Party with a real player is aggregated in `FakeInventory` up to `lootCapacity`. If a solo fake accepted the real leader's Party, items pass through core `Party.distributeItem`: `ITEM_LOOTER` sends auto-loot to the leader, RANDOM/ORDER preserve the selected Party rules, and Adena is divided among members within the allowed radius. A share assigned to a fake remains memory-only and never accesses the database. VIP-point rewards for a fake are ignored, so a missing `VipTemplate` cannot raise an error and no VIP progression is persisted for it. A temporary town SELL store selects up to `maxStoreItems`, uses `referencePrice × priceMultiplier`, and receives a category-based title. With `AuctionPrivateStoreAutoAdded=True`, entries from permanent and temporary SELL stores are registered in the core Alt+B auction, update their remaining count after a purchase, and are removed when the store closes or despawns. BUY orders are not sellable auction lots.
## 6. GM commands
| Command | Action
| `//fakes` | Full status: spawned/queued, stores, clan/alliance assignment and capacity, shots/potions, buffs, lifecycle, dialogues, target/movement budgets, and scheduler. |
| `//fakes_reload` | Full shutdown followed by INI/XML/TXT reload. |
| `//fakes_spawn <profileId>` | Spawns one existing runtime profile. |
| `//fakes_despawn <profileId>` | Removes an active or queued profile. |
| `//fakes_group_start <groupId>` | Starts a group manually. |
| `//fakes_group_stop <groupId>` | Stops a group and its lifecycle. |
| `//spawn_fake 20-30` | Atomically appends a solo location to a matching `spawn/single/<range>.xml`, selects the next global ID, town, and compatible classes, and validates the whole directory without stopping active fakes. A matching file is created automatically when needed. The new point applies after manual `//fakes_reload` or server restart. The range may not cross profession boundaries 20/40/76 or exceed the server maximum. |
| `//spawn_fake_group 76-85 [3-9]` | Adds a balanced Party; selects an exact level within the range and writes the group to a matching or automatically created `spawn/group/<range>.xml`; selects the next global ID and validates the whole directory without automatic reload. The allowed upper level equals the server maximum. The group applies after manual `//fakes_reload` or server restart. |
| `//spawn_fake_trader SELL 20-30` | Creates an autonomous exact-point SELL/BUY template at the GM coordinates in `traders.xml` with `minLevel=20`, `maxLevel=30`, the next ID, and an initial `<variants><variant id="1">`. Race comes from the root `races` pool; no spawn profile is needed. Variants 2/3 and their weights may be added while editing. Validation does not reload the running engine; the store applies after `//fakes_reload` or restart. Extra arguments are rejected. |
## 7. Validation and common errors
Loading stops before spawning on an unknown INI key, invalid boolean/number/enum, XSD error, duplicate ID/name, unknown town/class/skill/item/race, unknown custom skill level, absence of a trader profession in the configured range, a gap in buff-level coverage, a `<shield>` item that is not physically a left-hand shield, an invalid Party leader count, insufficient BUY budget, invalid Min/Max, or missing AI/equipment for a level. Class/equipment compatibility is deliberately not validated here and is fully controlled by XML.
`CacheCharNames=True` is required: name collisions must be checked in memory without a database query.
## 8. Protected production build
Obfuscation is applied only to the standalone `l2e-fakeplayers.jar`; the HF5/Salvation core and datapack are not modified. Run `tools/Install-ProGuard.ps1` once, then use `tools/Build-Protected.ps1` or `ant protected`. The toolchain pins ProGuard 7.10.0, verifies the downloaded archive SHA-256, and supports Java 25 bytecode.
The regular `build-*/l2e-fakeplayers.jar` remains the diagnostic build. Deploy only `build-*/protected/l2e-fakeplayers.jar`. Keep `build-*/obfuscation/mapping.txt`, `seeds.txt`, and `effective.pro` owner-only: `mapping.txt` is required to retrace production stack traces and must never be placed on the server or shared with customers.
The production profile keeps only `l2e.fakeplayers.integration.FakeListener` at a stable name because its fully qualified name is stored in `META-INF/services`. All other classes, fields, and methods are renamed and implementation classes are repackaged. Enum constants remain stable because their names form part of the INI/XML contract. Shrinking and bytecode optimization are deliberately disabled so dynamically used paths cannot be removed and AI runtime performance remains unchanged.
Obfuscation raises the cost of decompilation but cannot make Java bytecode executed on somebody else's machine mathematically inaccessible. Source code, the regular JAR, and mapping files must remain in a private repository. A later protection tier may add commercial string/control-flow protection and per-customer build watermarking; an online licensing dependency inside the critical GameServer process is not recommended.
### Summoners and herbs
- Warlock/Arcana Lord, Elemental Summoner/Elemental Master, and Phantom Summoner/Spectral Master summon a level-appropriate combat servitor from `class-ai.xml`.
- The owner and summon attack the same target. In PvE, the owner prefers regular weapon attacks and may use configured combat skills between attacks.
- Entries with `target="SUMMON"` heal the summon below `hpBelow` and apply missing class buffs.
- On creation, the summon receives a permanent set from `buff-sets.xml` based on the owner's level. There are no renewal tasks; effects remain until death or summon removal.
- The summon automatically and infinitely uses Beast Soulshot for physical attacks and Blessed Beast Spiritshot for magic. After every charge reset, the core immediately charges the next one in the same combat flow, without a separate task or item handler.
- If the summon dies or disappears during farming, the shared tick removes the old object and immediately prioritizes the XML `SUMMON` skill. If the core skill reuse has not finished, the attempt repeats on regular AI ticks. The new summon appears with full HP/MP and receives the complete permanent `buff-sets.xml` set again.
- Fake summons and reagents exist only in memory. Lifetime is handled by the owner's shared AI tick; summon, effect, and reuse data are never written to the database.
- Herbs are always auto-looted and immediately applied by the core handler to the owner and living summon without occupying inventory. A herb cannot replace a permanent buff in the same abnormal group.
Документация
Документ описывает отдельный безбазовый модуль фейк-игроков для HF5 и Salvation.
## 1. Назначение и основные гарантии
- Сборка требует Java 25
- `FakePlayer` наследуется от штатного `Player`, поэтому видим клиенту как обычный персонаж и использует движение, геодату, Party, касты, private store и сетевые пакеты ядра.
- Профили, навыки, экипировка, расходники, лут и торговые остатки существуют только в памяти. Модуль не содержит DAO, `DatabaseFactory`, JDBC или SQL.
- Сохранение персонажа, эффектов, инвентаря и навыков фейка отключено. После рестарта состояние строится заново из INI, XML и TXT.
- Поддерживаются профессии 0–3: classId `0–57`, `88–118`, `123–136`.
- Solo-фармеры и организованные Party-группы являются двумя независимыми системами спавна.
## 2. Размещение, сборка и запуск
Стандартные пути относительно рабочей папки GameServer:
Назначение | Путь
Главный конфиг | `config/mods/fakeplayers.ini`
Игровые XML/TXT | `data/stats/services/fakeplayers/`
Модуль | `libs/l2e-fakeplayers.jar`
## 3. Полный справочник `fakeplayers.ini`
### 3.1 Запуск и scheduler
`FakeEngineEnabled` | `True` | Главный выключатель. При `False` читается только `fakeplayers.ini`; XML, TXT и XSD не открываются, runtime и интеграции не запускаются. GM-handler остаётся доступным для статуса и `//fakes_reload`.
`FakeEngineSpawnOnLoad` | `True` | Автоматически запустить включённые solo-точки и группы после старта.
`FakeEquipmentStarterMaxLevel` | `8` | Максимальный уровень обычного фейка, на котором используется штатный комплект создания персонажа вместо `equipment.xml`. Допустимый диапазон — `0..максимальный уровень сервера`; `0` включает XML-экипировку уже с 1 уровня. На трейдеров не влияет.
`FakeClanlessMaxLevel` | `20` | Максимальный уровень включительно, до которого фейку запрещено назначать клан. При `20` уровни 1–20 всегда остаются без клана, с 21 уровня назначение разрешено. `0` отключает ограничение. Если в XML-пати есть хотя бы один участник под ограничением, вся пати остаётся без клана, чтобы сохранить единый клановый статус группы.
`FakeCommunityStatisticsPlayers` | `True` | Добавлять активных фейков в счётчик онлайна и рейтинги Community Board по PvP, PK, PC Bang, адене и времени онлайн. Рейтинг объединяется с результатами реальных игроков только в памяти, без записи фейков в БД.
`FakeCommunityStatisticsClans` | `True` | Добавлять активные кланы фейков в счётчик и клановый рейтинг Community Board. Учитываются только кланы, чей текущий лидер является фейком.
`FakeStatisticsPvpMin` / `FakeStatisticsPvpMax` | `0 / 30` | Включительный диапазон случайного стартового PvP для каждого фейка.
`FakeStatisticsPkMin` / `FakeStatisticsPkMax` | `0 / 30` | Включительный диапазон случайного стартового PK для каждого фейка.
`FakeStatisticsPcBangMin` / `FakeStatisticsPcBangMax` | `0 / 10000` | Случайные PC Bang очки. Выдаются только при `PcBangPointEnable=True` и ограничиваются штатным `MaxPcBangPoints`.
`FakeStatisticsOnlineMinutesPerLevelMin` / `FakeStatisticsOnlineMinutesPerLevelMax` | `5 / 60` | Диапазон имитируемых минут сессии на один уровень. Результат умножается на уровень фейка и выбирается независимо, поэтому персонажи одного уровня не получают одинаковый онлайн. После спавна штатный таймер продолжает увеличивать значение.
`FakeSchedulerTickMillis` | `100` | Период stepping-менеджера. Минимум `25` мс.
`FakeSchedulerBatchSize` | `50` | Максимум контроллеров за один AI-batch. Минимум `1`; базовое значение рассчитано на 500 фейков.
`FakeSchedulerCompetitiveBatchSize` | `32` | Приоритетная квота фейков активных PvP-ивентов и Олимпиады перед фоновой round-robin полосой, `1..FakeSchedulerBatchSize`. Это не отдельный поток и не дополнительный временной бюджет: обе полосы делят один `FakeSchedulerMaxBatchMillis`, один scan/geo/pathfinding budget, а competitive-фейк не обрабатывается повторно как фоновый в том же batch.
`FakeSchedulerMaxBatchMillis` | `20` | Временной бюджет одного batch. Диапазон `1..FakeSchedulerTickMillis`.
`FakeSchedulerSpawnBatchSize` | `2` | Максимум новых фейков за один spawn-batch; минимум `1`.
### 3.1.1 Автодобавление на PvP-ивенты
`FakeEventAutoFillEnabled` | `True` | При закрытии регистрации дополнять PvP-ивент уже заспавненными подходящими фейками. Новые объекты не создаются, БД не используется, трейдеры и фейки в городском режиме не забираются. На командный ивент целая активная XML-пати может быть перенесена в одну event-команду; недостающие места балансируются solo-фейками. Для каждого участника проверяются `validLevels`, `validProffs`, `excludedClasses` и остальные штатные условия ивента. Если хотя бы один член XML-пати не подходит, занята не вся пати или её размер не помещается в одну команду, группа пропускается целиком.
`FakeEventAutoFillMinimumRealPlayers` | `1` | Минимум реальных участников для включения автодобавления. `0` разрешает полностью искусственный ивент.
`FakeEventAutoFillMinimumParticipants` | `10` | Минимальное желаемое число участников для одиночных режимов и нижняя граница для командных. Итог командного режима дополнительно определяется `FakeEventAutoFillPartiesPerTeam`.
`FakeEventAutoFillPartiesPerTeam` | `3` | Желаемое количество стандартных групп на каждую команду. Целевой состав равен `число команд × значение × PartyLimit`; если он превышает `maxAllPlayers` карты, используется наибольший допустимый сбалансированный состав карты.
`FakeEventAutoFillMaximumFakes` | `54` | Предохранительный максимум добавленных фейков на один ивент; `0` фактически запрещает добавление. Значение `54` позволяет полностью собрать по три группы в двух командах, когда карта это допускает.
`FakeEventPhysicalOffensiveSkillChance` | `35` | Шанс попытки атакующего навыка физом на одном боевом решении активного PvP-ивента, `0..100`. Если подходящий навык недоступен или находится в откате, AI без ожидания переходит к движению либо обычной атаке оружием. Для обычного PvP и Олимпиады есть отдельный behavior-параметр.
`FakeEventPhysicalDebuffSkillChance` | `15` | Шанс попытки физического контроля/дебафа на одном решении ивента, `0..100`. Вместе с предыдущим параметром не даёт танкам, Blade Dancer, Sword Singer, лучникам и другим физам бесконечно прокручивать навыки вместо ударов оружием.
`FakeEventPatrolDistanceMin` / `FakeEventPatrolDistanceMax` | `1000 / 2000` | Диапазон одного случайного перемещения по активной зоне ивента, когда нет доступного врага или обязательной цели. Перед стартом проверяются границы event-zone, геодата и закрытые двери; непроходимая точка не используется.
`FakeEventPatrolIntervalMinMillis` / `FakeEventPatrolIntervalMaxMillis` | `3000 / 7000` | Случайный интервал между успешными патрульными перемещениями. При неудачном выборе точки повтор выполняется быстрее; появление видимого противника немедленно отменяет патруль.
`FakeEventAutoFillTypes` | список PvP-режимов | Допустимые Java-имена реализаций через запятую/точку с запятой/пробел. По умолчанию включены обычные и объектные PvP-события: Death Match, Last Hero, TvT, TvT Round, Korean Style, обе PvP Zone, Capture The Flag, Base Capture, Domination и Treasure Hunt. Для CTF/Base/Domination/Treasure используется отдельный event-AI флага, базы, зоны и сундуков.
На обычном ивенте заполнение происходит при закрытии регистрации. В глобальных `SoloPvpZoneEvent`/`TeamPvpZoneEvent` — после входа первого реального игрока; при `MinimumRealPlayers=0` заполнение возможно сразу после старта. В командном режиме XML-пати назначается одной команде атомарно, затем solo-фейки распределяются в наименее заполненные команды. Prophet и Hierophant никогда не выбираются. В одной переносимой XML-пати допускается не более одного healer; при составлении event-команд общее число healer ограничивается числом итоговых групп, поэтому в каждой группе получается не более одного, а группа без healer остаётся допустимой. Итоговое число участников выбирается кратным числу команд; если вместимость карты или количество подходящих фейков меньше цели, система берёт ближайший меньший сбалансированный состав, а не создаёт перекос. Фейк проверяет врага через `event.canAttack`, ассистит временному лидеру, не атакует свою команду и лечит, очищает, восстанавливает MP и бафает доступных союзников. Навыки одиночного и массового воскрешения на ивенте заблокированы центрально: смерть, респавн и задержка возврата обслуживаются только механикой самого ивента. На соло-ивент XML-пати не забирается, каждый другой зарегистрированный участник считается противником. Во время подготовки AI ждёт; в активном бою раз в секунду подтверждает свою активность штатному AFK-контролю, поэтому не удаляется раньше завершения матча. Только после фактического телепорта обратно фейк восстанавливает постоянные бафы и продолжает обычный фарм.
Перед использованием HP-, CP- или MP-банки фейк проверяет штатное `event.canUsePotion`. Если правила конкретного ивента запрещают банки, фейк их не использует.
После старта боя включается отдельный event-AI. На Death Match, Last Hero, TvT, TvT Round и PvP Zone фейк ищет разрешённого правилами врага по всей карте, а не только в обычном farm scan radius. Дальняя цель удерживается до появления прямой геовидимости и достигается через штатный PathFinding. Попадание скрытой стеной цели в формальный радиус атаки больше не завершает навигацию: маршрут продолжается до реальной геовидимости. Новый невидимый противник прерывает прежний патруль или другое несвязанное перемещение и сразу становится целью обхода. После неудачного маршрута эта цель временно исключается, чтобы фейк не повторял движение в ту же стену. Когда доступной цели нет, лидеры с заданным интервалом патрулируют случайные проходимые точки в радиусе `1000..2000` внутри активной зоны, а участники временной Party следуют за лидером. Во время патруля поиск целей продолжается, и найденный противник немедленно прерывает движение. CTF умеет брать и возвращать флаг, а свободные союзники сопровождают своего носителя; Base Capture атакует базу или применяет capture skill; Domination занимает активную зону; Treasure Hunt ищет и открывает живые сундуки. В Korean Style двигаются и сражаются только выбранные дуэлянты, остальные участники не вмешиваются. Ближний видимый противник временно важнее не срочной объектной цели. Lucky Creatures и Monster Attack распознаны как PvE-режимы и намеренно не входят в стандартный список автозаполнения.
### 3.1.2 Безопасная интеграция в олимпиаду
`FakeOlympiadAutoFillEnabled` | `False` | Главный переключатель автодобавления уже заспавненных solo-фейков в штатные очереди олимпиады. По умолчанию выключен.
`FakeOlympiadNonClassedEnabled` | `True` | Разрешить фейков во внеклассовых боях один на один.
`FakeOlympiadClassedEnabled` | `True` | Разрешить фейков в классовых боях один на один. Базовый класс фейка обязан точно совпадать с базовым классом ожидающего реального игрока.
`FakeOlympiadTeamsEnabled` | `True` | Разрешить синтетическую команду в боях три на три. Состав всегда содержит ровно трёх фейков и не более одного healer.
`FakeOlympiadAutoFillMinimumRealPlayers` | `1` | Минимум реальных игроков в очереди 1x1 или реальных команд в очереди `TEAMS` до попытки дополнения.
`FakeOlympiadAutoFillMaximumFakes` | `1` | Общий максимум одновременно зарегистрированных временных фейков для `NON_CLASSED` и `CLASSED`.
`FakeOlympiadAutoFillMaximumTeamFakes` | `3` | Отдельный максимум фейков для командной олимпиады. Значение должно быть не меньше трёх при включённом `FakeOlympiadTeamsEnabled`.
`FakeOlympiadRealPlayerKillPoints` | `1` | Фиксированные очки только за фактическую смерть фейка. В командном бою после полного убийства команды фейков значение один раз получает каждый выживший реальный участник. Победа по времени, неявке или ничья очков не дают. Значение `0` отключает награду, а превышение ограничивается штатным `AltOlyMaxPoints`.
`FakeOlympiadRegistrationTimeoutMillis` | `300000` | Максимальное ожидание в очереди. По истечении времени снимается только ещё не выбранный в матч фейк; сформированный и активный бой не прерывается.
Один реальный игрок в `NON_CLASSED` получает подходящего фейка напрямую. В `CLASSED` дополнение происходит только при наличии свободного фейка с тем же `baseClass`. В `TEAMS` одна зарегистрированная реальная тройка получает отдельную тройку фейков; смешанные составы и матчи «фейки против фейков» запрещены в ядре. Кандидат должен находиться в solo FARM-режиме, не состоять в Party, быть живым, свободным от торговли/ивента/другой олимпиады и соответствовать фактическим `ClassRegisterParams`. Требование noblesse сохраняется, кроме серверного режима `AllowRegWithouNobleStatus=True`.
Регистрация фейка временная и не вызывает `Olympiad.addNoble`: его статистика существует только внутри объекта матча. Фейк не получает и не теряет очки, а результат с ним не записывается в таблицу боёв и не участвует в выборе героя. Настоящая статистика реального игрока получает результат и расход недельного боя соответствующего типа; поражение от фейка очки не снимает, предметные награды, достижения и квестовые callbacks не вызываются.
Приглашение на телепортацию каждый синтетический участник подтверждает автоматически; реальные игроки по-прежнему подтверждают вход сами. После переноса фейк получает пять навыков штатной группы `SupportType.OLYMPIAD`: магический либо физический набор из актуального `supportMagic.xml`; тот же набор применяется живому саммону. Во время предбоевого отсчёта фейк вызывает саммона, накладывает селфы и после открытия дверей занимает рабочую дистанцию без преждевременной атаки. Невидимый по геодате соперник сохраняется как navigation target и до старта, и в активном бою; фейк строит обход, но атаковать до штатного начала боя не может. В командном бою healer/support определяет союзников по совпадающим `gameId` и `olympiadSide`, лечит, очищает, восстанавливает MP и бафает их даже после штатного роспуска Party. Массовый party-heal не используется без реальной Party, вместо него применяется точечное лечение. HP-, CP- и MP-банки запрещены; заряды, стрелы и болты работают. Воскрешение запрещено на всём олимпийском цикле. После возврата восстанавливаются постоянные бафы и обычный FARM-режим.
### 3.2 Поиск и проверка целей
`FakeBehaviorTargetMode` | `MONSTERS` | Базовые цели: `MONSTERS`, `PLAYERS` или `BOTH`. Ответ атакующему и разрешённый PvP имеют приоритет над этим режимом.
`FakeBehaviorExcludedNpcIds` | `18793` | Список ID шаблонов NPC, которых нельзя выбирать, принимать по ассисту или атаковать в ответ. Разделители: запятая, точка с запятой или пробел; пустое значение отключает список.
`FakeBehaviorScanRadius` | `2000` | Радиус поиска от текущей позиции; больше `0`. Скан запускается при отсутствии пригодной удерживаемой цели.
`FakeBehaviorScanHeight` | `600` | Максимальная вертикальная разница кандидата; больше `0`.
`FakeBehaviorScanIntervalMillis` | `1000` | Интервал повторного поиска без цели/при недоступной цели; `100..1000` мс.
`FakeBehaviorScanBatchLimit` | `50` | Общий лимит world-scan за batch; не меньше `FakeSchedulerBatchSize`.
`FakeBehaviorGeoChecksPerBatch` | `250` | Лимит проверок видимости целей; не меньше `batchSize × (geoCandidatesPerScan + 1)`.
`FakeBehaviorGeoCandidatesPerScan` | `4` | Число ближайших кандидатов для проверки GeoEngine; минимум `1`.
`FakeBehaviorMovementGeoChecksPerBatch` | `50` | Лимит проверок геодаты движения; не меньше `FakeSchedulerBatchSize`.
`FakeBehaviorPathFindingEnabled` | `True` | Разрешает bounded-обход препятствия к невидимой подходящей цели: монстру на фарме, assist-цели лидера группы, противнику PvP-ивента или Олимпиады. Требует `PathFindBoost=True` в `main/geodata.ini`.
`FakeBehaviorPathFindsPerBatch` | `2` | Лимит новых фоновых PathFinding-маршрутов на AI-batch; минимум `1`.
`FakeBehaviorCompetitivePathFindsPerBatch` | `8` | Отдельный лимит новых маршрутов ивента/Олимпиады на batch, `1..FakeSchedulerCompetitiveBatchSize`. Не расходуется обычным фармом.
`FakeBehaviorPathFindMaxDistance` | `2000` | Максимальная дистанция до невидимого монстра; `1..FakeBehaviorScanRadius`.
`FakeBehaviorPathFindRetryMillis` | `5000` | Backoff перед повторным выбором недоступной цели; минимум `1000` мс.
`FakeBehaviorPathFindTimeoutMillis` | `15000` | Время на выход к прямой геовидимости; от retry до `60000` мс.
`FakeBehaviorTargetValidationIntervalMillis` | `1000` | Повторная проверка видимости удерживаемой цели; `100..1000` мс.
### 3.3 Движение и бой
`FakeBehaviorLeashRadius` | `2500` | Глобальный предел пригодности цели от центра фарма; не меньше scan radius. XML `distance` дополнительно задаёт границу конкретного спавна: минимум 500 для solo и 1000 для group. |
`FakeBehaviorMeleeRange` | `80` | Предпочтительная дальность обычной ближней атаки.
`FakeBehaviorPoleSkillMaxRange` | `180` | Жёсткий предел массовых pole/AURA-навыков до основной цели; минимум `1`.
`FakeBehaviorPveWarriorOffensiveSkillChance` | `25` | Шанс атакующего навыка WARRIOR/TANK/FARMER/ARCHER/HYBRID_SUPPORT в PvE, `0..100`; PvP/Олимпиада и ивенты имеют отдельные параметры. DAGGER использует отдельный физический цикл. С надетым луком/арбалетом действует ARCHER независимо от исходной роли. Готовый обычный PvE-выстрел приоритетнее навыка.
`FakeBehaviorPveWarriorDebuffSkillChance` | `12` | Шанс физического дебафа в PvE, `0..100`.
`FakeBehaviorPvpWarriorOffensiveSkillChance` | `35` | Шанс атакующего навыка физической роли против игрока в обычном PvP и на Олимпиаде, `0..100`. Если навык недоступен, невалиден или в откате, AI сразу продолжает движением либо обычной атакой оружием.
`FakeBehaviorPvpWarriorDebuffSkillChance` | `15` | Шанс контроля/дебафа физической роли в обычном PvP и на Олимпиаде, `0..100`. На PvP-ивенте вместо него используется `FakeEventPhysicalDebuffSkillChance`.
После принятого атакующего навыка физический класс ставит обычную атаку в продолжение каста. Переход выполняется непосредственно по штатному `EVT_FINISH_CASTING`, а резервная проверка контроллера сохраняет удар при мгновенном навыке или занятой очереди ядра. Завершившийся боевой подбег отдельно сбрасывает остаток `actionIntervalMillis`: удар или навык начинается на ближайшем тике task manager, а не после полного общего интервала.
Персонаж с пикой открывает бой обычной атакой и только после установленной автоатаки подключает массовые навыки. Orc Mystic, Shaman, Overlord, Warcryer, Dominator и Doom Cryer на PvP-ивенте используют такой же физический старт, после чего чередуют удары, атакующие навыки и дебаффы. Необязательные party-бафы healer/support/hybrid-support больше не прерывают уже найденного противника или активный бой; лечение, cleanse и восстановление MP сохраняют приоритет.
`FakeBehaviorPveMageDebuffSkillChance` | `10` | Шанс магического дебафа в PvE; обычные nukes остаются приоритетнее, `0..100`.
`FakeBehaviorRangedRange` | `900` | Резервная желаемая дистанция лучника/мага; фактический cast range навыка имеет приоритет.
`FakeBehaviorKiteDistance` | `350` | Длина резервного шага kite.
`FakeBehaviorFormationRange` | `500` | Радиус следования/построения Party вокруг лидера.
`FakeBehaviorWanderRadius` | `900` | Максимальный шаг случайного патруля без цели, дополнительно ограниченный farm area.
`FakeBehaviorWanderIntervalMillis` | `10000` | Базовый интервал патруля; минимум `1000` мс.
`FakeBehaviorWanderJitterMillis` | `5000` | Случайная добавка к интервалу патруля; неотрицательная.
`FakeBehaviorActionIntervalMillis` | `650` | Минимальный интервал боевого решения одного контроллера; минимум `100` мс. Значение 650 немного повышает активность относительно прежних 750 мс без увеличения частоты world-scan.
`FakeBehaviorBuffCheckIntervalMillis` | `3000` | Интервал проверки классовых buff/aura/party buff; минимум `100` мс.
`FakeBehaviorFormationUpdateIntervalMillis` | `1500` | Интервал обновления следования/formation; минимум `100` мс.
`FakeBehaviorRespawnDelayMillis` | `10000` | Задержка solo-восстановления после смерти; минимум `1000` мс, затем фейк направляется в город.
`FakeBehaviorPartyReviveWaitMinMillis` | `10000` | Минимальное ожидание resurrection членом группы; минимум `1000` мс.
`FakeBehaviorPartyReviveWaitMaxMillis` | `20000` | Максимальное ожидание; не меньше минимального. После истечения — восстановление в городе.
### 3.4 Party, heal и support
`FakeBehaviorHealBelow` | `70` | HP% для точечного heal/emergency; `0..100`. XML `hpBelow` конкретного навыка также учитывается.
`FakeBehaviorSupportMpBelow` | `35` | MP% для recharge/support; `0..100`.
`FakeBehaviorMassHealMembers` | `2` | Минимум раненых живых участников для mass heal; не меньше `2`.
`FakeBehaviorMassResurrectMembers` | `2` | Минимум мёртвых участников для mass resurrection; не меньше `2`.
`FakeBehaviorDamageTrackerCapacity` | `8` | Фиксированное число запоминаемых атакующих на фейка; `1..32`.
`FakeBehaviorDamageMemoryMillis` | `15000` | TTL записи нанесённого урона/defensive assist; минимум `1000` мс.
`FakeBehaviorSummonAssist` | `True` | Существующий summon атакует текущую цель владельца.
`FakeBehaviorPartyAssist` | `True` | Участники XML-группы следуют опубликованной цели лидера.
`FakeBehaviorProtectHealer` | `True` | Атакующий healer, либо support при отсутствии healer, становится защитной приоритетной целью группы.
`FakeBehaviorRealPlayerPartyAcceptChance` | `3` | Шанс solo-фейка принять приглашение реального игрока, `0..100`.
`FakeBehaviorRealPlayerPartyInviteCooldownMillis` | `300000` | Задержка между рассмотрениями приглашений; минимум `1000` мс.
`FakeBehaviorRealPlayerPartyCheckIntervalMillis` | `2000` | Проверка состояния Party с реальным лидером; минимум `250` мс.
`FakeBehaviorRealPlayerPartyLeaveTolerance` | `500` | Допуск сверх farm/formation range до выхода из Party; неотрицательный.
### 3.5 PvP-реакция
`FakeBehaviorEngageFlaggedPlayers` | `True` | Разрешает упреждающую атаку flagged/PK-кандидатов. Ответ реальному игроку, уже нанёсшему урон, обрабатывается отдельно.
`FakeBehaviorFlaggedPlayerRadius` | `1200` | Радиус специального PvP-скана; `100..FakeBehaviorLeashRadius`.
`FakeBehaviorFlaggedPlayerScanIntervalMillis` | `1000` | Интервал PvP-скана; `100..1000` мс.
`FakeBehaviorFlaggedPlayerMaxLevelDifference` | `5` | Игрок может быть максимум на это число уровней выше фейка; значение неотрицательное.
`FakeBehaviorFlaggedPlayerSoloChance` | `50` | Шанс solo-фейка атаковать flagged/PK игрока на 1–N уровней выше, `0..100`. Равный/более слабый атакуется со 100%.
`FakeBehaviorFlaggedPlayerPartyChance` | `100` | Аналогичный шанс для лидера fake Party, `0..100`.
`FakeBehaviorTargetOtherFakes` | `False` | Разрешает выбирать чужих нефлагнутых фейков как обычные цели. Флагнутые/PK-фейки и фактические нападавшие обрабатываются PvP-правилами независимо от параметра; участники своей серверной Party или одной spawn-group всегда исключены.
`FakeBehaviorRespectAutoAttackable` | `False` | При `True` дополнительно требует положительный штатный `isAutoAttackable`; может ограничить имитационный PvP.
### 3.6 Имена и титулы
`FakeIdentityTitleMinLevel` | `60` | Минимальный уровень случайного титула; от `1` до штатного максимума сервера.
`FakeIdentityTitleChance` | `35` | Шанс титула с указанного уровня, `0..100`. Перед выдачей титула фейк получает noblesse.
### 3.7 Чат и диалоги
`FakeDialogueEnabled` | `True` | Главный выключатель DialogueManager.
`FakeDialogueNearbyRadius` | `900` | Радиус выбора отвечающего фейка для ALL и собеседника автономного разговора; все сообщения SHOUT доставляются глобально.
`FakeDialogueReplyDelayMinMillis` | `1500` | Минимальная задержка ответа игроку.
`FakeDialogueReplyDelayMaxMillis` | `5000` | Максимальная задержка ответа; должна быть не меньше минимальной.
`FakeDialoguePlayerCooldownMillis` | `20000` | Cooldown одного реального отправителя против повторных ответов.
`FakeDialogueFakeCooldownMillis` | `12000` | Cooldown одного отвечающего фейка.
`FakeDialogueMaxPendingReplies` | `256` | Вместимость ограниченной очереди отложенных реплик.
`FakeDialogueMaxRepliesPerBatch` | `4` | Максимум отправляемых реплик за один dialogue tick.
`FakeDialogueFakeConversations` | `True` | Разрешает сценарии conversation между фейками.
`FakeDialogueFakeConversationChance` | `35` | Шанс начать автономный сценарий при проверке, `0..100`.
`FakeDialogueFakeConversationMinMillis` | `120000` | Минимальный интервал между попытками conversation.
`FakeDialogueFakeConversationMaxMillis` | `300000` | Максимальный интервал; не меньше минимального.
`FakeDialoguePeriodicMessages` | `True` | Разрешает одиночные периодические сообщения для эффекта живого чата.
`FakeDialoguePeriodicMessageMinMillis` | `45000` | Минимальный интервал периодической реплики.
`FakeDialoguePeriodicMessageMaxMillis` | `90000` | Максимальный интервал; не меньше минимального.
Фейк, временно занятый PvP-ивентом или олимпиадой, не выбирается для автономного разговора, периодической реплики либо публичного ответа в `ALL`/`SHOUT`. Уже поставленная в очередь публичная реплика отбрасывается, если к моменту отправки фейк вошёл в один из этих режимов. Адресный ответ в `TELL` остаётся разрешённым.
## 4. XML и TXT данные
### 4.0 `clans.xml` и `crests/`
Корень `<clans enabled>` включает полностью внутрипамятные кланы фейков. `<alliance id name crest>` задаёт локальный числовой ID, отображаемое имя и закреплённый 8×12 8-bit BMP-герб альянса. `<clan id name level reputation maxFakes allianceId crest>` задаёт имя, отображаемый уровень и репутацию клана, лимит его фейков, ссылку на альянс и закреплённый 16×12 8-bit BMP-герб. `allianceId="0"` означает независимый клан. Репутация применяется через штатный `Clan` только в памяти с `save=false`.
Гербы лежат в `data/stats/services/fakeplayers/crests`; имя файла указывается явно и поэтому не рандомизируется после рестарта. Загрузчик строго проверяет L2-совместимый BMP, дополняет его высоту с 12 до требуемых движком 16 пикселей и штатным `DDSConverter` ядра преобразует в DDS/DXT1: 256 байт для клана 16×16 и 192 байта для альянса 8×16. Видимая область исходного герба остаётся 16×12/8×12. Клиентский crest ID стабильно вычисляется из начального номера BMP в безопасных диапазонах `51 000 + catalogId` для клана и `61 000 + catalogId` для альянса. Текущий набор содержит 26 кланов: 16 объединены в четыре альянса, 10 независимы; общая вместимость — 2400 фейков. Все четыре клана одного альянса используют одинаковый clan crest и общий alliance crest, поэтому составная эмблема едина для всего альянса; независимые кланы имеют разные гербы. Новый solo-фейк случайно выбирает одно из оставшихся свободных мест, поэтому `maxFakes` соблюдается, а клановые и альянсовые пары остаются постоянными. При исчерпании общей вместимости лишние фейки остаются без клана, что видно в `//fakes` как `clans.unassigned`.
`FakeClanManager` регистрирует кланы и гербы в штатных holders только на время работы сервера, чтобы `CharInfo`, pledge-info и crest-пакеты показывали их обычным клиентам. Создание, участники, лидерство и удаление не выполняют INSERT/UPDATE/DELETE; при despawn член удаляется из памяти, при shutdown временные кланы, гербы и ID освобождаются. Имена обязаны быть уникальными, алфавитно-цифровыми и длиной 2–16 символов; level — `0..11`, reputation — неотрицательная, `maxFakes` — положительный. Загрузчик проверяет ссылки альянсов, наличие файлов, BMP-сигнатуру, размеры и 8-bit глубину до запуска фейков.
### 4.1 `towns.xml`
Корень `<towns enabled lootCapacity>` включает городское поведение и ограничивает число разных типов накопленного лута. Каждый `<town>` задаёт:
- `id` — ссылка на набор параметров городского поведения;
- `x/y/z`, `heading` — резервная точка, используемая только если ядро не определило MapRegion домашнего спавна;
- `npcRadius`, `npcHeight` — поиск NPC;
- `visitMinMillis/visitMaxMillis` — интервал между визитами;
- `stayMinMillis/stayMaxMillis` — длительность визита;
- `moveMinMillis/moveMaxMillis` — пауза между переходами к NPC;
- `storeChance`, `storeMinMillis/storeMaxMillis`, `maxStoreItems`, `priceMultiplier` — временная SELL-лавка.
Все Min/Max пары упорядочены; проценты находятся в `0..100`, радиусы и ёмкости положительны.
После списка городов находятся семь `<peaceCombatZone id>` с вершинами `<zone x y zMin zMax>`. Это точные полигоны гремлинов для Human Fighter, Human Mystic, Elf, Dark Elf, Orc, Dwarf и Kamael. Если фейк находится внутри такого полигона, зона PEACE не включает городской режим и не блокирует PvE; целью может быть только монстр внутри того же полигона. Игроки в PEACE никогда не становятся целью, а во всех остальных мирных зонах сохраняется обычное городское поведение.
### 4.2 `spawn/single/*.xml` — solo-система
Каталог изначально содержит файлы `01-10.xml`, `10-20.xml`, `20-30.xml`, `30-40.xml`, `40-50.xml`, `50-60.xml`, `60-70.xml`, `70-80.xml`, `80-85.xml`. Загрузчик принимает дополнительные XML с именем `<min>-<max>.xml` (например, `86-100.xml`), а ID location проверяются на уникальность глобально. Максимальный уровень берётся из штатного серверного `MaxPlayerLevel` (`Config.PLAYER_MAXIMUM_LEVEL - 1`), а не фиксируется системой фейков. Каждый файл задаёт собственный независимый lifecycle через корневые `cycle`, `peaceMinutes`, `battleMinutes`, поэтому разные диапазоны уровней могут иметь разную длительность фарма и отдыха. При `cycle=false` solo-фейки данного файла работают постоянно; при `cycle=true` активная и мирная фазы файла чередуются. Все lifecycle обслуживаются одним общим scheduler и не создают отдельные потоки.
`<location>`:
| Поле | Значение |
|---|---|
| `id` | Уникальный положительный числовой ID. |
| `enabled`, `amount` | Включение и количество независимых фейков. |
| `distance` | Farm/leash радиус: не меньше 500 для solo location и 1000 для group spawn. |
| `spawnRadius` | Первичное случайное размещение; default `min(distance, 200)`. |
| `town` | Обязательная ссылка на набор параметров визита в `towns.xml`; город респавна определяется отдельно через MapRegion исходных координат. |
| `<coords x y z heading>` | Центр; `heading=-1` рандомизируется. |
| `<class id>` | ClassId через `;` или `,`; пустой список включает автоматический подбор по уровню. |
| `<level min max>` | Включительный диапазон `1..максимальный уровень сервера`; `max="server"` означает динамическую верхнюю границу. |
Допустимы overrides `account`, `ai`, `female`, `role`, а также `appearance`, `tactics`, `items`, `hennas`, `social`, `skills`. В solo запрещены HEALER, Prophet 17 и Hierophant 98. Профили получают ID вида `solo_loc_<location>_<index>`.
#### Проверка места спавна по геодате
Перед созданием персонажа `SpawnLocationSelector` проверяет выбранную точку. Для solo сохраняется исходный `spawnRadius`, для party — `spawn.radius`; больший радиус фарма `distance` для подбора не используется. Проверяется наличие геодаты, высота поверхности (поправка не более 128), NSWE и свободное пространство на 24 координатные единицы вокруг точки, включая диагонали. Перепад пола в этом пространстве допускается до 32. Для solo/party дополнительно проверяется прямой проход по гео от центра XML и обратно: точка за стеной или на несвязанном этаже не принимается.
Если предварительная точка не подходит, выполняется не более 64 случайных попыток в исходной области. Затем для solo/party проверяется сам центр. Если безопасное место не найдено (в том числе при отключённой/отсутствующей геодате), используется **точная исходная точка XML, включая Z**, без случайного смещения. В лог пишется `no geo-safe spawn found; using XML coordinates`. Этот явно заданный fallback не гарантирует отсутствие стены в самой XML-точке.
Точечная лавка сохраняет XML X/Y, при успешной проверке корректируется только Z; при неудаче используются исходные XYZ. Для зонной лавки подбирается точка внутри полигона и его `zMin..zMax`. У полигона нет единого центра спавна: при неудаче fallback — первая XML-вершина `<zone>` с её `zMin`, с предупреждением в логе.
Проверки выполняются только при спавне в существующей очереди, без новых потоков, A*/PathFinding или запросов в БД. Фактические координаты появления сохраняются как home для возврата из города и восстановления после выхода за пределы фарма. Новых параметров INI/XML нет.
### 4.3 `spawn/group/*.xml` — Party-система
Каталог использует те же начальные файлы диапазонов и также принимает дополнительные `<min>-<max>.xml` до максимального уровня сервера. Все `<group>` объединяются в один набор, а group ID проверяются глобально. `<group id enabled autoStart cycle peaceMinutes battleMinutes town partyId>` задаёт отдельный lifecycle. При `cycle=false` группа живёт до GM-stop/shutdown. `<spawn x y z heading radius distance>` задаёт общую область, `<wave delayMillis>` — задержанную волну, `<fake>` — участника.
Обязательные параметры участника: `classId`, `level`; дополнительные: `account`, `ai`, `female`, `role`, `town`, `partyId`, `partyLeader` и те же вложенные overrides профиля. В одной группе допустимо 2–9 участников и ровно один лидер. Внутренние ID создаются как `<groupId>_member_<n>`.
Клановая принадлежность выбирается один раз на `partyId` и резервирует места для полного состава: вся группа получает либо один общий клан, либо разные кланы только одного общего альянса, либо полностью остаётся без клана. Уровни 1–`FakeClanlessMaxLevel` принудительно остаются без клана; если такой профиль входит в XML-пати, clanless-режим применяется ко всему её составу без резервирования клановых мест. Режим и места сохраняются при временном despawn/respawn участников до shutdown, поэтому party не смешивает в одном составе чужие альянсы и независимые кланы. Статистика режимов выводится в `//fakes` как `partyModes`, а количество отдельно ограниченных по уровню активных фейков — как `levelRestricted`.
Если участника не воскресили за 10–20 секунд по INI, он появляется в городе. Группа возвращается на spot вместе с лидером после готовности лидера и отсутствия мёртвых членов.
### 4.4 `class-ai.xml`
`<classAi id parent role>` образует дерево профессий. `parent` наследует тактику и skills; дочерняя запись с одинаковыми `id + use` заменяет родительскую. Роли: `WARRIOR`, `ARCHER`, `DAGGER`, `MAGE`, `HEALER`, `SUPPORT`, `HYBRID_SUPPORT`, `TANK`, `FARMER`. Орочья магическая ветка использует `WARRIOR` до первой профессии и `HYBRID_SUPPORT` начиная с Orc Shaman: групповой саппорт сохраняется, а в PvE атакующие навыки чередуются с физическими ударами по warrior chances.
`<tactics>`: `preferredRange`, `movementIntervalMillis`, `kite`, `kiteTriggerRange`, `kiteStep`, `retreatToHealer`, `retreatHpBelow`, `retreatRange`, `flank`, `flankDistance`. Для роли ARCHER `kite=true` включает отход при близкой цели. Только действительно начатый/поставленный в очередь отход блокирует следующий выстрел до завершения движения. После отхода разрешается атака; недоступный movement budget, cooldown или заблокированный геодатой отход не запрещают бой с места. Порог отхода ограничен половиной рабочей дистанции, чтобы короткий лук не заставлял постоянно отбегать.
Фактически надетый лук/арбалет включает дальний бой у любой исходной роли, включая Rogue, Elven Scout и Assassin. Их исходные `preferredRange=80`, flank и dagger-приоритет навыков не применяются к луку. Рабочая дистанция берётся из реального `getPhysicalAttackRange()` с ограничением желаемой дальностью ARCHER/INI; AI не увеличивает характеристики оружия. При снятом луке профиль ARCHER переходит к ближней атаке. Ограничения навыков по оружию проверяются при каждой попытке, даже без изменения уровня.
Как только цель видна по геодате и находится на дистанции выстрела, ненужное сближение/патруль/маршрут обхода прекращается. Обычная стрельба передаётся штатному PlayerAI в режиме атаки с места: перемещение остаётся за общим AI, без автоматического преследования вплотную. В PvE готовый выстрел приоритетнее атакующего навыка; во время перезарядки разрешены навыки с warrior chances. В PvP приоритет навыков сохранён. Уже выполняющийся физический удар не прерывается новым атакующим навыком/отходом в этих ветках.
Вся орочья магическая ветка (`49`, `50`, `51`, `52`, `115`, `116`) использует физический fallback без ограничения уровня: Orc Mystic, Orc Shaman, Overlord, Warcryer, Dominator и Doomcryer. Если атакующий навык не изучен, в откате, запрещён условиями/молчанием, не хватает ресурсов либо попытка каста не принята, AI сближается для обычного удара. Бафы, лечение и групповой саппорт сохраняют свой приоритет. Атакующие навыки этой ветки и лучников запускаются через `doCast` после штатных проверок; недоступный навык не ставится в очередь CAST для сближения.
Если состояние `ATTACK` осталось без движения, выполняющейся атаки/каста и очереди действий, оно повторно передаётся ядру не чаще раза в секунду. Перезарядка лука учитывается, таймеры атаки/навыков не сбрасываются. Новых потоков, периодических задач на персонажа, запросов в БД или параметров конфигурации эти проверки не добавляют.
`<skill>`:
- `id`, `level`, `minLevel`, `maxLevel`, `grant` — идентификация, доступность и способ получения уровня; отсутствующий `maxLevel` либо `maxLevel="server"` действует до максимума сервера;
- `use` — `OFFENSE`, `RARE_OFFENSE`, `AOE`, `CONTROL`, `RARE_CONTROL`, `DETECTION`, `HEAL`, `PERCENT_HEAL`, `MASS_HEAL`, `BUFF`, `PARTY_BUFF`, `SUPPORT`, `RESURRECT`, `MASS_RESURRECT`, `CLEANSE`, `EMERGENCY`, `ULTIMATE`, `SITUATION`, `CHARGE`, `SWEEP`, `SUMMON`, `AURA`, `PASSIVE`;
- `target` — `SELF`, `ENEMY`, `PARTY`, `SUMMON`;
- `priority`, `chance`, `reuseMillis`, `hpBelow`, `minRange/maxRange`, `effectAbsent`;
- `condition` — `NONE`, `SELF_HP`, `SELF_MP`, `SELF_CP`, `SELF_CHARGES`, `TARGET_HP`, `TARGET_MP`, `TARGET_CP`, `HEIGHT_DIFFERENCE`; границы задают `minCondition/maxCondition`;
- `weapons`, `armors` — допустимые типы экипировки.
Большее `priority` проверяется раньше, но не отменяет chance/reuse/range/condition. При `grant=false` используется реально доступный профессии уровень навыка; `grant=true` явно выдаёт заданный уровень.
Для навыков вне профессии внутри нужного `<classAi>` используется отдельный наследуемый блок:
```xml
<customSkills>
<active id="1234" level="1" minLevel="40" use="OFFENSE" target="ENEMY" priority="40" chance="35" />
<passive id="1235" level="1" minLevel="40" />
</customSkills>
```
`active` поддерживает те же условия, дистанции, ограничения экипировки, шанс и AI-reuse, что обычный `<skill>`, но всегда выдаётся персонажу независимо от class skill tree. `passive` также выдаётся автоматически, применяется штатной системой характеристик ядра и намеренно исключается из списка действий AI. При выходе уровня за `minLevel/maxLevel` выданная добавка снимается, а одноимённый штатный навык профессии при наличии восстанавливается. `level` обязателен и должен существовать в `SkillsParser`; неизвестный ID/уровень останавливает загрузку до спавна.
При пересечении боевым магом границ профессий `20`, `40` и `76` система детерминированно выбирает дочернюю магическую профессию из `class-ai.xml`, меняет штатный class template только в памяти, выдаёт доступное retail-дерево и перестраивает кэш навыков. Переход с 39 на 40 больше не оставляет персонажа без атак: записи первой профессии с `maxLevel="39"` заменяются навыками выбранной второй профессии. Устаревшие `Wind Strike`, `Ice Bolt` и аналогичные навыки при этом не возвращаются.
### 4.5 `equipment.xml`
На уровнях 1–`FakeEquipmentStarterMaxLevel` (по умолчанию 8) обычно копируется `PcTemplate.getInitialEquipment()`, то есть штатный комплект создания персонажа для его базовой профессии. Диапазон `equipment.xml` с `starterWeaponOverride="true"` заменяет только оружие стартового комплекта случайным оружием своего weighted-пула; в поставляемых данных так настроен Orc Mystic (`49`). В Java нет списка исключительных classId. Сохраняются количество, флаг экипировки, заточка, аугментация и элементы; предметы остаются только в памяти. Со следующего уровня применяется полный weighted-выбор из `equipment.xml`. Значение `FakeEquipmentStarterMaxLevel=0` полностью отключает стартовый комплект.
Профессия и уровень выбирают ровно свой пул XML. Поставляемый `equipment.xml` сохраняет прежние наборы: например, Orc Mystic/Shaman и крафтерская ветка используют физические одноручные дубины, а Overlord/Warcryer-ветки также имеют магические дубины. Это теперь данные, а не Java-ограничение: изменение списка в XML сразу меняет допустимую экипировку без правки кода.
Структура: `<class id>` → `<level min max starterWeaponOverride>` → независимые weighted-пулы `<weapons>`, необязательный `<shields>`, `<armors>` и `<jewels>`. `max="server"` продлевает последний диапазон до максимума сервера. `starterWeaponOverride` по умолчанию `false`; `chance` является относительным весом, не процентом.
- `<weapon id chance enchant augmentationId>` и до шести `<element type value>`;
- `<shields>/<shield id chance enchant>` задаёт щиты для танковых и гномьих веток;
- `<armors>/<variant id chance>` и `<jewels>/<variant id chance>` содержат `<item id count enchant equip augmentationId>`;
- вариант может иметь `<hennas>/<henna symbolId>`, максимум три.
Для нестакаемого предмета `count` означает количество отдельных `ItemInstance`: например, `count="2"` у серьги или кольца создаёт и экипирует два предмета в левый и правый слоты. Для стакаемого предмета сохраняется один стек указанного размера. Поскольку экипировка и лут фейка существуют только в памяти, штатная механика `Player.onDieDropItem` для фейков отключена; обычных игроков это не затрагивает.
Выданные предметы учитываются MemoryInventory по `objectId`, поэтому одинаковый `itemId` у двух нестакаемых экземпляров не объединяет их. Левая и правая серьги/кольца сохраняют свои `locationSlot`, а при удалении фейка каждый объект освобождается отдельно.
Выбираются одно оружие, один armor-вариант и один jewel-вариант. Если в диапазоне объявлен `<shields>`, его вариант комбинируется с оружием именно так, как задано XML; скрытой проверки профессии или типа оружия нет. Валидатор сохраняет только структурную защиту: элемент `<shield>` обязан действительно быть щитом левой руки. Совместимость оружия, брони и щита полностью отвечает автор XML. Стрелы и болты могут находиться в инвентаре, но экипируются только при реально надетом луке или арбалете.
### 4.6 `buff-sets.xml`
`<set id minLevel maxLevel>` должен без пробелов и пересечений покрывать уровни от 1 до штатного максимума сервера. Значение `maxLevel="server"` означает этот динамический максимум. Пустой `set` отключает постоянные бафы для своего диапазона; поэтому уровни 1–5 остаются без автоматических бафов. `<buff id level priority>` создаёт бессрочный эффект до смерти. Классовые `BUFF`, `PARTY_BUFF` и `AURA` также не применяются к фейкам 1–5 уровня.
При конфликте abnormal type выбирается больший abnormal level, затем `priority`, уровень skill и ID. Song/dance в постоянных наборах запрещены. После смерти/изменения уровня набор применяется заново; задач продления нет. Обычный BUFF/PARTY_BUFF не кастуется, если конфликтует с постоянным эффектом.
### 4.7 `consumables.xml`
Корень `startingAdena` задаёт виртуальную адену обычного фармера (`0` по умолчанию), а `traderStartingAdena` — отдельный стартовый баланс постоянного SELL/BUY-трейдера (`10000000`). Поэтому обычные фейки начинают без адены и набивают её с монстров, а скупщики сохраняют рабочий бюджет. Обе суммы существуют только в памяти. `<consumable>` использует:
- `itemId`, `kind`: `SOULSHOT`, `SPIRITSHOT`, `BLESSED_SPIRITSHOT`, `BEAST_SOULSHOT`, `BLESSED_BEAST_SPIRITSHOT`, `ARROW`, `BOLT`, `POTION`, `OTHER`;
- `resource`: `NONE`, `HP`, `MP`, `CP`;
- `count`, `infinite`, `minLevel`, `maxLevel`; отсутствующий `maxLevel` либо `maxLevel="server"` действует до максимума сервера;
- для банок: `useBelow`, `restorePercent`, `reuseMillis`.
Подходящий уровню грейд находится в inventory. Infinite shots логически перезаряжаются после атак/кастов, arrows/bolts не уменьшаются, банки восстанавливают ресурс напрямую и показывают обычную анимацию предмета. `BEAST_SOULSHOT` и `BLESSED_BEAST_SPIRITSHOT` принадлежат самону: видимый стек хранится в MemoryInventory хозяина, но ядро заряжает самона напрямую и никогда его не расходует.
### 4.8 `traders.xml`
Корень `<traders enabled spawnOnLoad races armorGrades weaponGrades unarmedChance>`. `races` задаёт ограниченный пул рас по умолчанию. `armorGrades` и `weaponGrades` задают допустимые грейды внешней экипировки торговцев (`NG,D,C` по умолчанию), а `unarmedChance` — процент появления без оружия.
У корня `traders.xml` нет общего дерева экипировки. Каждый `<store>` после `<point>` или `<territory>` обязан содержать собственный `<equipment>` с секциями `<weapons>`, `<armors>` и `<jewels>`. Внутри нет `<class>` и `<level>`: набор физически привязан к конкретной лавке и не может быть выбран другим store. В `weapons` перечисляются взвешенные `<weapon id chance>`, а броня и бижутерия задаются отдельными `<variant id chance>`; одинаковые грейды armor/jewel объединяются при выборе.
```xml
<store id="1" minLevel="15" maxLevel="19" type="SELL">
<point x="-14372" y="123575" z="-3112" heading="30535" />
<equipment>
<weapons>
<weapon id="4" chance="60" />
<weapon id="13" chance="40" />
</weapons>
<armors>
<variant id="1" chance="100">
<item id="23" count="1" equip="true" />
</variant>
</armors>
<jewels>
<variant id="1" chance="100">
<item id="909" count="1" equip="true" />
</variant>
</jewels>
</equipment>
<!-- items или variants ассортимента -->
</store>
```
Дочерний `<pricing>` полностью задаёт базовое ценообразование SELL-лавок:
```xml
<pricing defaultMultiplier="1.0">
<equipment grade="NG" multiplier="1.0" minimumMultiplier="1.0" />
<equipment grade="D" multiplier="1.0" minimumMultiplier="0.9" />
<equipment grade="C" multiplier="1.3" minimumMultiplier="1.2" />
<equipment grade="B" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="A" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="S" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="S80" multiplier="5.0" minimumMultiplier="5.0" />
<equipment grade="S84" multiplier="5.0" minimumMultiplier="5.0" />
</pricing>
```
`defaultMultiplier` применяется к расходникам, материалам и другим предметам без индивидуальной цены. Для оружия и брони используется `multiplier` соответствующего грейда. `minimumMultiplier` — нижний предел SELL-цены экипировки, который действует даже при индивидуальном переопределении. Порядок расчёта: положительный `price` предмета задаёт фиксированную цену; иначе положительный `priceMultiplier` предмета переопределяет базовый коэффициент; иначе используется коэффициент из `<pricing>`. Итог округляется как `referencePrice × multiplier`, минимум до одной адены. BUY-позиции по-прежнему обязаны иметь явный положительный `price` и не используют базовые SELL-коэффициенты.
Каждый автономный `<store id minLevel maxLevel races type budget>` создаёт одну уникальную BUY или SELL лавку и использует ровно один способ размещения. Атрибут `races` у store необязателен и переопределяет корневой пул:
- `<point x y z heading>`;
- `<territory name heading>` с минимум тремя `<zone x y zMin zMax>`.
Уровень, раса и подходящий классу AI выбираются без обращения к solo/group spawn. Раса сначала равновероятно выбирается из допустимого пула, затем выбирается подходящая уровню профессия; пол и внешность случайны. Для BUY и SELL торговцев броня с бижутерией выбирается отдельно от оружия и независимо от уровня персонажа: сначала равновероятно выбирается доступный грейд из `armorGrades`, затем комплект этого грейда из собственного `<store>/<equipment>`. Оружие выбирается из `<store>/<equipment>/<weapons>` в `weaponGrades` либо не выдаётся с шансом `unarmedChance`. Java больше не запрещает конкретные типы оружия, брони или сочетания расы/класса: все такие ограничения определяет содержимое конкретного store. Сохраняются только общие проверки существования предмета, допустимого грейда, видимого armor-комплекта и запрет временных предметов.
Ассортимент задаётся либо совместимым одиночным `<items>`, либо новым блоком:
```xml
<variants>
<variant id="1" weight="1">
<item id="1463" count="8000" />
<item id="2510" count="8000" />
<item id="3948" count="8000" />
</variant>
<variant id="2" weight="2">
<item id="955" count="100" />
<item id="956" count="100" />
<item id="7124" count="100" />
</variant>
</variants>
```
`weight` — относительный вес, а не процент. Один вариант выбирается при запуске сервера и при ручном reload; остальные не попадают в активную лавку, но полностью валидируются. Варианты одной лавки имеют уникальные числовые ID и разные наборы item ID. Каждый SELL-вариант содержит минимум три позиции. `count` задаёт виртуальный остаток или объём скупки, `enchant` — заточку. BUY требует положительный `price` и достаточный `budget`. Для SELL обычно достаточно не указывать `price` и `priceMultiplier`: цена будет взята из общего `<pricing>`. Индивидуальные атрибуты нужны только для исключений.
Стрелы, обычные HP-поты, haste/alacrity/magic-haste и бинты запрещены во всех SELL-вариантах. Поставляемые правила сохраняют фактические цены лайва: D-экипировка продаётся по `1.0x`, C — по `1.3x`, B/A/S/S80/S84 — по `5x`; минимумы равны `0.9x`, `1.2x` и `5x` соответственно. У повторяющихся позиций готовой экипировки локальные коэффициенты удалены, но 51 намеренное переопределение материалов и компонентов сохранено. Цены проверяются загрузчиком при доступном item parser и повторно при создании лавки.
Название вычисляется по выбранному фактическому набору: shots имеют приоритет `[SHOTS]`; weapon/armor — `[WEAPONS]`, `[ARMOR]` или `[EQUIPMENT]`; scroll без shots/equipment — `[SCROLLS]`. Поэтому заголовок про заряды, свитки либо шмот невозможен без соответствующего предмета. В поставляемом файле 202 лавки; основные городские лавки имеют по три варианта, а созданный GM шаблон может иметь один вариант до ручного расширения. Низкие города имеют только 1–2 SELL-лавки экипировки, Гиран/Годдард/Аден/Руна — больше; грейды shots и вещи из drop привязаны к указанным городам и их farm-локациям.
### 4.9 `dialogues.xml`
- Файл содержит 100 intent с непрерывными ID 1–100. Каждый `<intent id channels>` содержит RU/EN `<trigger>` и `<response>`; channels: `TELL`, `ALL`, `SHOUT`. Intent 42–100 расширяют ответы на повседневные вопросы и игровые разговоры в шауте.
- `<fallback language>/<response text>` используется при отсутствии точного trigger.
- `<conversation id language channel minLevel>` содержит минимум две `<line speaker delayMinMillis delayMaxMillis text>`.
- Подстановки: `{player}`, `{name}`, `{level}`, `{class}`.
Язык определяется до поиска trigger. PM адресуется по индексу имени; для local выбирается один подходящий фейк в `FakeDialogueNearbyRadius`. На SHOUT отвечает один случайный активный фейк из всего мира независимо от его координат. Ответы и самостоятельные периодические SHOUT доставляются глобально всем реальным игрокам; cooldown по-прежнему не даёт толпе ответить одновременно. Listener только ставит событие в bounded queue и не задерживает сетевой поток. Статус `//fakes` показывает счётчики `received`, `matched`, `replies`, `sent`, `shouts`, `dropped` и `periodic`.
### 4.10 TXT-пулы
| `names.txt` | Один уникальный ник UTF-8 на строку, 1–16 допустимых символов. Имя не повторяется среди активных фейков и кэшированных игроков. |
| `titles.txt` | Один титул на строку; используется с уровня и шансом из INI. |
| `sell-store-titles.txt` | Обязательные секции `[SHOTS]`, `[SCROLLS]`, `[WEAPONS]`, `[ARMOR]`, `[EQUIPMENT]`, `[JEWELRY]`, `[RECIPES]`, `[MATERIALS]`, `[CONSUMABLES]`, `[OTHER]`, `[MIXED]`. |
| `buy-store-titles.txt` | Те же обязательные категории для BUY. |
Пустые строки данных, слишком длинные значения и регистронезависимые дубли отклоняются загрузчиком.
## 5. Поведение AI
### Цели и движение
World scan обычно выполняется без пригодной locked target, но скрытая navigation target больше не блокирует поиск до своего timeout: раз в `FakeBehaviorScanIntervalMillis` AI оппортунистически проверяет ближайших кандидатов. Любая видимая валидная цель сразу вытесняет скрытую, прежнее движение отменяется без задержки перед новой атакой. Если watchdog подтверждает отсутствие прогресса маршрута, текущая цель блокируется на `FakeBehaviorPathFindRetryMillis`, после чего следующий scan может выбрать другую невидимую цель и проверить её маршрут. Сундуки, рейд-боссы и их raid-minion'ы отбрасываются до GeoEngine и PathFinding; запрет также применяется к текущей цели, Party/leader assist, защите хилера и ответной атаке. Видимые кандидаты всегда имеют приоритет и проверяются GeoEngine в пределах batch-budget. Если видимой цели нет, ближайший невидимый монстр в `FakeBehaviorPathFindMaxDistance` становится временной navigation target: AI передаёт его реальные координаты штатному PathFinding ядра, но запускает не более `FakeBehaviorPathFindsPerBatch` новых маршрутов. При восстановлении прямой геовидимости цель переводится в обычный бой; по timeout или невозможности начать движение маршрут отменяется, а цель блокируется на `FakeBehaviorPathFindRetryMillis`. PvP-цели этим обходом намеренно не выбираются. Фейк не покидает XML farm area, возвращается домой, патрулирует, следует лидеру, а kite выполняется через общий movement budget. Зависшие состояния `CAST`, `MOVING` и `IDLE` контролируются timeout/recovery в `FakeController` и `TacticalMovement`.
На PvP-ивенте и Олимпиаде невидимая по геодате цель жёстко переводится в navigation state до выбора навыка или автоатаки. Даже если цель была видима при прошлом validation либо пришла от лидера/объекта ивента, боевая ветка повторно проверяет LOS и не пытается кастовать сквозь стену. Во время обхода продолжается полный поиск участников: появившийся видимый разрешённый противник немедленно заменяет скрытую цель; после провала маршрута временная блокировка позволяет выбрать другого соперника. Competitive-маршруты используют отдельный `FakeBehaviorCompetitivePathFindsPerBatch`, поэтому фоновые фермеры не отнимают у участников лимит запуска PathFinding.
Solo-фермер не выбирает монстра, которого уже активно атакует другой персонаж или summon. Первый solo-фейк кратковременно резервирует выбранную цель ещё до первого удара, поэтому несколько фейков из одного batch не собираются на одном мобе. Резерв автоматически снимается при смене/потере цели, смерти владельца либо по timeout и периодически очищается без отдельных задач. Неполное HP само по себе не считается занятостью: повреждённый, но фактически брошенный моб остаётся валидной целью. Ограничение не применяется к XML-группам, ассисту Party, ответной атаке, PvP-ивентам и олимпиаде.
### Роли и навыки
- WARRIOR/TANK/FARMER чаще используют базовую атаку; PvE skill/debuff chances ограничивают спам.
- DAGGER не пытается постоянно обойти цель: спереди приоритетна автоатака. Если фейк уже оказался за спиной, он один раз применяет доступный back/offensive skill и следующим действием обязательно возвращается к атаке с руки.
- ARCHER имеет бесконечные стрелы/болты, держит дистанцию и умеет атаковать обычным выстрелом. Близкий монстр запускает обязательный цикл kite: начатый отход завершается перед следующей атакой и не отменяется ранним выстрелом.
- MAGE выбирает реальный range доступного nuke; дебаффы реже обычных атакующих заклинаний.
- HEALER/SUPPORT сначала обслуживают Party, затем могут атаковать подходящими уровню навыками. Устаревшие low-level атаки фильтруются по диапазонам XML.
- FARMER после spoil сохраняет труп, подходит и использует `SWEEP`, если добыча принадлежит ему/Party.
`SkillEngine` проверяет известность/уровень skill, экипировку, target, distance, geodata, MP/HP/CP/charges, effect absence, XML reuse и штатный castability, затем запускает `doCast`.
### Party и PvP
Лидер публикует основную цель; группа ассистит ему либо защищает атакованного healer/support. Healer выбирает mass heal при достаточном числе раненых, иначе single-target heal; также работают cleanse, recharge, resurrection и party buffs. BD/SWS используют доступные XML dance/song только после проверки отсутствующего эффекта.
Реальный игрок, нанёсший урон фейку, получает приоритет независимо от `TargetMode`, если проходит level/peace/party/clan проверки. Flagged/PK рядом может быть выбран упреждающе. Равный или более слабый игрок атакуется гарантированно; chances применяются к допустимо более сильному.
Solo-фейк с малым шансом принимает Party реального игрока и ассистит его цели. Связь прекращается при logout лидера или уходе из допустимой зоны.
### Смерть, город и торговля
Solo после задержки определяет штатный город и точку возрождения через `MapRegionManager` по координатам home spot, некоторое время ходит между NPC/торгует и возвращается на farm spot. Ссылка `town` предоставляет таймеры, радиусы и настройки лавки, но не подменяет вычисленный город; её координаты служат fallback. Party сначала ждёт resurrection. Невоскрешённые члены уходят в рассчитанный город; вся группа возвращается вместе с лидером. При движении к NPC прямая гео-линия используется без PathFinding, а препятствие передаётся штатному ограниченному PathFinding ядра.
Лут вне Party с реальным игроком агрегируется в `FakeInventory` с ограничением `lootCapacity`. Если solo-фейк принял Party реального лидера, предметы проходят через штатный `Party.distributeItem`: режим `ITEM_LOOTER` направляет автоматический подбор лидеру, RANDOM/ORDER сохраняют выбранные правила Party, а адена делится между членами в допустимом радиусе. Доля, назначенная фейку, остаётся только в памяти и не обращается к БД. VIP-point reward для фейка игнорируется, поэтому отсутствующий `VipTemplate` не создаёт ошибку и VIP-прогресс ему не сохраняется. Временная городская SELL-лавка выбирает до `maxStoreItems`, цену `referencePrice × priceMultiplier` и заголовок по категории. При `AuctionPrivateStoreAutoAdded=True` позиции постоянных и временных SELL-лавок регистрируются в штатном Alt+B-аукционе, обновляют остаток при покупке и удаляются при закрытии лавки либо despawn. BUY-заявки не являются продаваемыми аукционными лотами.
## 6. GM-команды
| Команда | Действие
| `//fakes` | Полный status: spawned/queued, stores, clan/alliance assignment и capacity, shots/potions, buffs, lifecycle, dialogues, target/movement budgets и scheduler. |
| `//fakes_reload` | Полный shutdown и повторная загрузка INI/XML/TXT. |
| `//fakes_spawn <profileId>` | Создать один существующий runtime-профиль. |
| `//fakes_despawn <profileId>` | Удалить активный или ожидающий в очереди профиль. |
| `//fakes_group_start <groupId>` | Запустить группу вручную. |
| `//fakes_group_stop <groupId>` | Остановить группу и её lifecycle. |
| `//spawn_fake 20-30` | Атомарно добавить solo location у GM в подходящий `spawn/single/<range>.xml`, выбрать глобально следующий ID, город и совместимые классы и проверить весь каталог без остановки работающих фейков. Если подходящего файла нет, он создаётся автоматически. Новая точка применяется после ручного `//fakes_reload` или перезапуска сервера. Диапазон не должен пересекать границы профессий 20/40/76 и не может превышать серверный максимум. |
| `//spawn_fake_group 76-85 [3-9]` | Добавить сбалансированную Party; выбрать точный уровень внутри диапазона и по нему записать группу в подходящий либо автоматически созданный `spawn/group/<range>.xml`; глобально выбрать следующий ID и проверить весь каталог без автоматического reload. Допустимый верхний уровень равен серверному максимуму. Группа применяется после ручного `//fakes_reload` или перезапуска сервера. |
| `//spawn_fake_trader SELL 20-30` | Создать автономный точечный SELL/BUY-шаблон на координатах GM в `traders.xml` с `minLevel=20`, `maxLevel=30`, следующим ID и стартовым `<variants><variant id="1">`. Раса берётся из корневого пула `races`; профиль спавна не нужен. После редактирования можно добавить варианты 2/3 и задать их веса. Проверка выполняется без автоматического reload; лавка применяется после `//fakes_reload` или перезапуска. Лишние аргументы отклоняются. |
## 7. Валидация и типичные ошибки
Загрузка прекращается до спавна при: неизвестном INI-ключе; неверном boolean/number/enum; XSD-ошибке; дубликатах ID/имён; неизвестных town/class/skill/item/race; неизвестном кастомном skill level; отсутствии профессии трейдера в заданном диапазоне; пробелах в покрытии buff levels; предмете `<shield>`, который физически не является щитом левой руки; неправильном Party leader count; недостаточном BUY-budget; неверных Min/Max; отсутствии AI/экипировки для уровня. Классовая совместимость экипировки здесь намеренно не проверяется и полностью задаётся XML.
`CacheCharNames=True` обязателен: проверка коллизий имён должна выполняться в памяти без запроса к БД.
## 8. Защищённая production-сборка
Обфускация применяется только к отдельному `l2e-fakeplayers.jar`; ядро HF5/Salvation и datapack не изменяются. Один раз выполните `tools/Install-ProGuard.ps1`, затем запускайте `tools/Build-Protected.ps1` либо `ant protected`. Используется закреплённый ProGuard 7.10.0 с проверкой SHA-256 и поддержкой bytecode Java 25.
Обычный `build-*/l2e-fakeplayers.jar` остаётся диагностической сборкой. На сервер следует передавать только `build-*/protected/l2e-fakeplayers.jar`. Файлы `build-*/obfuscation/mapping.txt`, `seeds.txt` и `effective.pro` предназначены только владельцу: `mapping.txt` нужен для восстановления имён в production stack trace. На сервер и третьим лицам их передавать нельзя.
Production-профиль сохраняет фиксированным только `l2e.fakeplayers.integration.FakeListener`, потому что его полное имя находится в `META-INF/services`. Остальные классы, поля и методы переименовываются; реализация переносится в скрытый пакет. Имена enum-констант сохраняются, поскольку они являются частью INI/XML-контракта. Shrink и bytecode optimization намеренно выключены: это исключает удаление динамически используемых путей и не меняет производительность AI.
Обфускация повышает стоимость декомпиляции, но не делает выполняемый на чужой машине Java-код математически недоступным. Исходники, обычный JAR и mapping должны оставаться в закрытом репозитории. Для следующего уровня защиты можно отдельно добавить коммерческое шифрование строк/control-flow и персональную маркировку сборок; привязку к онлайн-серверу лицензий в критическом GameServer-процессе использовать не рекомендуется.
### Сумонеры и хербы
- Warlock/Arcana Lord, Elemental Summoner/Elemental Master и Phantom Summoner/Spectral Master вызывают подходящего уровню боевого самона из `class-ai.xml`.
- Хозяин и самон атакуют общую цель. В PvE хозяин предпочитает обычные удары оружием и между атаками может применять настроенные боевые навыки.
- Записи с `target="SUMMON"` лечат самона ниже порога `hpBelow` и накладывают отсутствующие классовые бафы.
- При вызове самон получает постоянный набор из `buff-sets.xml` по уровню хозяина. Задач продления нет; эффекты живут до смерти или удаления самона.
- Самон автоматически и бесконечно использует Beast Soulshot для физических атак и Blessed Beast Spiritshot для магии. После каждого сброса заряда ядро немедленно заряжает следующий в том же боевом потоке, без отдельной задачи и item handler.
- Если самон погибает или исчезает во время фарма, общий тик удаляет старый объект и немедленно ставит XML-навык `SUMMON` в приоритет. Если штатный откат навыка ещё не завершён, попытка повторяется на обычных AI-тиках. Новый самон появляется с полными HP/MP и заново получает весь постоянный набор `buff-sets.xml`.
- Самоны фейков и реагенты существуют только в памяти. Время жизни обрабатывается общим AI-тиком хозяина; данные самона, эффектов и откатов не пишутся в БД.
- Хербы всегда подбираются автоматически и сразу применяются штатным обработчиком к хозяину и живому самону, не занимая инвентарь. Херб не может заменить постоянный баф той же abnormal-группы.
.png.9b30fdd2022e177af9d4b2fefd863723.png)
