Expected behavior
When a plugin sets a Lever's powered state via BlockData
(Lever.setPowered() + Block#setBlockData()) and also calls
Block#setBlockData() with applyPhysics=true on the block the lever is
attached to, any redstone dust or redstone torches placed on/adjacent to
that block should update to reflect the new power state - the same way
they would if a player manually right-clicked the lever.
Observed/Actual behavior
Redstone dust and redstone torches placed on the block a plugin-controlled
Lever is attached to do not update when the lever's power state is changed
programmatically via the Bukkit API, even though:
- Lever.setPowered(state) is called and Block#setBlockData(lever) is applied
- Block#setBlockData(block.getBlockData(), true) is called on the source
block (the block the lever is attached to) to force physics
- Synthetic BlockRedstoneEvent objects are fired for both the lever and
the source block afterwards
Despite doing everything the public API exposes for this purpose, adjacent
redstone dust/torches remain in their old state until an unrelated,
manual block update (e.g. a separate redstone signal briefly touching the
same block) forces a refresh.
This was confirmed by a CraftBook maintainer (github.com/EngineHub/CraftBook),
who stated: "This part of the interaction is handled by the server software,
CraftBook updates the lever and it's up to Spigot/Paper to actually do those
further side effects. The server APIs don't actually expose a way to force
this to happen beyond what CraftBook already does."
Steps/models to reproduce
- Write a plugin that, on some trigger, programmatically toggles a Lever's
powered state:
Switch lever = (Switch) leverBlock.getBlockData();
lever.setPowered(true);
leverBlock.setBlockData(lever);
attachedBlock.setBlockData(attachedBlock.getBlockData(), true);
- Place redstone dust directly on top of the block the lever is attached
to (attachedBlock)
- Trigger the plugin's lever toggle
- Observe: the lever visually flips, but the redstone dust on the same
block does not light up/update to reflect the new power state
- Manually cause an unrelated block update on that block (e.g. briefly
touch it with a separate redstone signal) - the redstone dust then
correctly updates to match the lever's actual state
Plugin and Datapack List
Server Plugins (16):
Paper Plugins (1):
- BKCommonLib
Bukkit Plugins (15):
- CraftBook, Essentials, MachinaBuilder, MachinaChem, MachinaCore, MachinaDrill,
MachinaPump, mcMMO, Movecraft, ProtocolLib, SignManager, Train_Carts,
TreeFeller, WorldEdit, WorldGuard
Datapacks:
There are 4 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)],
[file/movecraft-data.zip (world)], [paper (built-in)]
There are no more data packs available
Paper version
This server is running Paper version 1.21.11-132-ver/1.21.11@c5eb079 (2026-05-11T11:43:09Z) (Implementing API version 1.21.11-R0.1-SNAPSHOT)
You are running the latest version
Other
Diagnosed via CraftBook (github.com/EngineHub/CraftBook), where all
Integrated Circuits (ICs) that output redstone directly from the IC's
own block fail to update neighboring redstone dust/torches after a
lever toggle, requiring an unrelated manual block update as a workaround.
Related previous CraftBook issue: #1199 ("Light switch bug") describes
a narrower instance of the same underlying pattern.
Expected behavior
When a plugin sets a Lever's powered state via BlockData
(Lever.setPowered() + Block#setBlockData()) and also calls
Block#setBlockData() with applyPhysics=true on the block the lever is
attached to, any redstone dust or redstone torches placed on/adjacent to
that block should update to reflect the new power state - the same way
they would if a player manually right-clicked the lever.
Observed/Actual behavior
Redstone dust and redstone torches placed on the block a plugin-controlled
Lever is attached to do not update when the lever's power state is changed
programmatically via the Bukkit API, even though:
block (the block the lever is attached to) to force physics
the source block afterwards
Despite doing everything the public API exposes for this purpose, adjacent
redstone dust/torches remain in their old state until an unrelated,
manual block update (e.g. a separate redstone signal briefly touching the
same block) forces a refresh.
This was confirmed by a CraftBook maintainer (github.com/EngineHub/CraftBook),
who stated: "This part of the interaction is handled by the server software,
CraftBook updates the lever and it's up to Spigot/Paper to actually do those
further side effects. The server APIs don't actually expose a way to force
this to happen beyond what CraftBook already does."
Steps/models to reproduce
powered state:
Switch lever = (Switch) leverBlock.getBlockData();
lever.setPowered(true);
leverBlock.setBlockData(lever);
attachedBlock.setBlockData(attachedBlock.getBlockData(), true);
to (attachedBlock)
block does not light up/update to reflect the new power state
touch it with a separate redstone signal) - the redstone dust then
correctly updates to match the lever's actual state
Plugin and Datapack List
Server Plugins (16):
Paper Plugins (1):
Bukkit Plugins (15):
MachinaPump, mcMMO, Movecraft, ProtocolLib, SignManager, Train_Carts,
TreeFeller, WorldEdit, WorldGuard
Datapacks:
There are 4 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)],
[file/movecraft-data.zip (world)], [paper (built-in)]
There are no more data packs available
Paper version
This server is running Paper version 1.21.11-132-ver/1.21.11@c5eb079 (2026-05-11T11:43:09Z) (Implementing API version 1.21.11-R0.1-SNAPSHOT)
You are running the latest version
Other
Diagnosed via CraftBook (github.com/EngineHub/CraftBook), where all
Integrated Circuits (ICs) that output redstone directly from the IC's
own block fail to update neighboring redstone dust/torches after a
lever toggle, requiring an unrelated manual block update as a workaround.
Related previous CraftBook issue: #1199 ("Light switch bug") describes
a narrower instance of the same underlying pattern.