hi all, if I may add that if you watch the ARR, at the start, before the timer starts all three leo's where on the land in line formation facing south. As was said, this was check by a few people before we started. If you then move the time slider one notch after game start the platoon jumps to the wedge formation and faces east. This resulted in one of the Leo's dropping in to the water. I'm sure this is a known issue or bug, but I have recently come across a smiler type of bug in a game I am developing. The cause was the movement prediction algorithm missing the initial starting state message for a spatial and reverting to its last know position. Which in this case was the initial game state. If the problem is something smiler here, the server is sending the initial( or last know) platoon state to the client on game start. Thus causing the jump if the clients changes never made it to the server for some reason ( do movement state messages in the planning stage use UDP or TCP?). Perhaps the initial state of the platoon should be sent to the server and updated on all clients just prior to the game/clock starting. This would ensure all clients and the servers 'plan' are synced before any 'in game' state changes are exchanged. This would require the server to query each client for the state of owned units and building a new game state and issuing that new stat to all clients just prior to game start. In my code this adds a couple of seconds to the start up process for all clients, but prevents random movements on game start. no water to fall in to in space but a star can be just as deadly if an entire fleet decides to jump a light second down well! I'm sure the E-Sim coders have thought of this sorry, but I got geeked out there for a moment. As I dont know the code for SB and can only guess at the methods and order of process used at this stage of the game, what I said is just an educated guess. s!