Back to minecraft.net

We've split up the commands, scripting and mods, and add ons category! Please be sure you get your thread in the right place.

← Commands
268
Follow

/motion command

With /motion you can make player move to a specific place or use the ~ to make the player move in a more smooth way than simply using the tp command over and over and getting something rough and ugly

Avatar
Registered User shared this idea

20 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 2
    Registered User commented
    Comment actions Permalink

    you can kind of already do that with a lot of command blocks,

    /tp [player] 1 ~ ~

    /tp [player] 1.2 ~ ~

    /tp [player] 1.4 ~ ~

    i think you get the idea

  • 11
    Registered User commented
    Comment actions Permalink

    You can inject motion with /data but this does not work with players

  • 1
    Registered User commented
    Comment actions Permalink

    I think this should work for entities so they will use their walking animation to move to the coördinates you want it to move towards.

    As for players... you can already do this by using /tp @p ^ ^ ^0.1 in long succesion (with more control over how it moves).
    But a /camera command could also be nice for this.

  • 1
    Registered User commented
    Comment actions Permalink

    The command usage could be
    “ /motion [player] x1 y1 z1 x2 y2 z2 [speed] “

  • 15
    Registered User commented
    Comment actions Permalink

    not a /motion command!

    just let "/data merge" merge nbt to players too!

  • 16
    Registered User commented
    Comment actions Permalink

    It'd be nice if they add this command and allow us to execute relative motion with it like: /motion ^ ^ ^1 to make a player or an entity move "forward".. Or at least allow us to use ^ ^ ^ with the motion tag to make relative motion for entities to make raycasting much easier and much more accurate.. So something like /data merge @e[tag=ray] {motion:[^1 ^ ^]} instead of setting a specific motion that'll always add motion into a constant direction not relative to the entity's rotation

  • 20
    Registered User commented
    Comment actions Permalink

    A /motion command could make imparting or preventing motion simple and universal, and combined with the execute command could be very flexible:

    motion (set | modify) {X} {Y} {Z} {target} {time}

    • "set" means the command applies the specified amount of motion to the target directly, overwriting any existing motion in that direction.

    • "modify" means the command adds or subtracts the specified amount of motion to the target's existing motion.

    • If X, Y, and Z are simple numbers, the motion is applied along the world coordinate axes, without regard to the executor's current direction or rotation.

    • If X, Y, and Z use tilde notation, the motion is applied along axes pointing leftward, upwards, and forwards with respect to the executor's current direction of motion.

    • If X, Y, and Z use caret notation, the motion is applied along axes pointing leftward, upwards, and forwards with respect to the executor's head's rotation.

    • If "target" is omitted, the motion is applied to the executor
    • "time" specifies the amount of time the applied motion will stay static after being modified before normal gravity/friction effects begin to slow it down. If not specified, gravity/friction start applying immediately.

    Combined with the "/execute" command to set the executor, position, and rotation of the command, this would allow for very flexible control of player or other entity motion.

  • 11
    Registered User commented
    Comment actions Permalink

    oh YES! This is brilliant. I need something just like this for my datapack, because then my smash attacks could fling players and not just mobs.

  • 1
    Registered User commented
    Comment actions Permalink

    Maybe it should be named something else? In the nbt editor  you can see a motion section that is actually, your player motion data at the moment, if a command was named  motion it should probably be about editing that in game, maybe instead lable it smooth TP or STP? Or something like /setpath as it seem people would use it to create a certain course of movement they could not otherwise get to naturely occurr.

  • 7
    Registered User commented
    Comment actions Permalink

    I like this idea, though I think it should be an additional parameter to the /tp command
    /tp <x> <y> <z> [yaw] [pitch] [time]

    /tp <target> <x> <y> <z> [yaw] [pitch] [time]

    /tp <target> <target> [time]

    time sets the amount of time it takes to reach the new position.

    with the rotation taken into account if you set the yaw to something like 720 they would spin around until the turned a total of 720 degrees minus the direction they were already facing.

    /motion should be used in away that applies force to the player in a direction

    /motion <x> <y> <z> 

    /motion target <x> <y> <z>

    that or the ability to modify the player's Motion datatag

  • 1
    Registered User commented
    Comment actions Permalink

    This would be so cool, even if it was just another option to the current TP command like /tp @p 100 72 100 walk or even some thing else to set the speed, or how long it will take for an entity to move from one place to another.

  • 1
    Registered User commented
    Comment actions Permalink

    An extension of the execute command? /execute as <player|entity> [walk <seconds> <direction>]|[jump]|[drop <item>] etc etc.

     

    oh boi it's time to make an AI.

  • 4
    Registered User commented
    Comment actions Permalink

    Imagine using dqta merge to do all tp stuff. Can't be me.

  • 9
    Registered User commented
    Comment actions Permalink

    I worked out a version of the motion command:

    • motion <target> get <axis> [<scale>]
    • motion <target> set <motion>
    • motion <target> set towards <location>
    • motion <target> set towards entity <destination>
    • motion <target> add <axis> <amount>

    (It uses "towards entity" to prevent the teleport ambiguity!)
    Worked out as actual commands:

    • motion @s get x 1000.0
    • motion @s set * 0.5 * ("*" could be used as the current motion value)
    • motion @s set towards ~ ~1 ~
    • motion @s set towards entity 1-2-3-4-5
    • motion @s add y 0.5

    Maybe we could use it in "execute store" as well: (so we can set from a score, for example)

    • execute store <result|success> motion <targets> <axis> <scale>
  • 3
    Registered User commented
    Comment actions Permalink

    So if your thinking of moving players that’s a brilliant idea! But you know what else is good? Moving blocks! You could create an obstacle game or build fancy machines of your own with moving parts! Not only the player can move but the blocks can move too! /moveblock and /moveplayer. {/move (player/block) (x) (y) (z)}

  • 2
    Registered User commented
    Comment actions Permalink

    Imagine having to use /data modify, /scoreboard players add, /scoreboard players operation and /execute store to move entities around. Awefully complicated, right? Well, that's what we're doing with motion these days. 

    I'm honestly confused and surprised that this 3-year-old topic is not even under review. The {Pos:[x,y,z]} nbt has had a command equivilant for years, but why not the {Motion:[x,y,z]} nbt? It feels so logical. A proper /motion command combined with the (^ ^ ^) rotation based coordinates, custom projectiles and raycasting would be so easy to do.

    if you ever tried making datapacks and maps before, you'd know how important raycasting is. To simulate a moving behavior, all we have right now is to teleport the entity foreward hundreds of thoussands of times, which is so tedious and inefficient. The same happens when placing custom blocks as you have to raycast to find the block you placed. 

    So Mojang, please add the command. You don't have to add a tag to this post. Just add it so that everyone is happy. 

  • 0
    Registered User commented
    Comment actions Permalink

    /motion <target> (set|add|remove) <x> <y> <z>

    The tilde or caret notation in <x> <y> <z> should be applied the execution position, because we can be used like other commands.

    I would also like to see a /execute subcommand that converts an entity's motion to an execution position. (e.g. /execute motion <targets> -> execute)

  • 1
    Registered User commented
    Comment actions Permalink

    using /tp over and over again is not very smooth, and it ignores gravity.

  • 0
    Registered User commented
    Comment actions Permalink

    Command syntax suggestion:

    /motion <selector> [local] <velocity> [second|tick]
    /motion <selector> to <position> (tick|interpolated <time>)
    /motion <selector> towards <position> <speed> [second|tick]
    /motion <selector> control <z control> [<jump>] [<x control>]
    • <selector> - entity to move

    Option 1 (set velocity):

    • <velocity> - velocity to apply, 3D vector, optional argument "local" means that entity local coordinates are applied
    • "tick" and "second" specifies units (units/tick or units/second)
    • "second" is by default

    Option 2 (set target position):

    • <position> - position to apply, 3D point, may use tilde and caret notation
    • "tick" - position is applied within the next tick
    • "interpolated" - entity moves to the target position in specified amount of time, requires the entity not to be affected by physics (succeeds for mobs with {NoAI:1b}, some entities with {NoGravity:1b}, any block/item/text displays, etc.., by the way add another NBT tag for disabling physics)
    • "tick" or "interpolated" is required

    Option 3 (set velocity targeted to given position):

    • <position> - position the entity is attempting to achieve, 3D point that the velocity vector towards to
    • <speed> - the speed the entity moves, the length of the velocity vector
    • "tick" and "second" like in Option 1

    Option 4 (simulate player controls or control entities):

    • <z control> (still|forward|sprint|backward) - control WS (in WASD)
    • <jump> - true/false, false by default
    • <x control> (still|left|right) - stand by default - control AD (in WASD)
  • 0
    Registered User commented
    Comment actions Permalink

    Currently an entity can have teleport_duration which when set to a higher value makes the teleportation smoother. Sounds similar to what you're asking for