Um...... Yes, I understand your idea. From the MPSmoothing script referenced above:
Code:
/*******************************************************************************************************
Design Concept:
This concept is rather simple. I'm going to change the rotation and movement to be handled on the
client side. The servers job will then be to simply 'echo' each clients movements to all the other clients.
Traditionally 3dgs expects this to be handled on the server. To prevent the server from
sending it's automatic updates, I am setting nosend_angles and nosend_origin flags on all entities.
As we gather_input from the client keyboards, each client will apply the keyforces to it's own entity. Then
each client will send the movement coordinates of the entity via skills to the server.
The server will take these coordinates coming in from the clients and 'move' the corresponding entity. Then
the server will 'echo' these movements to all the other clients via other skills.
And finally a "client_move" function will use these 'echo' skills to move the 'echo entities' of other clients.
To smooth the movement effect client_move will use vec_lerp to interpolate the current position and rotation
of the clients' entities with these 'echoed' position updates coming from the server. Simple huh!
Note: This is not a prediction algorithm. Under very high latency this code will break down.
**********************************************************************************************************/
So, you can use that script as a reference if you like.
Also note that in the thread of discussions about this script, we kinda concluded that this method wouldn't scale well in a real game. I wrote it just so I could 'see' the client movement smoothed out without the overshoot problems you get with dplay_smooth enabled.