Quote:

---

Just to be clear, the "lagging behind" method means that that you send to your clients an update that is X number of timesteps behind so that the clients are always "lagging behind" the simulation, right?

---

The 'lagging behind' method I'm talking about is , when a client hits the forward key , the server receives the input , but for example the client sent the input right after a regular update has been sent. So , the client has to wait for example 250ms , until the next regular update wich will give the current x/y/z of the ent. This is great for my 'lag behind' method it looks smooth , but if the client hits the key right before a regular update , the ent starts moving to the received x/y/z , than stops and waits 250ms for another update to see the next possition so , sometimes it looks 'walk,stop,walk,stop' kind of way strange...
So , we discussed only RPG so far , and an RPG using WSAD for movement...Damocles wrote about RTS. RTS and RPG using mouse for movement , and any other game wich uses mouse movement + pathfinding is very easy to predict. You have to send only the 'goal' coordinates and to generate the path to see how long it takes to get there , and the clients (the same pathfinding) will generate the same path,and move the ents for that given time , for example , you send a var from the server on every 'join' event that states how many frames have passed since the server was started (you can even zero that from time to time) and according to prediction on wich frame the ent will arrive at the goal point. So , the clients see for how long the ent should be moving there , and I bet , no mather what latency you have (I mean < 250ms) the clients will have the same ent possitions all the time.
But this doesnt bring 'action' to a game. If you want action than , you cannot have a good DR , unless you have 300 people working on it or you're a genius
I'm going to use a diffrent method , I'll send 'goal' possitions from the server instead of actual possitions , and always in a straight line forward. If a client changes the pan of the ent , the server will force no more than 3 updates between regular updating for synching of server & clients. Dunno if I can do that but I'll try tommorow.
Btw , I tested without 'glide' , and the results from a c_move or ent_move again are diffrent depending on speed. With no gliding the entities get stuck on walls or corners. But when I moved them to the right of the walls (no object in the way) the 'instant move' ent got stuck for no reason just next to that wall while the other entity (same distance from wall and path and wall pos.) wich was moving smoothly went further without touching the wall. I guess if you move an ent very fast/slow the bounding box orientation or size differs. But with some tweaks I'll use this way to make my 'stupid' DR

PS.: I started from scratch again today (for 14-th time for 30 days,each time I get further and my script becomes more complex and better written from mechanics point of view) and I decided to try another method for ent management. I'll have only 'real' entities for the clients , everything else is handled local (server local & client local) and server will synch clients & clients will synch server (with input). It'll be easyer to handle , because currently I used a function to check every entity if its a 'player' entity and assign a local function (ent_next(you);func(you);) and it got kind of messy It'll be a lot more organised this way , but I'm not shure how synchronised the server and clients will be. We'll see What do you think about the new method?