Smooth mob interpolation with jump-style steps and predictable bandwidth knobs

[Nu11ified]

Video:

20.09.2025_01.17.49_REC.mp4

This is a completely unneeded cosmetic change and I understand if it's too heavy for the purposes of this project. Also I saw in another PR that you wanted issues created before PRs that is completely my bad I missed that in the readme.

Summary

1. Encode prior horizontal deltas inside MobData and cache tiny per-mob scratch buffers so we can interpolate movement without adding to the struct size.
2. Rework the tick loop to capture deltas, preserve panic headings, retry blocked moves, and queue interpolation phases only when something actually changes.
3. Add a lightweight interpolation scheduler (default 6 slices) that smooths horizontal motion, emits a discrete “hop” profile for vertical climbs/drops, and clears deltas/ yaw once the move settles to prevent snap-backs.
4. Expose helpers so player joins spawn in-flight mobs at the correct interpolated position/yaw, and keep head rotation deterministic.

Goal: mimic Minecraft’s block-step feel with minimal RAM/CPU so an ESP32-hosted server stays responsive.

Memory impact

1. MobData remains unchanged.
2. New state: mob_interp_dy[MAX_MOBS] and mob_interp_yaw[MAX_MOBS] (1 byte each). With the default MAX_MOBS = 16, total additional RAM = 32 bytes.

Bandwidth impact

1. Each predicted slice still uses the standard Teleport Entity + Set Head Rotation packets (~78 B combined).
2. With MOB_INTERP_STEPS = 6, one move now emits up to 6 slices (~468 B) instead of 1 (~78 B). Idle mobs remain silent.

Config / tuning

1. MOB_INTERP_STEPS (in src/procedures.c) controls interpolation granularity. Lower values reduce bandwidth at the cost of choppier motion; 4–6 works well.
2. The vertical profile currently hops on the final two slices. Tweak mobVerticalProfile if you want a taller or earlier jump.
3. MOB_COORD_OFFSET/MASK constrain mob positions to +/-8192 blocks per axis, still well beyond what the ESP32 can serve.

[p2r3]

I'm not really a fan of how this is implemented. I touched on a much simpler opt-in interpolation approach in #78, and I'll probably be doing that one myself at some point.

Primarily, I want any change that measurably impacts memory usage or bandwidth to be opt-in. This has way too many direct changes to mob behavior for that (including some that seem outside the scope of this feature).

[p2r3]

I also don't think you need 11 new global functions for interpolated movement.

[Nu11ified]

I also don't think you need 11 new global functions for interpolated movement.

But we do need 11 global functions...just kidding a lot can be cleaned up as my implementation is very rough. I looked at what you said in #78. Obviously the interpolation idea is pretty hard to get to a decent state without large memory requirements. My idea was to capture a mobs start/end position for every tick, stash that in a tiny opt-in buffer, and feed a midpoint "teleportation" before each tick. This is so we don't have to mess with the existing integer pathing. If I am wrong, if you have any thoughts that you want to add, or if you have any specification requirements for this feature I am open to discussion.

I understand you said you wanted to implement this in the future yourself, but if you don't mind I would like to try to get this working.