Skip to content

All Beacon Effects

github-actions[bot] edited this page Jan 3, 2026 · 11 revisions

Beacon Effects Configuration Manual

This document provides an exhaustive technical reference for the configuration, behavior, and implementation of all beacon effects available within the BeaconPlus ecosystem. It is intended for server administrators and system integrators who require precise control over effect mechanics. Be advised that this document serves strictly as a configuration manual; it does not offer gameplay advice or strategic consulting.


1. Potion Effect Configuration

Type Identifier: POTION_EFFECT

The Potion Effect module serves as the primary mechanism for applying vanilla Minecraft status effects to entities. It operates by interfacing directly with the server's internal potion registry, allowing for the application of any registered effect type to valid targets within the beacon's radius.

Functional Description

The beacon operates on a scheduled tick cycle. During each cycle, the system performs a spatial scan of the defined radius to identify all entities that match the beacon's target criteria (e.g., players, specific mobs).

Upon identifying a valid target, the system retrieves the entity's current active potion effects. It compares the configured effect with the entity's existing state.

  1. Absence Check: If the entity does not currently possess the effect, the beacon applies it immediately using the configured Amplifier and Duration.
  2. Intensity Check: If the entity already possesses the effect, the system compares the Amplifier (level) of the existing effect against the beacon's configured level. If the beacon's level is lower than or equal to the existing level, the application is skipped to prevent overriding a more potent buff (e.g., a Potion of Strength II drank by the player).
  3. Duration Check: If the beacon's level is higher, or if the logic permits extension, the effect is re-applied to refresh its duration.

This logic ensures that beacons act as endless sources of effects without disrupting the utility of consumable potions that might offer superior, albeit temporary, benefits.

Configuration Parameters

Effect

Defines the specific potion type to be applied. The value acts as a key to lookup the effect in the server's registry.

  • Format: String (Case-Insensitive)
  • Scope: Accepts all vanilla potion types. Common examples include SPEED (movement speed), FAST_DIGGING (mining speed), INCREASE_DAMAGE (melee damage), HEAL (instant health), JUMP (jump height), REGENERATION (health recovery), FIRE_RESISTANCE (fire immunity), WATER_BREATHING (oxygen preservation), INVISIBILITY (rendering suppression), NIGHT_VISION (gamma correction), WEAKNESS (damage reduction), POISON (periodic damage), WITHER (periodic decay damage), SLOW (movement reduction), SLOW_FALLING (gravity reduction), LEVITATION (upward velocity), LUCK (loot table modifier), DOLPHINS_GRACE (swim speed), CONDUIT_POWER (underwater vision/speed).
  • Validation: Invalid names will result in a console error and the effect failing to load.

Amplifier

Defines the intensity level of the potion effect. Minecraft uses a zero-indexed integer system for levels.

  • Format: Integer
  • Zero (0): Corresponds to "Level I" in gameplay terms.
  • One (1): Corresponds to "Level II".
  • Two (2): Corresponds to "Level III".
  • Mechanics: Higher amplifiers linearly or exponentially increase the potency of the effect depending on the specific potion type. For example, JUMP level 1 allows jumping 1.5 blocks, while level 2 allows 2.5 blocks. FAST_DIGGING increases mining speed by 20% per level.

Duration

Defines the length of time the effect remains active on the entity after each application cycle. This does not determine how long the beacon runs, but rather how long the effect lingers on the player.

  • Format: Time String (e.g., "15s" for 15 seconds, "200t" for 200 ticks).
  • Continuity: To achieve a seamless experience where the effect never flickers, the Duration must be significantly longer than the beacon's update interval. If the beacon updates every 2 seconds, a duration of "5s" provides a 3-second safety buffer against server lag.
  • Flickering: A duration set exactly equal to the update interval will cause the effect to visually disappear for one tick before reappearing, causing screen flashing.

Ambient

Toggles the rendering style of the potion particles.

  • Format: Boolean (true / false)
  • True: Particles are rendered as "Ambient". In the Minecraft client, ambient particles are more translucent and less obtrusive. This is the default state for effects provided by vanilla beacons.
  • False: Particles are rendered as "Normal". These are opaque and vibrant, identical to the particles emitted when a player drinks a potion or is splashed.

Particles

Controls the network transmission of particle packets.

  • Format: Boolean (true / false)
  • True: The server sends particle packets to the client. The client renders swirls around the affected entity.
  • False: The server suppresses particle packets. The effect is applied "silently". Note that other players will not see that the target is buffed unless they check the entity's health or speed.

Icon

Controls the visibility of the effect icon in the player's Heads-Up Display (HUD).

  • Format: Boolean (true / false)
  • True: The square buff icon is displayed in the top-right corner of the screen (or inventory screen).
  • False: The icon is suppressed. This allows for "Invisible" buffs that affect gameplay mechanics without alerting the player via the UI.

Remove On Leave

Determines the behavior when an entity exits the beacon's effective radius.

  • Format: Boolean (true / false)
  • True: The system intercepts the entity's exit event (or calculates it during the tick) and programmatically removes the specific potion effect. The removal is instant.
  • False: The system takes no action upon exit. The effect remains on the entity and persists until its remaining Duration expires naturally. This allows for "Charge Up" zones where players can stand to gain a 30-second buff and then leave to use it.

Configuration Examples

Example A: Standard Haste Configures a standard mining buff with seamless duration and ambient particles.

- Type: POTION_EFFECT
  Effect: FAST_DIGGING
  Amplifier: 1
  Duration: "15s"
  Ambient: true
  Particles: false
  Icon: true
  Remove On Leave: true

Example B: Hidden Resistance Configures a defensive buff with absolutely no visual indicators (no particles, no icon).

- Type: POTION_EFFECT
  Effect: DAMAGE_RESISTANCE
  Amplifier: 0
  Duration: "10s"
  Ambient: true
  Particles: false
  Icon: false
  Remove On Leave: false

Example C: Environmental Wither Configures a zone that applies a detrimental effect to intruders. Usage of particles ensures the hazard is visible.

- Type: POTION_EFFECT
  Effect: WITHER
  Amplifier: 1
  Duration: "5s"
  Ambient: false
  Particles: true
  Icon: true
  Remove On Leave: false

Example D: Charging Station Configures a mechanism where players enter to gain 60 seconds of Speed, which they can take with them outside the zone.

- Type: POTION_EFFECT
  Effect: SPEED
  Amplifier: 1
  Duration: "60s"
  Ambient: true
  Particles: true
  Icon: true
  Remove On Leave: false

Example E: High-Grav Zone Configures a heavy levitation effect (Levitation 128 usually prevents movement or pulls down depending on version quirks) or generic Slowness.

- Type: POTION_EFFECT
  Effect: SLOW
  Amplifier: 3
  Duration: "5s"
  Ambient: false
  Particles: true
  Icon: true
  Remove On Leave: true

2. Immortality Field Configuration

Type Identifier: IMMORTALITY_FIELD

The Immortality Field is an event-driven protection module. Unlike periodic effects that apply buffs, this module sits dormant monitoring the Event Bus for specific conditions related to entity mortality.

Functional Description

The system registers a high-priority listener for EntityDamageEvent. When an entity within the beacon's radius takes damage, the module performs a simulation:

  1. Damage Calculation: It calculates the final damage amount after armor, enchantments, and potion effects are processed.
  2. Mortality Check: It compares this final damage against the entity's current health.
  3. Intervention: If the damage is sufficient to reduce the entity's health to zero or below, the intervention protocol is initiated.
  4. Cancellation: The damage event is cancelled (set to 0 damage).
  5. State Reset: The entity's health is explicitly set to the configured Min Health value.

This sequence occurs within a single server tick, ensuring that the entity never actually "dies" in the engine's perspective. The "You Died" screen is never presented to the client, and inventory is not dropped.

Configuration Parameters

Min Health

Defines the exact health value set on the entity immediately after a fatal damage event is intercepted.

  • Format: Double (Floating Point Number)
  • Value Scale: 20.0 represents full health (standard 10 hearts). 1.0 represents half a heart.
  • Effect: This value is absolute. If configured to 20.0, the player instantly heals to full health upon "dying". If configured to 1.0, the player survives but is left in a critical state.

Survival Chance

Defines the probability that the intervention logic will successfully execute.

  • Format: Double (0.0 to 100.0)
  • Deterministic Logic: When a fatal event is detected, the system generates a pseudo-random number between 0.0 and 100.0. If the number is less than or equal to Survival Chance, the entity is saved. If the number is greater, the system yields, allowing the fatal damage to proceed normally.
  • Usage: setting this to 100.0 ensures total reliability. Lower values introduce RNG elements.

Configuration Examples

Example A: Guaranteed Safety Configures a reliable safe zone where death is mathematically impossible.

- Type: IMMORTALITY_FIELD
  Min Health: 20.0
  Survival Chance: 100.0

Example B: Last Stand Configures a zone where players survive fatal damage but are left with only half a heart, emphasizing the danger.

- Type: IMMORTALITY_FIELD
  Min Health: 1.0
  Survival Chance: 100.0

Example C: Unreliable Shield Configures a zone where the protection matrix fails 50% of the time.

- Type: IMMORTALITY_FIELD
  Min Health: 10.0
  Survival Chance: 50.0

Example D: Full Restore Configures a zone that acts as an instant-resurrection point, fully healing the player.

- Type: IMMORTALITY_FIELD
  Min Health: 20.0
  Survival Chance: 100.0

3. Potion Duration Boost Configuration

Type Identifier: POTION_DURATION_BOOST

The Potion Duration Boost effect functions as a maintenance module for existing status effects. It does not generate new effects but rather detects and modifies specific effects already present on the entity.

Functional Description

On every update tick (usually once per second), the system retrieves the list of active potion effects on the target entity. It checks this list against the configured Potion Effect Type. If a match is found:

  1. The system determines the current remaining duration of the effect in ticks.
  2. The system adds the Duration Boost Tick value to this current duration.
  3. The modified duration is written back to the entity.

This creates a dynamic equilibrium. If the Duration Boost Tick matches the tick rate of the beacon (e.g., adding 20 ticks every 20 ticks), the effect duration freezes. If the boost is higher, the duration grows. If lower, the duration decays slower than normal.

Configuration Parameters

Potion Effect Type

Defines the specific effect type to target for boosting.

  • Format: String
  • Scope: Must match a valid Minecraft potion name (e.g., NIGHT_VISION, WATER_BREATHING).
  • Limitation: The module targets a single effect type. To boost multiple types (e.g., Strength and Speed), multiple instances of this effect module must be configured in the beacon.

Duration Boost Tick

Defines the integer amount of ticks added to the effect's duration per cycle.

  • Format: Integer
  • Time Scale: 20 ticks equals 1 second.
  • Threshold: To achieve a net increase in duration, this value must exceed the update interval of the beacon. If the beacon updates every 2 seconds (40 ticks), a value of 41 or higher is required to "charge" the potion.

Configuration Examples

Example A: Night Vision Extender Configures infinite extension for Night Vision, assuming a 1-second update cycle.

- Type: POTION_DURATION_BOOST
  Potion Effect Type: NIGHT_VISION
  Duration Boost Tick: 40

Example B: Resistance Stabilizer Configures a value ensuring Resistance potions do not expire.

- Type: POTION_DURATION_BOOST
  Potion Effect Type: DAMAGE_RESISTANCE
  Duration Boost Tick: 25

Example C: Slow Decay Water Breathing Configures an extension that slows down the expiry of Water Breathing by 50%.

- Type: POTION_DURATION_BOOST
  Potion Effect Type: WATER_BREATHING
  Duration Boost Tick: 10

Example D: Invisibility Sustainer Configures infinite extension for Invisibility.

- Type: POTION_DURATION_BOOST
  Potion Effect Type: INVISIBILITY
  Duration Boost Tick: 30

4. Flight Configuration

Type Identifier: FLY

The Flight module manipulates the player's allowFlight capability flag. This is the boolean flag used by Creative Mode to enable double-tap flight.

Functional Description

Upon every scan cycle, the beacon validates if the player is within the radius.

  1. Entry Logic: If the player enters the radius and matches the criteria, player.setAllowFlight(true) is invoked.
  2. Exit Logic: When the player exits the radius, or if the beacon is destroyed, the system performs a cleanup safety check. It verifies if the player is in Creative or Spectator mode. If the player is in Survival or Adventure mode, player.setAllowFlight(false) and player.setFlying(false) are invoked immediately.

The system includes an optional height delimiter to create "Ceilings" for flight within the zone.

Configuration Parameters

Height

Defines a vertical boundary relative to the beacon core's Y-coordinate.

  • Format: Integer
  • Negative Values: A value of -1 disables the height check logic entirely. Flight is valid at any Y-level within the horizontal radius.
  • Positive Values: Defines a ceiling relative to the beacon. If set to 50 and the beacon is at Y=64, flight is disabled if the player exceeds Y=114.
  • Enforcement: Players exceeding the height are considered "Out of Range" and will immediately lose flight capability, causing them to fall.

Configuration Examples

Example A: Unrestricted Flight Configures flight with no vertical limitations.

- Type: FLY
  Height: -1

Example B: Low Altitude Hover Configures flight limited to 10 blocks above the beacon.

- Type: FLY
  Height: 10

Example C: Skyscraper Zone Configures flight allowing access to tall structures up to 100 blocks.

- Type: FLY
  Height: 100

Example D: Ground Effect Configures flight limited to 2 blocks, effectively allowing high jumps/hovering but not true flight.

- Type: FLY
  Height: 2

5. Magnet Configuration

Type Identifier: MAGNET

The Magnet module applies a physics vector to entities within the radius, altering their trajectory. It supports both attraction and repulsion mechanics.

Functional Description

The system calculates a 3D vector from the entity's current position to the beacon's center. Vector direction = beaconLocation.toVector().subtract(entity.getLocation().toVector()).normalize(); This normalized direction vector is then multiplied by the configured Magnitude scalar. The resulting velocity is added to the entity's current velocity. This process repeats every tick, creating a smooth, continuous force.

Configuration Parameters

Magnitude

Defines the scalar strength of the velocity vector applied to the entity.

  • Format: Double
  • Direction - Attraction: Positive values (e.g., 0.2) create a force pulling the entity towards the source.
  • Direction - Repulsion: Negative values (e.g., -0.5) create a force pushing the entity away from the source.
  • Intensity:
    • 0.1: Gentle drift, easily resisted by walking.
    • 0.5: Strong current, difficult to walk against.
    • 1.0+: Extreme force, likely to launch entities violently.

Configuration Examples

Example A: Gentle Collection Configures a subtle pull for items.

- Type: MAGNET
  Magnitude: 0.2

Example B: Strong Defense Configures a powerful repulsion field to keep mobs away.

- Type: MAGNET
  Magnitude: -0.8

Example C: Static Field Configures a zero-magnitude field (functionally inert, possibly for visual testing).

- Type: MAGNET
  Magnitude: 0.0

Example D: Black Hole Configures an inescapable gravity well.

- Type: MAGNET
  Magnitude: 1.5

6. Spawner Boost Configuration

Type Identifier: SPAWNER_BOOST

The Spawner Boost module scans the local environment for CreatureSpawner tile entities (Mob Spawners). It directly manipulates the NBT data of these tiles to accelerate their spawn cycles.

Functional Description

Upon identifying a Spawner Tile Entity within the beacon's range, the system reads its current delay variables: SpawnDelay, MinSpawnDelay, and MaxSpawnDelay. It applies a reduction formula to these integers: NewDelay = CurrentDelay * (1.0 - (Percentage / 100.0)) If the Speed Up Percentage is 50%, a delay of 800 ticks (40 seconds) is reduced to 400 ticks (20 seconds). The system essentially compresses the timeline for the spawner logic.

Configuration Parameters

Speed Up Percentage

Defines the percentage of time removed from the vanilla spawn delay cycle.

  • Format: Double (0.0 to 100.0)
  • Linear Scale:
    • 10.0: 10% faster (1.11x rate).
    • 50.0: 50% faster (2.0x rate).
    • 75.0: 75% faster (4.0x rate).
    • 90.0: 90% faster (10.0x rate).
  • Safety: Values approaching 100.0 result in delay values of 0 or 1, causing the spawner to attempt a spawn event on every single update tick if conditions allow.

Configuration Examples

Example A: Moderate Boost Configures a 25% reduction, providing a noticeable but safe increase.

- Type: SPAWNER_BOOST
  Speed Up Percentage: 25.0

Example B: Double Speed Configures a 50% reduction, effectively doubling the mob output.

- Type: SPAWNER_BOOST
  Speed Up Percentage: 50.0

Example C: Extreme Overclock Configures a 90% reduction.

- Type: SPAWNER_BOOST
  Speed Up Percentage: 90.0

Example D: Minimum Viable Boost Configures a 5% reduction.

- Type: SPAWNER_BOOST
  Speed Up Percentage: 5.0

7. Crops Boost Configuration

Type Identifier: CROPS_BOOST

The Crops Boost module interacts with organic blocks implementing the Ageable data interface. This includes most crops (Wheat, Carrots, Potatoes, Beetroots) and some growth blocks (Nether Wart, Cocoa, Cactus, Sugar Cane, Kelp, Bamboo).

Functional Description

The system performs a block scan of the radius. When it encounters a valid Ageable block, it retrieves its current Age integer. It increments this integer by the configured Speed Up Stage. NewAge = CurrentAge + StageIncrement If the new age exceeds the maximum age for that block type (e.g., 7 for Wheat), the age is clamped to the maximum. This simulates the effect of Bone Meal application without requiring the item.

Configuration Parameters

Speed Up Stage

Defines the integer quantity added to the crop's Age property per update interval.

  • Format: Integer
  • Value 1: The crop advances by one growth stage.
  • Value 7: The crop instantly advances to maturity (if maximum is 7).

Crops Whitelist

Defines a specific list of Material types to target.

  • Format: String List
  • Filter Logic:
    • If the list is Empty, the system targets ALL blocks that are Ageable.
    • If the list is Populated, the system checks block.getType() against the list. Non-matching blocks are ignored.

Prevent Instant Growth

Toggles safety logic for instant-break crops. Some crops rely on the specialized mechanics of growing into the block AIR above them (Sugar Cane, Cactus, Bamboo, Kelp). Force-setting their age data when they are already grown can cause the block to recognize an invalid state and break (drop as an item).

  • Format: Boolean (true / false)
  • True: The system acts conservatively. It checks if the crop is already at max age or height limit. If so, it skips the boost.
  • False: The system applies the boost blindly. This is aggressive and may cause automated harvesting by breaking the plant.

Configuration Examples

Example A: Wheat Specialist Configures conservative growth logic strictly for Wheat.

- Type: CROPS_BOOST
  Speed Up Stage: 1
  Prevent Instant Growth: true
  Crops Whitelist:
    - WHEAT

Example B: General Agriculture Configures rapid growth for standard food crops.

- Type: CROPS_BOOST
  Speed Up Stage: 2
  Prevent Instant Growth: true
  Crops Whitelist:
    - CARROTS
    - POTATOES
    - BEETROOTS

Example C: Industrial Bamboo Configures aggressive growth for a bamboo farm, potentially causing breaks.

- Type: CROPS_BOOST
  Speed Up Stage: 1
  Prevent Instant Growth: false
  Crops Whitelist:
    - BAMBOO

Example D: Nether Wart Farm Configures specific targeting for Nether Wart.

- Type: CROPS_BOOST
  Speed Up Stage: 1
  Prevent Instant Growth: true
  Crops Whitelist:
    - NETHER_WART

8. Keep Chunk Loaded Configuration

Type Identifier: KEEP_CHUNK_LOADED

The Keep Chunk Loaded module interacts with the server's chunk provider and ticket manager.

Functional Description

By default, Minecraft unloads chunks (segments of the world) to save memory when no players are nearby. This pauses all logic within that chunk (redstone, furnaces, growth). This module registers a persistent ticket with the server for the specified chunks. This forces the server to maintain the chunk in the memory heap and continue processing its tick logic (Redstone, Entity AI, Tile Entity logic) even in the absence of players.

Configuration Parameters

Single Chunk

Scope selector for the loading logic.

  • Format: Boolean (true / false)
  • True: The logic is applied strictly to the single 16x16 chunk containing the beacon block. This is a minimal-impact mode.
  • False: The logic is applied to every chunk intersected by the calculated radius of the beacon. For a large radius, this can encompass dozens or hundreds of chunks.

Load Chunk

Behavior selector for currently unloaded chunks.

  • Format: Boolean (true / false)
  • True (Active Load): If the system detects a target chunk is currently unloaded, it issues a command to load it immediately from disk.
  • False (Passive Sustain): The system only registers tickets for chunks that are already loaded. It keeps them loaded, but will not "wake up" a region that is currently dormant.

Configuration Examples

Example A: Local Persistence Configures persistence for the beacon's chunk only.

- Type: KEEP_CHUNK_LOADED
  Single Chunk: true
  Load Chunk: false

Example B: Area Persistence Configures persistence for the entire radius, actively loading the area.

- Type: KEEP_CHUNK_LOADED
  Single Chunk: false
  Load Chunk: true

Example C: Passive Area Hold Configures persistence for the area, but only if a player visits first to load it.

- Type: KEEP_CHUNK_LOADED
  Single Chunk: false
  Load Chunk: false

Example D: Critical Chunk Configures aggressive loading for a single critical chunk.

- Type: KEEP_CHUNK_LOADED
  Single Chunk: true
  Load Chunk: true

9. Apply Mending Configuration

Type Identifier: APPLY_MENDING

The Apply Mending module serves as an automated equipment repair station. It emulates the behavior of the "Mending" enchantment absorbing XP orbs, but uses the beacon's operation as the fuel source.

Functional Description

On every update cycle, the system iterates over the target player's inventory contents. The iteration order typically prioritizes: Main Hand -> Offhand -> Armor Slots -> Main Inventory. For each item stack encountered:

  1. Enchantment Check: The system verifies if the item contains the Mending enchantment.
  2. Damage Check: The system verifies if the item has current durability damage (durability > 0).
  3. Repair Action: If both checks pass, the system reduces the damage value by the configured Mending Repair Amount. The process repeats until the repair amount for the cycle is exhausted or all items are fully repaired.

Configuration Parameters

Mending Repair Amount

Defines the quantity of durability points restored per update cycle.

  • Format: Integer
  • Unit: 1 unit equals 1 point of durability.
  • Impact: Higher values result in faster repair. A Diamond Pickaxe has 1561 durability. A rate of 10 would repair it fully in roughly 156 seconds.

Configuration Examples

Example A: Standard Repair Configures a moderate repair rate.

- Type: APPLY_MENDING
  Mending Repair Amount: 5

Example B: Fast Repair Configures a rapid repair rate.

- Type: APPLY_MENDING
  Mending Repair Amount: 20

Example C: Trickle Repair Configures a very slow repair rate.

- Type: APPLY_MENDING
  Mending Repair Amount: 1

Example D: Instant Fix Configures a rate likely to fully repair items in one or two cycles.

- Type: APPLY_MENDING
  Mending Repair Amount: 500

10. Command Executor Configuration

Type Identifier: COMMAND_EXECUTOR

The Command Executor module acts as a trigger for server commands. This allows the beacon to interface with other plugins, scripts, or vanilla command logic.

Functional Description

When the effect is triggered (on tick), the system takes the configured command string.

  1. Parsing: It scans the string for variables (placeholders).
  2. Substitution: It replaces {player} with the name of the target entity.
  3. Dispatch: It sends the final string to the server's Command Map for execution.

Configuration Parameters

Command

Defines the command syntax to be executed.

  • Format: String
  • Syntax: Standard Minecraft command syntax (excluding the leading / in some contexts, though typically supported).
  • Placeholders:
    • {player}: Resolves to the player's username.
    • {uuid}: Resolves to the player's unique ID.

Console

Defines the identity of the command sender.

  • Format: Boolean (true / false)
  • True: The command is executed as the ConsoleSender. This grants the command full Operator (OP) privileges. It bypasses all permission checks.
  • False: The command is executed as the Player themselves. The player attempting to run the command must have the necessary permissions (e.g., if the command is gamemode creative, the player needs minecraft.command.gamemode).

Configuration Examples

Example A: Economy Integration Configures a monetary reward using an economy plugin command.

- Type: COMMAND_EXECUTOR
  Command: "eco give {player} 5"
  Console: true

Example B: Messaging Configures a title message sent to the player.

- Type: COMMAND_EXECUTOR
  Command: "title {player} title {\"text\":\"Welcome to the Zone\"}"
  Console: true

Example C: Teleportation Configures a forced teleport command.

- Type: COMMAND_EXECUTOR
  Command: "tp {player} 0 100 0"
  Console: true

Example D: User Action Configures the player to say something in chat.

- Type: COMMAND_EXECUTOR
  Command: "say I am at the beacon!"
  Console: false

11. Glow Configuration

Type Identifier: GLOW

The Glow module applies the GLOWING status effect/metadata to the entity. This creates a spectral outline around the entity's model, visible through solid blocks.

Functional Description

The system interacts with the entity's metadata or utilizes packet-based rendering (depending on the method) to flag the entity as glowing. This instructs the client-side renderer to draw the outline.

Configuration Parameters

Method

Defines the technical implementation for rendering the glow.

  • AUTO: The system detects the server version and selects the most appropriate method.
  • BLOCK_DISPLAY: Utilizes BlockDisplay entities (Available in Minecraft 1.19.4+). This method provides a sharp, stable outline.
  • SHULKER: Utilizes legacy invisible Shulker entities riding the target. This is a workaround for older versions (1.9 - 1.12).
  • SCOREBOARD: Utilizes vanilla Scoreboard Teams to apply the glowing color. This is the most native method but requires team management.

Configuration Examples

Example A: Standard Glow Configures a standard outline using automatic detection.

- Type: GLOW
  Method: AUTO

Example B: Sharp Glow Configures a high-fidelity outline using Block Displays.

- Type: GLOW
  Method: BLOCK_DISPLAY

Example C: Legacy Glow Configures the Shulker method for legacy compatibility.

- Type: GLOW
  Method: SHULKER

Example D: Team Glow Configures the Scoreboard method.

- Type: GLOW
  Method: SCOREBOARD

Server Owner Reference

Installation
Commands & Permissions
Config.yml
Beacon.yml
GUI Reference
All Beacon Effects
All Conditions & Filters
Effect File Structure
Storage Reference

Tutorials

VIP-Only Effects
Custom Recipes
Multi-Tier Economy
MySQL Setup

Player Guide

Getting Started
Managing Beacons
Upgrading Effects
Access Control

Developer Documentation

API Basics
Custom Effects
Team Providers

Clone this wiki locally