Well AFAIK c_updatehull is mostly used to (re)calculate the collision mesh of a different frame. When I'm back home, I will test the speed of this instruction when the frame hasn't changed. If it's slower than c_move, it's useless in my case.
However, normally you can avoid such a situation anyway by proper coding, f.i. tracing an object before and not after displacing it.
Not really, see the following situation:
A platform that moves vertically between two points up and down. It does not need collision detection when moving and should not be blocked by anything, so setting the z-position directly sounds logical. When the (PROC_LATE) player stands on the platform and performs his gravity code, he will get the position of the invisible collision mesh that is still at the position of the last frame.
Thus, because of the 1-frame-lag, he will either hover above the platform when it moves down or sink into it when the platform moves up.
To avoid this, I use c_move (instead of my.z = ...):
vec_diff(temp,new pos, old pos);
c_move(me,nullvector,temp,IGNORE_PASSABLE | IGNORE_MODELS | IGNORE_WORLD);
This updates the position of the collision mesh and the player and other objects on the platform don't lag one frame behind, but I think it's an unnecessary c_move call.
Btw. I've tried
c_move(me,nullvector,temp,IGNORE_SPRITES | IGNORE_MODELS | IGNORE_WORLD);
but it does not update the collision hull, I don't know if that is skipped on purpose or not.
