# Systems Observer is a set of systems that each handle one part of running an event. This page goes through them one at a time: what each does, and what you can change about it. If you're setting up for the first time, read the Event Lifecycle section below first. Everything else makes more sense once you know which phase it happens in. --- ## 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