OK, I have some more questions regarding moves and pathfinding. Say I have a standard isometric grid 10x10, and 4 players on it. Every X milliseconds all changes to the grid are sent to the players.
Say all 4 players request to move to cell 10:10, and do some pathfinding. I guess the best order to do it is in the order they submitted their move requests. But how does pathfinding take into consideration moving obstacles? How often to recalculate the path, every frame or just do it ONCE ?
For instance:
1. Player requests to move 10:10. Make pathfinding and store it, taking into consideration only obstacles that are NOT moving.
2. Every frame pop a move off the stack, and try to move there. If the cell is blocked with a non-moving obstacle (a player that is standing still) recompute path, if the cell contains a player that is moving then just wait this frame and try to access the cell next turn. If the player has waited to long for the cell to become free, recompute path.

What in this logic is faulting, attack it pls!

I figure the server is doing its pathfinding, and calculating those requests that come in. If the server is to overheated with work I''m in trouble, if the client is lagged in recieving the changes and sending changes its the clients problem?

I think bogdanontanu is making an implicit assumption that your using an instep server client synchronization, as most RTS games do. As using the standard client server dead reckoning sceheme for a world simulation with a 1000 moveable entites isn''t a good idea. With the in step sychronization, the slowest part of the system limits the update rate of the whole thing. So if the sever starts to chug due to the process load, it will likewise slow down all the other clients as it has become the slowest part. In step synchronization is similar to peer to peer but there is a centralized server, where as peer to peer there isnt a clear server. The benifit for in step synchornization is that you only need to exchange commands and command ackowledgements for each tick, vs state data for entites and such in a dead reckoning appraoch. Though it has to be said that an in step synchornization scheme doesnt have to stop becuase a laggy player has joined. The server can buffer all the commands that player has missed and send it to them at a later time to syncrhonize their game to the others. The server could choose to step a tick if most of the players have acknowledge that time steps ack request. That way the server would only stop if most of the players lagged that tick. Though low ping players would gain an advantage but that''s how it is for most multiplayer games.

Good Luck

-ddn

will i be notified if a packet gets lost? I don''t know!
in java you send(packet p) and receive(packet p)
but will java make sure that the datagrams get delivered? or is there no way to ensure delivery?

Also, what''s a usual packet length???

With UDP there isnt a built in packet acknowledgement scheme, you''ll have to build one on top of it. Using NTP or some other timmer scheme you can tag a packet loss if you dont recive a ack within a certain timeout and send it again. If the loss is very high or you never recive an acknowldegement packet you can eject the player as their connection is too poor anyways. The client to reduce overhead of sending out many small ack packets can buffer them up and send out them all in 1 UDP packet for every say 1k of data recived. Though the server should be aware of this buffering and extend the timeout approprately. There could be a problem with client to server loss, so it might be wise to send more than 1 ack packet, the server shouldnt be affected by reciving duplicate ack packets.

Good Luck

-ddn