2 hours ago, Kylotan said:

Don't use ticks - measure time in seconds. You don't need sub-millisecond precision and the timer doesn't truly have that level of resolution anyway. Time in seconds stored as a float is adequate for gaming purposes

This depends on the game genre highly. If you've got a race car going 300kmh, that's about 8cm per millisecond, which could show up as very noticeable jitter if that's your timer precision. Another way to look at that, is that a 1ms imprecision at 60Hz is 6% of a frame, which is a decently high error rate. 

Hardware timers will likely be closer to nanosecond precision than microseconds. So, definitely capable of under 0.006% per frame error if you use ticks (or time in seconds as double-precision float or 64bit fixed point), whereas with 32bit floats it only takes an hour to reach ~0.25ms quantisation (1.5% error). If someone leaves their PC on overnight, floating point time in seconds will quantise to more like half a frame  

@Kylotan I almost didn't recognise you with your new profile pic

7 hours ago, Kylotan said:

If you need to use the C# DateTime value, try measuring the time at program start and after that using TimeSpan.TotalSeconds to get the time since the program started. (Similar to Unity's Time.realTimeSinceStartup).

Sure, normally I should use probably the server's time that is definitely checking the time in it's own system to have a globally synchronised time which is why I'm trying a simplified approach to see first if it works. 

7 hours ago, Kylotan said:

It's not clear why you think that the extrapolation is wrong - if velocity is zero then it would be expected that the extrapolated distance would also be 0,0,0. Added to the previous position, whatever it was, creates a correct new position for a stationary object. I don't know if I've missed a post but since we don't know what each of those variables mean to you, it's hard to say exactly what is wrong here.

the problem is this:

20 hours ago, Tipotas688 said:

bool read = m_Extrapolator3.ReadPosition( m_PressTime.Ticks + STEP_COUNT, out data ); 

I'm not adding the extrapolated data, unless it's doing it automatically but as I mentioned above I was getting some crazy big numbers as a result so I couldn't really make sense what was supposedly returned.

But because of

        oPos = m_SnapPos + oVel * (float)( forTime - m_SnapTime );

when it's called in AddSample m_SnapPos becomes a huge number like (-49336320.0, -49336320.0, 0.0) 

7 hours ago, Kylotan said:

I assume that snippet is referring to your C# port of the EPIC code, but it's possible that there could have been bugs introduced in the porting, so it would probably be useful to see that code as well.

Since that post I actually found this: https://github.com/Relfos/EPICSharp which others can use as well if they ever manage to go through all these messages

So in the end I decided I should use something simpler than EPIC, sorry @hplus0603 and went with the much simpler

m_PotentialData.Position = m_LatestData.Position + ( m_LatestData.Position - m_PreviousData.Position );

basically, x2 = x1 + v0 for now for simplicity.

My current problem is that debugging has just gotten a lot more difficult. I have had set a delay as @Kylotan explained in the beginning of this post, around 30ms and used that to lerp into the future, as extrapolation I set it as 60ms so 30ms extra.

I noticed that 

1) I wasn't taking into account rendering time which also was 30ms ( in a 30 fps scenario )

which had as a result jittering so I increased this into 90ms as a base and 180ms for extrapolation. 

That had the very negative effect that we get packets a lot more often before reaching the target and 

thus as you can see in my code in previous pages I don't try to reach the final point rather update to

the new point:

if( !m_HasFinished )
{
     m_PreviousData.Position = m_BallTransform.position;
     m_PreviousData.Rotation = m_BallTransform.rotation;
}

so my question is, do I speed up the lerp? do I send packets slower? do I queue up each packet so that I reach the end point each time?