Component edit rights

Introduction

Component edit rights decide what a player — someone without the lasers.edit permission — is allowed to do to a puzzle component: turn a mirror support, take or place its mirror, turn a laser sender or a concentrator, resize a gravitational sphere.

A right is resolved through three levels, from the most general to the most specific:

1. the server default, in config.yml;
2. the area default, set in the Area configuration menu;
3. the per-component value, set in the component's own configuration menu.

The most specific level that has an opinion wins. A component that decides a right for itself beats its area — in either direction: it can be more permissive than the area it stands in, not only more restrictive.

The four rights

Right	Applies to
Rotate horizontally	mirror support, laser sender, laser receiver, concentrator
Rotate vertically	mirror support, laser sender, laser receiver, concentrator
Handle the mirror (take it off, put one back)	mirror support
Resize	gravitational sphere

A component only ever shows the rights that mean something for it: a laser sender has two rotation cells and nothing else, a gravitational sphere has a single resize cell.

Level 1 — the server default (config.yml)

The player_edit_rights.<component_type>.<right> keys in config.yml set the server-wide default for every right of every component type. See the Config reference.

⚠️ These defaults are a seed, not a live fallback. They are read once, when an area is created, and copied into it. Editing config.yml afterwards changes the areas you build from then on — it never reaches back into a puzzle that already exists. This is deliberate: a server-wide edit must not silently rewrite the rules of every published puzzle at once.

(This differs from a setting like component_info, which is a single global switch applying uniformly to every area, existing ones included. Edit rights are instead copied per area at creation, so each area keeps its own values. Do not expect a config.yml change to move an area that already exists.)

Level 2 — the area default

The Area configuration menu holds a matrix: one row per right, one column per kind of component. Each cell is the default that a component of that kind inherits when it decides nothing for itself.

Applying a change to the components already in the area

When you change an area-level value and the area already contains components of that kind, you are asked what becomes of them:

• Apply to the existing ones — every component of that kind obeys the area again, losing any value you had set on it individually. This is destructive and cannot be undone; the confirmation tells you how many components change and how many hand-set values you are about to lose.
• Only the future ones — the components already here keep exactly what they do today; only the components you build from now on take the new value.

⚠️ "Only the future ones" is a one-way door. To keep the existing components where they are, the plugin writes the current value onto each of them individually. From then on this area no longer decides that right for them — they hold their own value — until you use Apply to the existing ones, which hands the inheritance back.

Level 3 — the per-component value

Each component's own configuration menu shows one cell per right it carries. A cell has four states — the shape says the answer, the colour says who gave it:

Icon	Meaning
green tick	allowed — decided on this component
red cross	denied — decided on this component
grey tick	allowed — inherited from the area
grey cross	denied — inherited from the area

Clicking a cell walks a three-step cycle: inherited → allowed → denied → inherited. Going back to inherited is one more click, never a hidden gesture — it is how you undo an override and let the component follow its area again.

Inherited is a relation, not a value

A component that decides nothing does not store "allowed" or "denied" — it stores nothing, and reads its area. So a component copied and pasted into another area obeys that area, not the one it came from. Only a component that decided a right for itself carries that decision across a copy.

What deliberately ignores the rights

Edit rights gate the player, not the machinery. The following bypass them on purpose:

• Component synchronisation — a synced partner still moves when its twin does, even if its own rights forbid a player from moving it.
• Scheduled actions — a scheduled rotation runs regardless of the rights.
• The /lasers component rotate command and other editor commands.

So "I locked this mirror and the sync still turns it" is expected behaviour, not a bug.

The reflecting and filtering spheres are not covered

The mirror of a reflecting sphere and of a filtering sphere can be taken and placed by any player, and there is no setting to prevent it — deliberately. A filtering sphere is a coloured filter, which Minecraft's own stained glass already provides without any player interaction; the reflecting sphere may gain the right later. If you are looking for a lock on those spheres, there is none by design.

The component's head tells the truth

There is no "blocked mode" any more. A component's in-world head is simply the reading of its effective rights — "blocked" is just "no right granted". A mirror support in an area that forbids rotation now shows that it cannot be turned, where older versions displayed a free-looking head on a support nobody could move.

The refusal message

When a player is refused an action, the component_blocked_message config option controls whether they are told so. It now reaches every refused action; previously it only fired for a mirror support locked on its own.