Yeah, only the server is interested in the actual inputs of the client, for physics updates, verification and correction.

The remote clients will receive the occasional event message.and state updates, these get extrapolated / interpolated. Running and walking anims are either implicit (computed from the path of interpolation) or explicit (anim velocity replicated).

You can send each and every bullet event to remote clients, but that's rather inefficient, and clients are mostly interested in what 'looks good', bar things like grenades, rockets which would have to be replicated pretty accurately.

You can for example keep a count of the bullets to detect how many were fired since last update, or when to reload, or just flag the gun as firing, and only worry about simulating gun fire and reload anims regardless of what ammo is in the gun. The 'infinite gun firing' when a client drops for example.

The server doesn't forward the input of clients to other clients. [/quote]

It depends. It's certainly possible to build an FPS which is input-driven rather than state-snapshot-driven. Doing so will likely allow your server to scale to more players per map instance. I would be highly surprised if there is no "modern" FPS game that uses input update packets, perhaps with occasional "baseline" snapshots. I also think that, the more players per map are supported by the game, the more likely it is to use input forwarding instead of state forwarding.