I am still stuck on this and feel like I am making no progress by myself. I've been stuck at fiddling around with stuff but still cannot get rid of the jitter.

My previous topic is here.

I know that I need to find the difference in time between packets, from hplus's code here.

I am just so confused about the "previousState" and "nextState" states and their ".time" property.

For example I am using Godot and have this code to interpolate a player to a new position. Positional data is being sent 15 times a second, and received 15 times a second, on my local server.

var _velocity = Vector2(0,0)
var SPEED = 1000
func _process(delta):
	if new_pos.x:
		var my_pos = get_pos()
		var vector = new_pos - my_pos
		var length = floor(vector.length())
		var direction = vector.normalized()
		if length < 2: 
			if length < 0.5:
				_velocity = Vector2(0,0) # full stop.
			else:
				_velocity = vector * SPEED * delta
		else:
			_velocity = vector * SPEED * delta
			
			
func _integrate_forces(state):
	if new_pos.x:
		state.set_linear_velocity(_velocity)

So, the new_pos is the property that is being updated 15 times a second from the server.

The delta here is 0.0167. Game is running at 60 fps (1/60).

_process is being updated at that rate, 60 times a second.

My problem is, since I am only sending 15 positional packets per second to the server, that means I need to do some type of interpolation.

I could... instead of having that code in the _process method that runs at (60 times/s), have that code only run when the packets are received. Which would be essentially 15 times per second. But, if any lag would happen, would make the character jump all over the place because we're updating the linear_velocity.

Now, on to hplus` answer, I need to find the time difference between packets.

So I have a variable called "last_message_sent" and "last_message_received". If I am understanding this correctly, I now can get the difference (t) between packets and use that in my delta, right? To make it dynamic so that the jitter doesn't happen, but am unsure how to go about doing that. This is where my brain just gets stuck, thus this thread is created :X

e: I don't know where I went wrong..

The "time" of the positions is the game time. If you run 60 Hz simulation and send 15 Hz updates, each successive time should regularly be 0.0667 seconds apart, as they represent times that are 4 simulation steps apart.

There are four clocks here:

1) Game time -- this is important to the simulation, and advances at 60 Hz on the server, and it's up to the clients to keep up with this.
2) Server time -- this is the actual clock on the server. The server continually checks game time against wall clock time, subtracting some "game start time basis," and when wall clock time is ahead of game time, it steps the simulation and advances game time.
3) Client time -- this is the actual clock on the client. This advances at approximately the same rate as the server clock, but there may be some drift over time. Also, there is some unknown offset between server clock and client clock.
4) Client game time -- this is the simulation time, as currently executed on the client. The client establishes this by calculating some delta between client clock time and the game time it thinks it needs to be at, based on updates received from the server.

The interpolation display functions derive their "time to display at" from the client game time.
The server packet updates timestamp the updates with "server game time."
The client adjusts its clock offset when it receives a server-based update that shows a game time that is either behind where the client currently thinks game time is, or an update that is "too far" into the future of where it thinks game time is.