loco: i just use c_move to get to the next position, this is the complete code of the fakeentity at the client. hostplayerposition is the vector iam sending.

Code:

---

function hostplayerfakefunction()
{
	
var unit_speed[3];
var dire[3];

	var currentposition[3];
	
	my.mode = mode_stand;
	while(1)
	{
		//stand
		if(my.mode == mode_stand) 
		{
			my.anim_index += time;
			ent_Animate(my,"stand",my.anim_index,anm_cycle);
			
			// new different hostposition incoming -> go move there
			if(abs(my.x - hostplayerposition.x) + abs(my.y - hostplayerposition.y) > 15)
			{
				my.mode = mode_walk;
			}
			
		}
		
		// walking to hostplayerposition
		if(my.mode == mode_walk) 
		{	

		
			while (my.mode == mode_walk ) // stop near the target
			{
 

				
			// always face next position
			vec_set(temp, hostplayerposition);
			vec_sub (temp, my.x);
	  		vec_to_angle (dire, temp); // rotate the unit towards the target 
	  		my.tilt = 0; // we only need the correct "pan" angle, not tilt
	   	unit_speed.x = 1.5; // unit speed
	   	
	   		// turn
				if(((my.pan < dire.pan + 5) || (my.pan > dire.pan - 5)) && (abs(my.x - hostplayerposition.x) + abs(my.y - hostplayerposition.y) > 10 ))
				{
					my.pan = my.pan + ang(dire.pan-my.pan) * 1 * time;//i am turning
				
				}
	   	
			c_move(my, unit_speed, nullvector, ignore_me + ignore_you + IGNORE_CONTENT + ignore_sprites + ignore_passable );
			
		
			// trace to geht right height to terrain
			vecFrom.x =my.x;
			vecFrom.y =my.y;
			vecFrom.z = 200;
			
			vec_set(vecTo,VecFrom);
			vecTo.z = -200;
			
			c_trace(vecFrom,vecTo, IGNORE_ME|IGNORE_PASSABLE|IGNORE_CONTENT|IGNORE_SPRITES|USE_POLYGON); 
			vec_set(temp_loc,vecTo);
			my.z = target.z + 32;
			
			// animate
			my.anim_index += 5 * time;
			ent_animate(my,"walk",my.anim_index,anm_cycle);

		
			// are we near the last received hostposition? and z is 1
			if (abs(my.x - hostplayerposition.x) + abs(my.y - hostplayerposition.y) < 5 && hostplayerposition.z == 1)
			{
				my.mode = mode_stand;
				hostplayerposition.z = 0;
			}
			
			wait(1);
			}

			
		}
		wait(1);
	}
	
}

---

william: very very much thanks for your contribution, ill have a look at your method later in the afternoon. i guess setting directly doesnt take that much ressources like c_move also... however i assume you are using c_move for the server player? do you?

Naw, at first I was thinking of sending the clients input key to the server and c_moving it on the server, but I ended up just doing c_move on the client then using similar code for both server and clients. You could do your moveing on the server, but if your in a fast paced game it would be wise to always have some sort of client prediciton in place as well. I believe in locos tutorial he does the movement on the server and uses native A6 update methods to relay the positions back. I think it's best to turn off all A6 automatic updates and do everything yourself using send_rate.

Hi,

Ok, what I was suggesting on the clients would be to use dplay_latency to arrive at a percent rate to move on the clients.

You are sending update every 1/4 seconds + the time it takes the message to be recieved by the client from the server.

So, right after every new position list is sent every 1/4 sec, take the current latency on client and try to figure out just how slower the client should move adjusted for the latency. The difference in movement speed should hardly be noticeable and should keep more fluient movement happenening on the client.

The equation for figuring out the percent rate to move at would look something like this:

latencyAdjust = .25/(.25 + (dplay_latency/1000)/2);
(I don't know how your movement works though, so this could be a totally wacky equation, and probably is)

.25 seconds (update rate) / (.25 seconds (update_rate) + (dplay_latency (milliseconds)/1000(now in seconds)/2 (latency is round trip, so divide by 2 to estimate send time));

Now let's say we has a latency of 100 milliseconds, we divide that 1000 to get latency in seconds and then divide that by 2 to get approximate send-to-client time. Which comes out to equal .05 seconds. Now that we have the approximate send delay time, we can try to move the client at a percent rate to compensate for the approximate delay time.

so basically we do .25/(.25+.05) = .83

So we move client at 83% of normal speed on client.

Anyway, just throwing that out there. May not really be a good idea even. Just something to think about.

One thing I did notice is that you are not multiplying your unit_speed.x*time in that client code.

You are using time with pan:

my.pan = my.pan + ang(dire.pan-my.pan) * 1 * time;//i am turning

But not with your x force (which you have as unit_speed.x). I think it would behoove you to add before c_move():

unit_speed.x = unit_speed.x * time;
(could make major difference if server and client are somehow not running same FPS)

If you were trying my crazy idea above it would be:

unit_speed.x = unit_speed.x * latencyAdjust * time;

Anyhow, thats all I know.

Later,
Loco

09.06.

big thanks for both of you!

i am now doing the following: i c_move on the host for the player, later ill use a simple pathfinding from the aum for the player. i think c_move is the way to go since this gives the opportunity of easy collision handling. i dont know if it runs smooth with 50 entities doing c_move at the same time. ill see ...

i then send his position 4 times a second to the client in a variable with send_var.
the client has a local entity created with ent_createlocal and moves this entity with interpolation like william posted his example.
it lags a bit behind but thats totally okay! to fix the problem where i receive a short position and then nothing so the player waits short i just do a little trick.
i continue to move the player to the direction the last position was, its likeley that the next update is somewhere near, so the movement is smooth. even if the next position is around the corner its not such a big problem since interpolation turns smoothly then. and with 4 updates a second its not a big deal, you wont notice the way you walked to far.

i even tested updating only 2 times a second, this still works quite good and i get as low as 28 average bps!

now the only thinks iam still not happy about is that when the host has a high movespeed it looks good on the hosts machine, very smooth.
but on the client its a bit choppy, its okay but you see the difference. maybe this is because i test at one computer? i have to test it with my second pc if this is also the case then...

so to sum up right now it works like this: move player on host computer with c_move, send_var to client 4 times a sec., move client with interpolation directly without c_move.

ill post the code in the near future when its cleaned up and commented.

@william, you say you use ent_rate, so you must send everything in skills? how is your system set up? do you create only one entity for a game entity?

i plan to use fixed pointers for each player, like entity* player1... and update those pointers at the server when a client joins or leaves the game. then i want to use variables and arrays to send stuff.

Quote:

---

@william, you say you use ent_rate, so you must send everything in skills? how is your system set up? do you create only one entity for a game entity?

---

While I can only speak from what i'm doing in my game(mabye it's not best for you). I first create 3 entities on the client(kart body, collision cube, wheels). I then set all the pointers and send to clients ect. Afterwards, I move the collision cube like normal. The kart body then follows that and does it's own suspension stuff normally. The wheels then followed the kart body. I had a problem with bad jittering on the client but with none on the server, oddly, I fixed this by setting the kart bodies position directly in the movement smooth for the collision cube. You'll notice this in this line >

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;}

If I instead set that in a function for the kart body like this:

Code:

---

function movement_smooth2() //body
{my.invisible = off; var stop_vanish; var old_spin;
 while(!my.tracekart){wait(1);}
 while(!my.kart_point){wait(1);}

 if(my.kart_point == 1){mkart1 = me;}
 if(my.kart_point == 2){mkart2 = me;}
 if(my.kart_point == 3){mkart3 = me;}
 if(my.kart_point == 4){mkart4 = me;} 
 if(my.kart_point == 5){mkart5 = me;}
 if(my.kart_point == 6){mkart6 = me;}
 if(my.kart_point == 7){mkart7 = me;}
 if(my.kart_point == 8){mkart8 = me;}

 while(1)
 {
  if(my != decoy_2)
  {
   my.passable = on;

   c_scan(my.x,my.pan,vector(360,0,160),IGNORE_ME); //trace for local weapons

   if(my.spin == 0){stop_vanish = 0;} //spinout?
   if(my.spin == 1) && (stop_vanish == 0){stop_vanish = 1; spinkart();}
      
   //you = ptr_for_handle(my.tracekart);
   //vec_set(my.pan, you.pan);
   //vec_set(my.x, you.x); my.z -= 27;
  }

  if(my.spin != old_spin){send_skill(my.spin, 0);} old_spin = my.spin;
  wait(1);
 }
}
 

---

Then there would be bad jittering. I've yet to look into this a little more, I know it sounds a bit weird. Also, by running multiple instances on one computer can add some jittering. You'll find if you split it across multiple computers things run a bit smoother.

As to the set up,


Code:

---

 if(connection) //Multiplayer
 {
  if(kart_create == 1){my.pan = kc1.pan;}

  if(my.client == 1)
  {  
   proc_client(my, move_player);
   proc_local(my,local_functions);  
   //cs_move();

   my.invisible = on;
   my.nosend_frame = on; my.nosend_alpha = on; my.nosend_ambient = on; my.nosend_color = on;  my.nosend_light = on; my.nosend_uv = on;
   my.nosend_origin = on; my.nosend_angles = on; my.nosend_flags = on; my.nosend_scale = on; my.nosend_skin = on; my.nosend_sound = on;
  } 
  if(my.client != 1)
  {
   proc_local(my,local_functions);  
   move_player();
   my.invisible = on;
   my.nosend_frame = on; my.nosend_alpha = on; my.nosend_ambient = on; my.nosend_color = on;  my.nosend_light = on; my.nosend_uv = on;
   my.nosend_origin = on; my.nosend_angles = on; my.nosend_flags = on; my.nosend_scale = on; my.nosend_skin = on; my.nosend_sound = on;
  }
 } 

---

Then in while loop on server:

Code:

---

   if(new_sends != people_connected){client_new += 1*time;}
  if(new_sends != people_connected)&&(client_new > 160){client_new = 0; new_sends += 1; send_skill(my.tracekart, send_all);} //this part resends pointers to a new client that just joined game

  send_skill(my.server_origin, send_vec + send_all + send_rate);
  send_skill(my.server_angle, send_vec + send_all + send_rate); 

---

I send skills for most things. Send positions from clien-server, then relay it back to clients from server. To keep things working for both single player and multiplayer, each kart has a pointer "kart1". That way all the single player functions still read it as a player and not A.I(A.I uses kart2-8). Now, I also number each clients kart indpendantly, this is for multiplayer distinction mkart1 - mkart 8. I do weapons/scans on only one computer at time(for example... if u fire projectile, it will detect people only on yours). If it hits on yours, it tells other computers and proceeds with other functions ect. This may not work with your game, it all depends what your trying to do. I also do checks and balances with movement and weapons ect. to keep cheaters away.


Heres a link that explains some multiplayer concepts that counterstrike uses, pretty good reading -

http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

P.S - If you find a good way to keep the entities very close to original positions in the interpolation code, be sure to give me a shout.

thanks william, ill test later how it works with more computers. i noticed you set the nosend flags one by one. are you using some things of the internal a6 sending? you could just send nosend with my.nosend = on; instead of all those single instructions.

in my lan simulation it works quite well with the positions, shure the clients lag a little bit behind but they arrive almost at the same time at the same point.

i did normalize the vector where the player moves to, so that there is constant movement. i dont want this starting slow, moving normal, ending slow kind of movement.

i assume you are already using some kind of input prediction for each client? so that they directly see the results of their inputs? its described in that source link. use almost the same code like on the server to display the actions a client presses directly. then you check from time to time if the client is on a different position like on the server simulation and if this is the case correct the position towards the server position slowly. so at least each client gets the feeling that his inputs are processed directly.

for the other cars you can either live with the little lagtime or use extrapolation/dead reckoning. thats what the standard conitec multiplayer system does i think. it calculates the position where an entity "should" be given the previous movement and predicts it. http://en.wikipedia.org/wiki/Dead_reckoning i remember there are some good gamasutra articles about that but havent found the link right now.

i havent looked in depth into it yet because i can live with that little delay in my game. i will however post the code once i got the movement working like i want.

i start the movement once the position of the server entity is a little bit away from the position on the client and end it when the client is near the server position.

I set the nosend flags one by one since I had a problem with my.nosend = on; messing up a proc_client command or proc_local, I forget which or what it was exactly, but I remember there being a problem that gave me quite a headache...

Unlike the article in the link, I just do all my movements on the clients, and just set the position on the server. No need for prediction then. The reason they do movement on both the player and the server is due to cheating I think. But, I do some checks and balances against this. The problem with doing 2 methods is that there will need to be some sort of correction in your code. For example, there is possibilities for the servers real positions(based on client input) and the clients predicted positions to be out of snyc. You then have to move the client in snyc back which causes jarring.

ahh okay now its clear for me what you mean. however i wouldnt do it that way even if you do checks at the server. i cant await seeing a demo of your game to test this. i learned in serveral threads that this causes the simulation to diverge and brings big problems.

you should be able to get closer to actual positons at your clients if you extrapolate the position of the other clients a little bit ahead of their current position. if you make this relative to the speed you shouldnt have too big problems. so your client player gets the current position from the server along with the current forces of that object and extrapolates a position ahaed of time that compensates the lag time.
you can even use the dplay_latency variable for that like lokoweed suggested so you should be able to predict almost perfectly where the players are at the server - even if you get the older positions and forces only.

Quote:

---

however i wouldnt do it that way even if you do checks at the server. i cant await seeing a demo of your game to test this. i learned in serveral threads that this causes the simulation to diverge and brings big problems.

---

Hmm.. what do you mean by it causing the simulation to diverge and bring up problems? I don't remember reading much about this. Remember, i'm moving on the client, sending the positions to server, then having the server relay the positions back to the clients. The checks on the server only see if the movement is in a realistic range(to make sure client isn't cheating).

Quote:

---

you should be able to get closer to actual positons at your clients if you extrapolate the position of the other clients a little bit ahead of their current position.

---

Yeah, I was thinking of doing something like this. It should work quite well, especially in a racing game since it wouldn't be all that sudden(acceleration over time).

look, you have 2 karts driving next to each other. because of network problems you are not getting updates from your opponents kart. in reality on the server he is ahead of you. but because you didnt get updates he is right next to you and blocks your way to drive right. because all your games driving logic is done locally you cant use a shortcut on the right because its blocked on your machine. whereas in reality on the server you would be able to because your opponent didnt block your way.

what happens if a hacked client just says i am moving there, nothing is there? with all game logic at the server he couldnt because you would do checking for that on the server only. what happens if both of your cars say, i want to move there? who gets the right to move there? the one wich is sending first? this probably gives advantage for people with good internet connection.

so its a bad way sending the results of game logic to the server. for client server architecture a general rule is keep all! the game logic including movement at the server.

just have a look at gamedev.net forums for example there are tons of threads like this. i may give only poor examples because iam not very good explaining things like this in english altough i try my best i hope you understand what i mean?