Of course polling the client would involve network traffic, there's no way around that(would have to be a proc that sleeps since a back and forth I guess). But I don't believe that polling the client once is comparable to having all 60 clients(in the case of ss13) be continually sending mouse location every single tick.

An example of this in ss13 would be our implementation of "space pods". You move the mouse to rotate the space pod as it always turns to face the user's mouse and you use the movement keys to move in a cardinal direction relative to the current rotation of the space pod. In most cases, we do not need to be listening to the MouseMove of most users as at most maybe 2 players will be using a space pod at any time. Yet we have to define MouseMove() in order to maintain functionality for the space pods.

As an alternative to having a proc to poll the client for the location, there could be a proc/var to enable/disable MouseMove per /client at runtime instead of a global everyone has it enabled or everyone has it disabled. Perhaps a SupressMouseMove var that defaults to 0 and clients would only send the MouseMove message if both MouseMove is defined and SupressMouseMove is set to FALSE in order to maintain backwards compatibility while allowing games to supress it for everyone but a select clients should they wish to implement it.

I think I came across the MouseMove proc showing up on the profile as having overtime, I cannot really remember if disabling it had much effect on lag overall but I'm not a fan of unneeded network traffic

514 may make some of this moot, since you could use .winset commands with a MouseMove macro and record coords in a hidden label.