I am refering to dead reckoning as a very complex mechanism to predict possitions thats why I said its not a dead reckoning (to move the ent simply forward and to possibly rotate it with a defined speed in a given direction) Dead reckoning is every (simple and complex) solution for prediction,but I'm saying it for the more complex solutions.
My system does have collision detection right now , and I havent tested how it works with 2 clients moving (localy I can only move one only if I had a second keyboard ) and I'm thinking of removing it(only player with player) and reworking the 'fight concept' to be the same as other MMOs. Currently my fighting concept will require instant updates (wich is not an option with more than 100ms latency) and constantly synching the clients. I think the current solution in many MMOs will be better , to have a 'cycle' where your character attacks at a certain rate eighter until you cancel it , or until the other(or you) player is dead.
By the way , the only thing that I did to 'predict' client movement was this 'forced' updating , but for some reason it updated more than once,so I'm still fixing it but from the feedback I got (when I tested with a server & two clients) I'm very satisfied by the numbers. I'm still new to MP,yet I'm managing to keep my data transfer to a minimum,I hope my project continues to develop this way

PS.: All the techniques we're talking about , you say you did it in your MMO...what exactly you did because (not only here,but in my post in MP section) we've talked about many thinkgs,and peer-to-peer , server/client & local movement together wouldnt look good and btw , how are you managing with the numbers ? bps , peak & rel/unrel ? I'd like to know for comparing how much 'spare' traffic I have for interraction (currently I have movement only & anim states)


Extensive Multiplayer tutorial:
http://mesetts.com/index.php?page=201