I believe this is Works As Intended, no? The f3 menu is now meant to be accessible from anywhere, including the pause menu and title screen
Can confirm, I ran into this issue while using the Debug Stick
Confirmed in 1.21.8. Also, if I recall correctly, the “eyeline” height being at 0 used to be the default behavior no matter what the interaction’s width and height were. Personally I would consider the current behavior after changing width and height to be bugged: it should just always be at 0. (This makes it very convenient for “bundling” entities together by making things ride an interaction: the hitbox of the interaction should not affect the riding height of the entities, because often times it’s convenient to have entities inside the interaction.)
Confirmed in 1.21.5.
I’d also like to point out that if this were “fixed” (as in the trigger was made to only respond to entities), universal damage tracking would no longer be possible in datapacks, period. As it stands now, we can force this trigger to only respond to entities by including a check for the direct entity in the provided damage
condition, so this bug doesn’t render any functionality unattainable.
The “fix” for this bug should 100% be to just change the name of the trigger to minecraft:player_damaged
or something like that.
Confirmed in 25w05a - affects Snowy Plains, Frozen River, Frozen Ocean, Deep Frozen Ocean, Snowy Beach, Jagged Peaks, Frozen Peaks, Grove, Snowy Slopes, Ice Spikes, Meadow (which may be WAI?), and potentially others (those are the ones I checked).
Also affects Cows; I'm pretty sure it's the same biome tag.
Can confirm.
Also, thanks for identifying and opening this! I apologize for initially reporting it as a Paper issue.
Can confirm, just came on here to report this
Can confirm, this issue is causing LOTS of crashes specifically when generating lakes (big worldgen datapack). This wasn't the case in 1.20.6.
I'd like to request that this issue be reopened, as it has not been fixed as of 1.21-rc1. When running a function on an arrow using the projectile_spawned trigger, the arrow still contains no information about its owner, whether it's a crit arrow, and other things that CAN be tested for 1 tick later.
Can confirm in 1.21-pre4.
Also, to add to uyp's statement, I was able to replicate this issue of end portals specifying the wrong destination, but ONLY if the player hasn't already seen the credits. Jumping into the end portal and watching the credits will always set the trigger's destination to the overworld regardless of where your spawnpoint is, but if you HAVE seen the credits already (meaning you arrive at your destination immediately), the correct spawn dimension will be passed into the trigger.
Can confirm in both 1.21-pre1 and also 1.20.6 (in 1.20.6, you can still give yourself an item with removed components by summoning an item entity).
Related note: it also doesn't work if you define attribute_modifiers as an empty array. For example
/give @s iron_chestplate[attribute_modifiers=[]]
This command still returns a chestplate with armor modifiers. In previous versions (1.20.4 and below), running an equivalent command would successfully remove all modifiers. Now, to get armor without any modifiers, you have to specifically define a modifier that does nothing (like adding 0 to your armor).
Well now I feel dumb, because I definitely used to know that. Thank you
Can confirm in the full release of 1.20.5.
Can confirm in 24w09a
Ah, my mistake! Never knew you were allowed to put quotes in a data path. Thanks for that.
I was just about to report this, and I also have something to add to it: it seems that emptying a bucket onto the ground (so, using the bucket item on a block) also fails to trigger the advancement.
Still an issue in 1.21.8