Disparity between entity position and visual mesh

I've been trying to debug a stubborn egg movement code.
In particular it has been "bouncing" vertically seemingly at random, see here: https://i.gyazo.com/b74daf93dac42d5457765f7a2aa3e92b.mp4

As I had issues with a non-uniform OBB I'm moving the entity up by it's vertical ellipsoidal difference (depending on tilt), perform the movement stuff with a round OBB (inner circle, so to speak), then move it back down.
I've been using c_move for height changes to update the collision hull (for the subsequent player movement).

After a while I figured it's not >directly< an issue with my code/ a standard bug that I'd be moving it incorrectly by accident but it's some other issue with the egg's visual mesh instead. The numbers on screen are drawn relative to the entity height, as well as logging the height always shows the same height when it's jerking around: https://i.gyazo.com/3d8b595df946feb1febc31700013a060.png

Is this an engine bug somehow or is there another reason? Is there anything I can do about it? (Hm, just got an idea, use a 2nd entity as a workaround and put it at the original now invisible egg's position?)

Thanks.

Hey superku, are you changing the entity position more than once per frame?

Can you upload just the movement snippet itself?

Does it happen if you set the entity to passable?

Yes, calling c_move 3 times per frame for the same entity.
Usually I code all movement codes so entities float above the ground via c_trace. For this egg I chose to have constant c_move collision because of the non-spherical shape, which probably wasn't the best idea - it works though, except that glitch. (Implying that I cannot set it to passable without redoing the code.)

The visual glitch seems to appear when the result of c_move is <= 0.

EDIT: Btw. putting a passable copy at the same position and angles does the trick as a workaround.

Moving it several times per frame could be a problem since the engine does some collision management tasks at every frame, but not inbetween. The passable workaround should fix it, since then the move is a mere displacement.

I've had a better time using a stand-in entity that handles movement and pathfinding with an agreeable shape for collision, and then a visual entity that handles animation and collision with bullets/weapons. Although there is legwork to do to synchronize the 2 entities on top of simply placing the visual entity in the same spot. You can also smooth out erratic movements when entities collide into each other, by causing the visual entity to smoothly move to it's collision entity. But this is on a per game thing.

@JCL Out of curiosity, what kind of collision tasks are done at the end of every frame? Identifying and resolving boxes that collide then attempt to moving them the next frame?