Your code looks good Ulf. Another tip might be to create your multiplayer entities at a position like vec(2000,2000,-5000), and then afterwards when your ready, set them to their proper positions. I noticed that upon creating some entities, you'll bounce into them even if you set them as passable, due to the time needed for it's instances, ect.


Anyways, i've finished converting a unique weapon compared to what I was converting before. I've learned a few things, and have an update to the interpolation code with extrapolation.

Code:

---

function movement_smooth() //collision box
{
 my.invisible = on; my.passable = on;
 var rotate[3]; var s_angle[3]; var old_angle[3]; var rpos[3]; var zpos[3]; var pos_add;
 var calc_angle[3]; var move[3]; var move_old[3]; var zspeed; var length; 

 while(1)
 {
  if(my != decoy_1)&&(!lan)
  {
   my.passable = on;

   vec_set(s_angle.pan, my.server_angle); //iterpolate server angle
   rotate.pan = ang(s_angle.pan - my.pan); my.pan += rotate.pan * 0.8 * time;
   rotate.tilt = ang(s_angle.tilt - my.tilt); my.tilt += rotate.tilt * 0.8 * time;
   rotate.roll = ang(s_angle.roll - my.roll); my.roll += rotate.roll * 0.8 * time;
   vec_set(old_angle.pan, my.server_angle);

   vec_set(move.x, my.server_origin); //interpolate server position
   if(move_old.x != move.x){vec_set(length.x, move.x); vec_sub(length.x, rpos.x); vec_set(temp.x, move.x); vec_sub(temp.x, rpos.x); vec_to_angle(calc_angle.pan, temp.x);}
   rpos.x += length.x * 0.6 * time;
   rpos.y += length.y * 0.6 * time;
   rpos.z += length.z * 0.6 * time;

   vec_set(zpos.x, rpos.x);

   pos_add = my.fspeed * 4; //extrapolate to original position, fspeed is the speed of entity
   if(pos_add > 400){pos_add = 400;} //if(pos_add < 40){pos_add = 0;}
   temp.x = -pos_add; temp.y = 0; temp.z = 0;
   vec_rotate(temp.x, my.pan);  vec_add(zpos.x, temp.x); vec_set(my.x, zpos.x); vec_set(zpos.x, nullvector);

   if(key_v){vec_set(my.x, my.server_origin);}
   if(my.fspeed < 5){vec_set(my.x, my.server_origin);}

   vec_set(temp.x, nullvector);
   if(my.server_origin != move_old.x){my.fspeed = vec_dist(my.server_origin, move_old.x); my.fspeed /= 2.74; zspeed = move.z - move_old.z; zspeed /= 2.74;}
   if(my.tracekart){you = ptr_for_handle(my.tracekart); vec_set(you.x, my.x); if(you.spin == 0){vec_set(you.pan, my.pan);} you.z -= 27;}
   
   vec_set(move_old.x, my.server_origin);
  }
  wait(1);
 }
}  

---

This actually worked quite well, and now all the karts on each client and server see eachother at their proper positions with smoothness. But, there is one thing I should say. This will most likely only work in a situation where you have acceleration, such as a racing game. Because you extrapolate according to your acceleration. If you put this in a FPS game, the extrapolation would be sudden, and it would look jarred. It needs a certain degree of predictability too, since it extrapolates according to the players angle. If your angle updates are very far behind, or your angle quickly changes, this may not work as well.

But, this is a good solution for racing games, and should fix the problem of 2 players crossing the finish line at same time, and on one computer it shows you win, but on another you lose, and in the end, you win, because on the other computer your position is being interpolated. It also fixs the problems with aiming projectiles.

If your doing an FPS you wont have these problems anyways. Afterall, a character in an FPS moves much slower...

A few other things i've learned:

- If your rotating bones via user input, just send the position similar to sending the server angle.

- Local entities can be used in a dynamic multipalyer environment. I ran into a problem where I needed to create a couple entities everysecond(projectiles). At first I coded it using multiplayer entities(instances), but then I realized the amount of traffic this produced. So I ended up just sending a skill determining if the entities should be fired, and if they did, fire local entities on each computer. Do the events on only one computer, and have local entities for the rest. Of course the problem with this is that the two local entities can become out of sync(delete on one comp, stays on another). So only use this method if you really need it, and if your sure there movement is quite linear... so they'll generally delete at the same time on both comps, ect.