# How do I predict where a player will be next in Forge/MCP?

I am trying to predict where a player will be next based on where they are now in Java. I have their XYZ position, their XYZ motion, but I don't have their speed. How can I predict where they will be in a couple of seconds based on their current position and motion?

I am doing this in Minecraft Forge/MCP but since this is probably more of a math/Java thing, I don't need an answer specific to Forge/MCP.

Thanks!

EDIT: The motion values for the player are the following:

While walking on positive Z axis (for some wierd reason)

Motion X: 2.0520011355833548E-4
Motion Y: -0.0784000015258789 // Gravity
Motion Z: 0.11785815704137818 // Basically 0


While running on positive Z axis

Motion X: 6.335480841945934E-4
Motion Y: -0.0784000015258789 // Gravity
Motion Z: 0.15320559375099232 // Basically 0

• What format do you have their "XYZ motion" in? Can you give us some examples. It's possible the speed is implicit in that input. Oct 11, 2021 at 17:56
• I made an edit to my post. The values I got in the log are very weird. I'm sure that they are the correct ones though. Oct 11, 2021 at 18:41

I threw some math at this, which could maybe give you something towards an approximation, but TBH the result is somewhat disappointing, perhaps because I'm not really sure what space the initial values are supposed to be in:

We can simply take the movement component values (ignoring gravity) from the values you've gotten and calculate the speed of the player in whatever units they happen to be in:

$$v_{walking} = \sqrt{v_{wx}^2+v_{wz}^2} \approx 0.1179 \\ v_{running} = \sqrt{v_{rx}^2+v_{rz}^2} \approx 0.1532$$

Now, from the Minecraft Wiki the speed for sprinting should be $$\5.612m/s\$$, and walking $$\4.317m/s\$$.

From this we can try to figure out what the units have been multiplied with to arrive at the values present in the code: $$v_{walking} \approx 4.317 \cdot a \\ v_{running} \approx 5.612 \cdot a \\ \implies a \approx 0.027$$

(Note that I'm doing some quite harsh approximations and you might want to double check these incase some rounding errors accumulate...)

You'd usually expect $$\a\$$ to possibly represent the delta time, but this doesn't seem to match up with any usual delta-times (this would represent an update rate of 37Hz, which doesn't seem to match up with anything I know of Minecraft's update systems...).

Anyways, with this mysterious constant known you should be able to estimate a future position simply by doing

$$\vec{p}_{future} \approx \vec{p}_{now}+\frac{\vec{motion} \cdot secondsToFuture}{a} \\$$

• Can you please explain this to me in more detail? I do not understand why this works. Oct 11, 2021 at 23:30
• What part exactly?
– user35344
Oct 12, 2021 at 6:50
• If I wrote something like Vec3 predictedPos = player.getPositionVector() + (player.getMotionVector() * 5) / a;, then would predictedPos be where the player should be in 5 seconds? I also still didn't really understand what the variable a is supposed to mean. There is a field in the Timer class (accessed through Minecraft.getMinecraft()) called elapsedPartialTicks. This number is from 0 to 1 and I assume it means the same thing as deltaTime. Could it potentially be the value for a? Oct 12, 2021 at 14:30
• Yep, predictedPos would be a prediction for where the player would be in 5 seconds. I also don't exactly know what the constant a describes, but it seems to provide a mapping from the data you've shared (which is in unknown space) into data we know the units of, and hence can possibly be used to convert into known space. Does the value of elapsedPartialTicks give you correct values? Is it the same as a? If so, I suppose it could be the real value, but I have no idea since I am not familliar with Minecraft's codebase or update loops.
– user35344
Oct 12, 2021 at 14:39