Quote:

I'm not talking about dead reckoning here,I'm saying that it needs only a simple move forward until the update comes. After the regular update (if the pos is offsetted) the ent will float(same speed as movement speed) to the new possition smoothly(with dead reckoning it could even be curved,for further smoothing). For a FPS it'll look not only slow but also wrong (I mean moving in another direction while facing the opposite for example) but for RPG its fine,imho



But that is the essense of DR. Ultimitely, you will be using a c_move on the client to move players on it. If you do teleportation (setting my.x directly), then you are at teh mercy of the server update speed and generally will just look bad. With c_move, you move based on previous physics data (position, velocity, and if you want, acceleration) and then adjust based on server updates. This means that as long as the player is moving predictably (no collision), you will be close to 100% accurate all teh time. If you have collisions (which are unpredictable), then the DR corrects.

Doesn't matter if FPS or RPG... this problem is stil a problem. Consider that a collision can be a Mob attacking you. Your players will SCREAM "foul" if they moved out of range on their computer consistently but the server sends updates that they are in range and taking damage.

Quote:

About the servers...you wont gain much,but even 50ms is enough if you reduce it below 100ms,dont you agree? Btw , lets first create the MMOs then we'll think about the money for the servers



I agree completely on both points, which is why I point out that this is a solution that requires money and the need and is not a "real" solution in terms of developing your game.

Quote:

player C receives the same inputs,possibly at diffrent times,and collides with just a little offset ent A and ent B because he got the inputs at diffrent times,and than they collide for 200ms , wich is just a little movement , until the regular update comes.



So the clients will be out of sync for 200ms and even then the server update may tell them that they were wrong all along! And you are forgetting a critica part of my example, that two people are trying to enter the same space on a client. Consider how complicated you have already made your system as opposed to the standard model: Player A and Player B send an update to the server, the server makes a decision on what happens and then updates all players on the "truth". Can you see how doing this makes developing and maintaining the simulation so much easier?

There is a saying that goes "too many cooks in the kitchen ruin the soup". This is what is going on here. By making each client a "cook" and able to affect their own simulation (the "soup"), you allow for way too many inputs, way too many voices saying "I was here first", "No I was here"... and ultimitely, it's STILL the server that has the ultimite say!

So what I'm saying is don't try to reduce latency... it's a losing game. Instead, work on mechanisims within your serve and client to hide the lag and process data effectively.

Quote:

but if you move them localy only until a regular update comes , the server will correct the possition (that the ent collided with another ent) and move that same ent on the clients a little back,where it actualy collided. It wont look good,but why do you suppose WoW doesnt have player-player collision



It's become clear that what you are proposing isn't very different from what is actually done. The only difference is that I somewhere got the idea that the clien woudl be transmitting back to teh server, would be actively modifing the simulation, and that is a no-no. As long as the server is the only one that can modify the simulation, then what you do on the client to hide the lag doesn't matter.

Quote:

It's interesting to discuss this , but we should try (each one of us) to make some solutions to this problem,so we could all benefit from it



What I talk is what I've done. All the techniques I've described are what we have going on with our MMOG. We haven't been able to do public demo due to our inability to create a stable published version, but we are actively working towards that. At that point, you will see how our solutions make our players move just as good (IMO) as any MMOG out there.


FUTUR-E-SCAPE: The Future Landscape of Education and Entertainment.