# Systems Observer is composed of interconnected systems that manage every aspect of your event. This page provides a breakdown of each system, what it does, and how you can configure it. --- ## Event Lifecycle The core flow of an Observer-managed event follows a three-phase lifecycle. ### Phase 1: IN_LOBBY Players connect and are held in the lobby world. During this phase: - The lobby world and player positioning are managed. - Player connections are tracked. - Staff can prepare kits. - Capsule locations and types can be pre-configured. - Item and enchantment restrictions can be set up. ### Phase 2: PRE_GAME Triggered by a state change from `IN_LOBBY` to `PRE_GAME`. During this phase: - Players are assigned to capsules based on the configured capsule type. - If Lead is installed, teams are assigned to capsules. - Player states are prepared. - Late scatter settings determine how late joiners will be handled. ### Phase 3: IN_GAME Triggered by a state change from `PRE_GAME` to `IN_GAME`. The event is now actively running. During this phase: - Players are released from capsules. - Deaths and eliminations are tracked. - Lifesteal heart mechanics are active. - Placed blocks begin decaying (if enabled). - All gameplay toggles are enforced. - World events can be activated and deactivated. - Pedestal interactions and crafting are monitored. - Custom recipes are active. - Respawn state capture is active. - Help requests can be submitted by players. - Translations are resolved and dispatched. --- ## Capsule System **Config File:** `capsules.yml` The capsule system determines how players are distributed into the event world. ### Capsule Types | Type | Behavior | |---|---| | `BATTLE_ROYALE` | Scatters players randomly across the map within a min/max distance range. | | `CIVILIZATION` | Groups players into clusters within a configurable radius. | | `WORLD_SPAWN` | Spawns players near the world spawn within a configurable radius. | ### Team Integration When Lead is installed, capsules can be bound to teams. Team members are assigned to their team's capsule during the pre-game phase. Lead must be installed for team-based capsule assignments. --- ## Elimination System **Config File:** `managers/elimination.yml` The elimination system intercepts player deaths and applies configurable consequences. ### How It Works 1. A player dies. 2. The player's gamemode is set to the configured `gamemode_on_death` (default: `SPECTATOR`). 3. If `lightning_on_kill` is enabled, lightning strikes at the death location. 4. The configured death message is broadcast. 5. If `auto_ban.enabled` is true and the player lacks the bypass permission, they are banned and shown the kick message. 6. The remaining player count is updated (offset by `minimum_remaining_players`). ### Auto-Respawn When `auto_respawn` is enabled, eliminated players are automatically respawned instead of staying on the death screen. This works in conjunction with the **Respawn System**. --- ## Lifesteal System **Config File:** `managers/lifesteal.yml` The lifesteal system adds health-based item mechanics to the game. ### Lifesteal Types | Type | Behavior | |---|---| | `DROP` | Hearts drop as items when a player is killed. | | `CONSUME` | Hearts are consumed directly on kill, granting health to the killer. | | `OBTAIN` | Hearts are added to the killer's inventory on kill. | | `ANYTIME` | Hearts can be obtained at any time. | ### Heart Items Hearts are custom items (default: Nether Star) with configurable display names, lore (MiniMessage format), material, item model, and stackability. ### Withdrawal When `can_withdraw` is true, players use `/withdraw [amount]` to convert their health into heart items. Each withdrawal removes 2 health points (1 heart) and produces one heart item. Withdrawal is blocked if the player's health would drop below `min_health`. ### Consumption When a player right-clicks a heart item, they gain 2 health points per heart. Consumption is blocked at `max_health`. If `should_remove_heart` is true, the heart item is consumed. ### Health Bounds - `max_health` (default: 40) — Maximum achievable health. - `min_health` (default: 14) — Minimum health before withdrawal is blocked. --- ## Decay System The decay system tracks player-placed blocks and reverts them to air after a configurable time. ### Global Block Decay When `should_global_block_decay` is enabled in `mechanics.yml`, all player-placed blocks are automatically marked for decay. --- ## Pedestal System **Config File:** `pedestals.yml` Pedestals are world-placed crafting stations that require specific ingredients and produce a result item. ### Pedestal Types | Type | Behavior | |---|---| | `SINGLE_USE` | The pedestal can only be used once, globally. | | `PER_PLAYER` | Each player can use the pedestal up to a configured number of times. | | `REUSABLE` | The pedestal has unlimited uses. | ### Configuration Each pedestal is configured with: - A unique identifier. - A world location. - A list of required ingredients. - The result item produced on craft. - Maximum number of uses (for `PER_PLAYER` type). - Height offset for the holographic item display. - The usage limitation type. --- ## Mechanics System **Config File:** `mechanics.yml` The mechanics system provides toggles for a wide range of gameplay behaviors. ### Available Toggles You can enable or disable mechanics such as: - Apple drop rates and flint rates - Sleeping, enchanting, anvil usage, ender chests - Villager breeding and trading - Respawn anchors, bed bombing, portal trapping - Indirect PvP, potion brewing - Global block decay, unbreakable spawners - World border improvements and synchronization - Nether and End access - Block trampling - Auto-grant all recipes ### Combat Logging Combat logging detection can be enabled to track when players are in combat. Configuration includes: - Whether combat logging detection is enabled. - Duration of combat tag in seconds. - Where the combat notification appears (`ACTION_BAR`, `TITLE`, or `CHAT`). - The message template with a `{time}` placeholder. --- ## World Event System **Config File:** `managers/world_events.yml` World events are named occurrences that execute commands and broadcast translation messages when activated. ### Configuration Each world event is configured with: - A unique identifier. - An icon material for the GUI. - A translation key broadcast on activation/deactivation. - A list of commands executed on activation. World events are controlled through the in-game GUI or commands and support start/end lifecycle states. --- ## Kit System The kit system saves and restores complete player states as named kits. ### What Kits Store Kits capture: - Inventory contents - Health, food level, saturation - Experience and level - Absorption amount - Fire ticks - Active potion effects - Location (optional) - Metadata: ID, timestamp, name, saved-by player ### Export and Import Kits can be exported to shareable codes or mclo.gs URLs and imported back, enabling kit sharing across servers. --- ## Custom Recipes System **Config File:** `custom_recipes.yml` Register custom shaped and shapeless crafting recipes that persist across server restarts. Recipes are managed through configuration and can be reloaded at runtime. --- ## Respawn System **Config File:** `managers/respawn.yml` The respawn system captures player state snapshots and restores them on respawn, preserving inventory, health, experience, potion effects, and location. --- ## Late Scatter System **Config File:** `managers/late_scatter.yml` Handles players who join after the game has started by scattering them into the event world. Configuration includes: - Whether late scatter is enabled. - The gamemode assigned to late joiners. - Starting inventory for late joiners. - Translation key for the late join broadcast. Players are only scattered once to prevent duplicate scattering. --- ## Player Data System **Config File:** `players.yml` Tracks per-player state throughout the event, including: - Whether the player is in combat. - Whether the player is in lobby mode. - Whether the player is dead/eliminated. - Whether the player is in staff mode. - The team the player is bound to (requires Lead). - Whether the player has been late scattered. - Whether the player is sitting out. - The WorldGuard region the player is assigned to. --- ## Translation System **Config File:** `translations.yml` All player-facing messages support MiniMessage formatting. Translations can include chat messages, titles, sounds, and commands. ### Translation Structure Each translation key can define: - `tellraw` — MiniMessage chat message. Prefix with `<center>` for centered text. - `title.title` / `title.subtitle` — Title and subtitle display. - `sound.sound` / `sound.volume` / `sound.pitch` — Sound effect. - `broadcastable` — Whether the translation supports broadcasting. - `commands` — Commands to execute alongside the translation. --- ## HelpOp System **Config File:** `managers/helpop.yml` A simple staff assistance system. Players can submit help requests with a configurable cooldown. Staff members with the `lodestone.observer.staff` permission receive notifications when players submit help requests. Pending requests can be cleared by staff. --- ## Related Pages - [[Observer/Server Owners/Commands]] — Complete commands reference - [[Observer/Server Owners/Configuration]] — Full config.yml breakdown