Well, yes now the listener is firing the events. Thanks. I a running into a problem now. A problem os my design. Is about precision. Actually, for each iteration the client sends the events to the server and the server moves everything, so I have a defined speed for turning and moving, but in a FPS the most important thing is the presision of the movements, for example:

Supose my cam is lokking at A and for each event I turn certaing degree to make the camera look at C.

Then I will never be able to aim B. point. making it turn a lower angle or move a smaller distance will make the game too slow. Any idea about this issue?

I was thinking about moving the cam a smaller angle/distance. But separating the moving thread from the networking and from the rendering threads. The problem is that letting a free independent movementon the client will lead to cheating. Thats why evertything is controled on the server.

for each iteration the client sends an array with the events id to the server (As actually does)

the server takes that information and moves the craft inside the server World (As actually does)

But instead of sending the fixed position, rotation matrix of all the crafts, and upgrading that into the client. I will let the cliente to do the movement for about 6 or 8 iterations, and each 8 or 6 iterations I will send the fixed position and rotation Ms of all the player (Aas actually does). If not cheating then it should be no difference for the player, the position and direction will be changed only if cheating. Anyway an aimbot can always be implemented.

Quake 3 Arena based games do like Egon said. Players send events to the server (usually running at 20 events / second, server side cvar sv_fps ) which does all the checking and logic of the game. Then the clients 'pool' the server for world events, and interpolate these. For making shure the game is fluid (like shooting and not waiting to the server's acknowledge), the client may run a kind of event prediction. That's why when someone connected to the server looses communication and walks (fires, etc.), it may happen that the player actually moves or fires for some little time (on the average of miliseconds), but locally!