Howzieky

Can confirm in 1.21.4

Can confirm in 1.21.4

It's probably good to clarify that the effect that disappeared in 24w33a was invisible without looking at NBT. It didn't move the camera and it didn't influence the mount entity unless it was a horse or something. The only effect that I know of was the effect on the player's Motion NBT.

Though, there is probably a side effect where projectiles shot by the player would have their motion shifted according to the player's WASD inputs, but I never verified that that was happening in the first place. And I'm not sure that it matters, because I don't believe anybody was relying on that functionality anyway. At least, I've never heard of anyone depending on or using it. And in case it's not clear what effect I'm referring to, I'm guessing that before 24w33a, if you were to /ride an armor stand and shoot 10 arrows, all at the exact same angle, and then shoot 10 more arrows while holding W (forward), the latter group of arrows would shoot slightly further than the first group, on average. If you held S and shot 10 arrows, that group would get the least distance. Like I said, I don't know if Minecraft was doing that prior to 24w33a, but I bet it was, and as far as the mapmaking community goes, I bet that it doesn't matter if that behavior is lost.

EDIT: More importantly, in case a full on "input detection system" isn't on the table for this update and this behavior must be manually re-added, I'd like to suggest a small design change. It might be better for the player's motion data to change depending solely on the WASD inputs, not both the WASD inputs and the player's rotation. When the motion data changes depending on both, we have to do our own logic to undo the influence that the player's rotation has. Instead of complicated (and slow) logic where we have to find the angle of the motion vector in degrees, then compare it to the player's rotation data, it'd be very nice if we could just say "if the player is holding W, their X velocity is 1.0d. If they're holding A, their Z velocity is 1.0d. If they're holding W and A, their motion vector is [0.707d,0d,0.707d]," regardless of what angle the player is rotated.

This would be great because, in the past, the motion vector didn't update immediately when rotating the camera, so if you held W and turned your camera, the datapack would often detect some other inputs instead. Choosing to not depend on the angle that the player is facing would solve this delay problem immediately, while also making WASD detection simpler in general. Now, there are some people doing logic as simple as "add the player's motion vector to their mount," which is useful because, if you want to create some kind of custom mount, then using that logic will let the rider influence their mount in the most simple way possible: "Hold forward to move forward." So making this change that I'm asking for would make that more difficult. However, as someone who actively uses both uses cases, I'd prefer to have the motion vector never change based on the player's rotation because it would fix the delay when turning the camera, and if you wanted to reimplement that "hold forward to move forward" behavior, you would just need to do a little math to rotate the player's Motion data based on the player's Rotation data. So either way, one use case will need to do extra math, but one use case is more popular, so it makes sense for it to be the one that gets simplified. Especially when fixing that one removes a delay that otherwise could not be removed.

Would love to see this fixed. I can't even say "<friend> eat food" or "/w <friend> do you already have one?" Incredibly frustrating for this to be happening on a server that I pay for.

If you set the nbt of an arrow to {damage:0.0d}, then the arrow will bounce off of the shooter and possibly any other players. It literally cannot hit a player entity. If the damage is not zero, it will behave normally.

Does bumping this thing work? I don't think this was ever viewed by anybody.

hey guys, vote for this issue and it will get more attention from mojang!

Yes it is, and to anybody else who sees this, PLEASE VOTE!

Anybody looking for help on this should watch this video: http://www.youtube.com/watch?v=So9xQ0Lu9Mg

Also make sure you dont bump the mob

Go Paul!

Can I update them? If so, how, where, and what?

Confirmed. I have tried everything. If we are doing something wrong TELL US WHAT IT IS PLEASE!

Intentional. Four torches hooked together would work.

oh. i wish i could contact dinnerbone

Can we change that?

Try making a TnT cannon. Notice how FAR the TnT flies. Now, fir again, but remove the 'cannon ball' and stand where it stood. Notice how HIGH instead of FAR you go.

The game needs to allow ANY enchantments on an enchanted book to work, not just regular level ones.

Oh yeah. I was trying to do it with level 100. The anvil would not let me, would that be a bug? I used MCEdit to enchant the book. Does that make a difference?

Wait. this still isnt fixed...