PaperMC / PaperMC/Paper

EntityKnockbackEvent not firing for other TNT when a TNT explodes

Open
#10,452 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status: needs triage type: bug version: 1.20.4
Dominant language
Java
Stars
12.7k
Forks
3.5k
Avg merge
3d 13h
Merged PRs (30d)
11

Description

Expected behavior

I expect the EntityKnockbackEvent to also fire when a primed TNT pushes another primed TNT
Additionally, it would also be nice if there was an EntityExplodedEvent#getEntityList()

Observed/Actual behavior

The event does not fire when event.getHitBy() and event.getEntity() are both TNTPrimed

Steps/models to reproduce

Build a simple cannon like so:
image

Add the following EventListener:

public class TestListener implements Listener {
    public void onEntityKnockback(EntityKnockbackByEntityEvent event) {
        Bukkit.broadcastMessage("HitBy: " + event.getHitBy().getType() + " Entity: " + event.getEntity().getType());
    }
}

Shoot the cannon

Plugin and Datapack List

FAWE, kotlin-stdlib, LuckPerms, PlaceholderAPI, PlugManX, spark, CustomPlugin

Paper version

[14:46:40 INFO]: This server is running Paper version git-Paper-493 (MC: 1.20.4) (Implementing API version 1.20.4-R0.1-SNAPSHOT) (Git: a6b6ecd)
You are running the latest version
Previous version: git-Paper-485 (MC: 1.20.4)

Other

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the TNT cannon scenario with the provided EntityKnockbackByEntityEvent listener and inspect the event-handling path for TNTPrimed entities. Confirm whether the event should fire for TNT-to-TNT knockback, and separately assess the requested EntityExplodedEvent#getEntityList() API addition; done means the intended behavior is covered and verified.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend-api-design
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.