When players send projects through portals that are tagged as coming from a player, they lose that player tag once they leave the other side of the portal.
This affects Nether portals and End portals.
End gateways work as we would expect them to. (fishing rod bobber still doesn't go through gateways)
Entities that have player tags (remind me if I have over looked any)
Arrow, potion, snowball, egg, enderpearl, fishing rod bobber, TNT
What should happen is that when the player tag entity leave a portal it should keep the tag from which player it came from so that if it kills a player or mob on the other side of the portal it is registered as a player kill.
This causes arrows shot by a player through a portal to kill a player on the other side despite PVP being disabled on the server config.
Original Post
What I expected to happen was the arrows would just look cool
What actually happened was the arrows shot through the portal set the other player on fire
Steps to Reproduce:
1. Shoot a arrow through a portal whilst pvp is off, (which is possible to do in a vanilla servers config) at another player who is on the other side of the portal
Related issues
is duplicated by
relates to
Comments
migrated
galaxy_2alex
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. If this has been done, we can reopen the issue.
Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. We will reopen it as soon as the requested information has been delivered.
Ray
Yes, this affects all versions currently.
It's in 16w38a snapshots.
Why this works is because when the player sends anything that is labeled as coming from a player (arrow shot by a player, potions through by a player, egg/snow ball through by a player) the game doesn't remember the player labeling on that entity. So once the arrow goes through the portal the game sees it as a normal arrow just as if it came from a dispenser. Since it is a normal arrow it does damage to players on the other side despite it coming from another player and the server having pvp turned off.
This is pretty much the same problem I am having so it would be great if this was reopened.
[Mod] Neko
Changed reporter to @unknown, as the original reporter is no longer active.
Uriel Salischiker
Is this still a issue in the latest version of the game(currently 1.13.1)?
If so, please add it to the affected versions, thanks!
migrated
MC-16937 is still an issue in 1.13.1, so this one also.
migrated
Same for 19w06a
migrated
Still the same in 20w06a.
ncolyer11
yup def happens coz it isn't stored in nbt and so it gets wiped when it goes through the portal, anyways this is still a bug in both 1.18.2 and 22w15a sadly
migrated
The interesting thing is that, at least for my tests with arrows, the Owner ID stays with the arrow even after it goes through the portal. All the NBT data stays, but because the Owner ID can only be connected to a player in the same dimension, it isn't able to find that player and apply specific effects to whatever is getting shot.
I was wondering if you could somehow introduce the UUID of the Owner in the same dimension by summoning in that player's player head, but no dice.
Brain81505
Can confirm in 1.19.4
PencilSharpener
Relates to MC-260591. What seems to happen is that the cached entity reference to the owner (that used to cause MC-226344) doesn't carry over when the projectile is recreated at the other end of the portal, and then looking up the owner by UUID fails because it's in a different dimension. If you go through the portal yourself before the projectile hits then credit is applied as expected.
etanaratsastaja
This possibly happens because if the arrow passes trough the portal it actually no longer is shot by somebody, but just summoned by the portal using the exact same NBT.
In short, the arrow is no longer a pvp shot when shot trough a portal.