This could be fixed by simply limiting how many attacks can be sent at the same time.

A more complex solution would need to make sure that the person being attacked has a chance to respond. Perhaps a delay between the attacks being sent.

What I did in my test fix, which I then removed until further testing could be done, is put in a wait at the point of attack where the attacking player pings the attacked player, then waits for the attacked player to be ready to process events and therefore ready to deal with the attack. This guarantees that a player is up to speed on the attacks. It paces the attacks so that one player can't rush ahead with multiple attacks before the attacked player's session has had a chance to update itself in response to the attack, synchronizing its data, location, etc. It will slow down combat, but I think it is a necessary thing. Maybe ultimately it will end up being optional for those who like to abuse this little-known tactic, but by default I'd want it to pace the combat like this.

I think that can already be configured. There's something in tedit about a weapon power-up delay. I'm not sure how finely you can tune it, but even something barely noticeable like 250ms would lock up the attacker as well as the target.

Edit: Well, maybe there isn't. I could have sworn there was an option for that.

I suppose a new delay could be added easy enough.

For some reason I thought it was separate from the movement delay, but it does say move/attack delay. Heh.

So a movement delay does double duty against kill scripts: slows down surrounds, and prevents fighter spam exploits.

I've often considered splitting these up into two settings. There's no reason they have to be linked like that. It's just always been that way.