TNTPrimeEvent#getPrimingBlock() always returns null when cause is REDSTONE since 1.21.2
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 12.7k
- Forks
- 3.5k
- Avg merge
- 3d 13h
- Merged PRs (30d)
- 11
Description
Expected behavior
When a TNT block is primed by redstone, TNTPrimeEvent#getPrimingBlock() should return the redstone component (e.g., lever, button, repeater) that triggered it — as it did before Minecraft 1.21.2.
Observed/Actual behavior
Since Minecraft 1.21.2, when TNT is primed via redstone, TNTPrimeEvent#getPrimingBlock() always returns null.
After checking the NMS, it seems that the Block#neighborChanged method signature changed from BlockPos sourcePos to @Nullable Orientation wireOrientation, and now the value passed to the event is always null.
Steps/models to reproduce
Create a simple plugin that listens to TNTPrimeEvent.
ej:
@EventHandler
public void onTNTPrime(TNTPrimeEvent event) {
if (!event.getCause().equals(TNTPrimeEvent.PrimeCause.REDSTONE)) return;
logger.info(event.getPrimingBlock() + "");
}
Plugin and Datapack List
Only the test plugin described above (no other plugins or datapacks).
Paper version
> ver
[13:18:05 INFO]: Checking version, please wait...
[13:18:05 INFO]: This server is running Paper version 1.21.8-60-main@29c8822 (2025-09-06T21:49:13Z) (Implementing API version 1.21.8-R0.1-SNAPSHOT)
You are running the latest version
Other
This behavior seems to originate from CraftBukkit’s change to the TNT block logic:
Although the change is technically on CraftBukkit’s side, since Paper is now a hard fork, it might be worth considering whether restoring the previous behavior (returning the redstone source block) would be beneficial for plugin compatibility.
Would you consider handling this case to maintain consistency with pre-1.21.2 behavior?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the TNTPrimeEvent listener and the NMS Block#neighborChanged path described in the linked CraftBukkit TNT patch. Reproduce redstone priming with the provided listener, then trace how the redstone source reaches the event. Done means getPrimingBlock() reports the triggering component for redstone while preserving other causes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100