(thelastblo) Is it possible to get the entity in a death message

[lyric needle]

I was wondering if it is possible to get the entity that killed a player if it happened indirectly. For example, if a player jumped off a cliff trying to escape a wolf, and the default death message says "Player was doomed to fall by Wolf" is it possible to get the wolf entity? My goal is to make custom death messages for a custom mob for all cases so it doesnt say wolf whenever a player dies to this custom wolf mob whether it be directly or indirectly.

[zenith harness]

(thelastblo) Is it possible to get the entity in a death message

[zenith harness]

Hi I'm AutoThreadBot! Don't mind me, I'll just be adding the helper team to this thread so they can see it. A human will get to you soon.

[lyric needle]

im aware of <context.damager> in the on player dies event, but this tag doesnt exist if the wolf didnt directly kill the player

[placid estuary]

Old threads state you may need to use the damage event to remember who attacked the player last.

There is some last_damage tags, but nothing for the attacker/damager.

[ebon cloud]

!e entity dies

[desert birch]

Event: entity dies|death

Group

Entity

Event Lines

<entity> dies|death

Switches

by:<entity> to only process the event if the killer is known and matches the specified entity matcher.
cause:<cause> to only process the event if it was caused by a specific damage cause.

Triggers

when an entity dies. Note that this fires *after* the entity dies, and thus some data may be lost from the entity.
The death can only be cancelled on Paper.

Has Player

when the entity that died is a player. - this adds switches flagged:<flag name> + permission:<node>, in addition to the <player> link.

Has NPC

when the entity that died is an NPC.

Context

<context.entity> returns the EntityTag that died.
<context.damager> returns the EntityTag damaging the other entity, if any.
<context.projectile> returns the EntityTag of a projectile used to kill the entity, if one was used.
<context.message> returns an ElementTag of a player's death message.
<context.cause> returns an ElementTag of the cause of the death. See !language damage cause...
<context.drops> returns a ListTag of all pending item drops.
<context.xp> returns an ElementTag of the amount of experience to be dropped.
<context.keep_inventory> returns true if the player dying is set to keep their inventory, false if...

Determine

ElementTag to change the death message.
"NO_DROPS" to specify that any drops should be removed.
"NO_XP" to specify that any XP orbs should be removed.
ListTag(ItemTag) to specify new items to be dropped.
ElementTag(Number) to specify the new amount of XP to be dropped.
"KEEP_INV" to specify (if a player death) that the inventory should be kept.
"KEEP_LEVEL" to specify (if a player death) that the XP level should be kept.
"NO_MESSAGE" to hide a player death message.

Has Known Location

True - this adds switches in:<area> + location_flagged:<flag name>.

[ebon cloud]

Seems there is a <context.damager> tag in the event.

[placid estuary]

User states they're aware but it's null if it isn't a direct kill.

[ebon cloud]

I missed that. My bad.

Flag the player with a map/list on damage event with your needed info. Then, use that history to pull data for your own logic/messages.

[lyric needle]

mk thanks yall for the help

[sweet veldt]

Resolved

Thread closed as resolved.

[long spade]

Hy, i think i have the same question

[sweet veldt]

Thread Reopened

Thread was manually reopened by @long spade.

[long spade]

When player kills player death message gives the display name of context entity that died, but for context damager it's just <context.damager>

sw_kill:
    type: world
    events:
        after player dies:
        - announce '<&c><context.damager.display_name> <&6>stabed <&4><context.entity.display_name>'

[placid estuary]

Don't re-open posts. Make your own post.

!makepost

[desert birch]

Info: makepost

If you have a support question, please make a forum post for it!

"But it's just a yes/no question!"
We hear this from users quite often, and, frankly, it almost never is just a yes/no question - many seemingly simple questions lead to long answers or complex debugging or interesting discussions or...

"But you've probably gotten this question before and have the answer prepared"
All the more reason to use forum posts! When you're typing the title, it auto-searches existing posts, and thus if you're asking a repeat question, you'll instantly find the prior time it was asked, and the answer it had then, before you even press enter on your post!

"But it's not worth bothering"
Good news: it takes almost no more effort to make a post than to type in a channel! It's really really easy!

"But I don't want to annoy the helpers"
A forum post won't annoy us! We prefer it! Most of us don't get pinged or anything, it's fine!