mojira.dev
MC-275450

Player Motion data no longer updates while riding another entity

For the past few years, when the player rode an entity, their Motion NBT data would change depending on their WASD inputs. So if they pressed W (or whatever their forward key is), their Motion vector would point in the direction they're facing. If they pressed S, their Motion vector would point behind them. By comparing their motion vector with their rotation, we were able to detect WASD inputs using commands. 

This has stopped working in snapshot 24w33a. In this snapshot, player motion NBT never updates based on their WASD inputs. This breaks a few years worth of existing projects.

Steps to reproduce (both versions):

  1. Create a repeating command block with the command /tellraw @a {"nbt":"Motion","entity":"@p"}

  2. /summon minecraft:item_display ~ ~ ~ {Tags:[test]}

  3. /ride @s mount @n[tag=test]

In 1.21.1, as you press different combinations of WASD, the command block will output different values in the Motion vector. In 24w33a, the printed Motion vector will never update. For me, I'm getting a consistent [0.0d,-0.0784000015258789d,0.0d]. This was not in any changelogs, and it seems like everyone who tries to reproduce it succeeds.

Linked issues

Attachments

Comments

kelianor

Can confirm

BugTracker

Also can confirm:

[media]
MulverineX

while of course we'd appreciate a fix to this bug, a better resolution would be a proper way to receive player input values & events, and if that means waiting another snapshot cycle or 2 the commands community would rather have a more polished/intentional method, as NBT access is bad.

Howzieky

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.

TheBoy358

Seems not fixed in 24w36a, can someone confirm please ?

migrated

They added a predicate to detect inputs instead

TheBoy358

Thank for the clarification.

Howzieky

Shugoh

Community Consensus

Platform

Important

Commands, Entities

24w33a

24w36a

Retrieved