The ban system needs a full rewrite anyway, but this move removes
something from Utils, puts it closer to its operating point, simplifies
the method, and clarifies what it actually does.
This is a public method that only has two uses in TShock and both of
them are listing players to a player. A foreach isn't rocket science and
this method was originally created just because there was no good object
to iterate on (e.g., a TSPlayer array).
There are two occasions in the codebase when Utils.Reload is called and
we're competent enough that we can just call the event when the reload
happens. Unrelated note, but shouldn't this event be called prior to
reloading? I've kept it the same to preserve existing behavior, but I
think it should probably happen before the reload event takes place.
Either way, I think this is fine.
Arguably, this is one of the more controversial methods that's being
kept. Because it kicks and bans a target player, it's more useful than
removing it and requiring people to interface with the TShock Ban
Manager directly (not a good move for the future). Whether or not this
method sucks is up for debate, but right now I think it's totally fine
to keep it around in a different location.
Some anti-cheat calls were changed to "You have been Bounced." I don't
think we need to tell clients why they were disconnected so they can
tune their hacks better.
On many servers, players are tricked into running the /auth or /setup
command to get them kicked. This is stupid. Since the system is disabled
anyway, we don't need to kick them.
See the changelog entry for this. Basically, it's worse to keep
confirmed broken noclip detection in, even if it detects noclip 90% of
the time, because a random hacker can make a better noclip system and
just evade it 100% of the time by exploiting holes.
Note: even in the previous iteration of the code the search function
returned -1 if it couldn't find it in the system, which would have made
removal of projectiles by ident and owner impossible because they
weren't found anyway.
Either way, this is related to fixing #1584.
