I suspect pushing the movement queue to the max using a speedhack that allows a client to behave as if it's running directly off the server (0 ping) will likely permit/cause a very high number of network requests to the server to send/receive updates on the positions of everyone else. If a speedhacker sends 10 request packets while a normal client sends only 1, subsequent normal requests are gonna be delayed until the 10 "speedhacked" packets have been processed.
Possibly causing the reported "lag spikes" or freezes for normal players near the speedhacker. Might also explain why normal players might never see the speehacker cast - the packet that sends an update to show that the speedhacker casting probably "expired" and got dropped.
But there's still an issue, there's an inherent timed delay based on FC before a targetting cursor comes up. I am not sure if and how sending/receiving extra packets interacts with that timed delay. I do know that if lag is good, I can create macros in UOA to cast 2 spells with a 800 ticks delay in between, if lag is bad, I sometimes need to increase the delay to 1200 ticks.
