So I looked at the problem again bmm. After reading all the evidence, what I dont understand is splines have a control paramter which goes from 0->1 if you scale your time paramter between updates so that a new packet arrives at the end of the spline control point, there should be little skipping ( will be some due to error ). But from your 2nd data point about the spline only being 1/2 the way along the spline when the next packet arrives, tells me several things.

possibly :

1)Spline control paramter is off ( time scalling is not done correctly, control param should be
t = delta_time_from_last_packet/packet_update_rate )

2)Spline control points are off ( not calcuating end point correctly, possible ping error here, check independlty that your ping is being reported correctly by Enet )

3)Spline could be prematurally terminating to floating point error. ( odd error when i was writting the spline code due to limits of floating point representation. Using (t < 1.f) would result in incorrect termination, use (t-1.f) < -small_delta to bound spline ) This might occurs if you bound the control param to 0->1.

If those things still check out then from what you told me it doesnt make sense that the arriving packet doesn''t correspond more closely with the current position of the object.

Good Luck!

-ddn