CheckRangePermission accepts coordinate which is divided by 16.
The Position variable which is passed in ForceItemIntoChestEventArgs is
multiplied by 16.
(To be more exact. `new Vector2((float)(Main.chest[i].x * 16 + 16),
(float)(Main.chest[i].y * 16 + 16))`)
The + 16 is there to get the middle of the player so it can make an
accurate check when checking distance between chest and player.
So I'm not really sure if the Position arg should be even passed in the
eventarg.
Anyway, CheckRangePermission always returned true because of the above,
and handled the event, so players could never quickstack into nearby,
unless they had RangeChecks off.
"True if the player should not be able to place the tile." (In our case,
stack items into chest)
Why doesn't CheckRangePermission contain a check on an actual range
permission of the player's group? So groups with the permission could
bypass the check.
Just wondering if there is any legit reason for that.
Reworked the StatTracker client side stuff to match the new server side
changes. Also fixed the memory tracking, plus added a 'providerid' for
certain server hosting providers
Removed check ignores failed and player disabled for
not being logged in whilst SSC is enabled console messages, as
they are incessant in larger servers.
The messages are not informative as they are not reasonably
actionable by the console, and there is no point in spamming
server operators about such issues.
Obsoleted the old disable method
Added a config option to disable OnSecondUpdate logs (disable message is written only to console if set to true)
Updated all instances of the obsolete Disable method to the new Disable method
It appears that there is a whole lot of display logic in the official
Terraria StartInvasion method, which is why martian invasion wasn't
working properly.
TSAPI now contains a slighly modified startInvasion method which takes
an optional invasion size, so TShock's StartInvasion method has now
been refactored to use TSAPI's invasion, restoring martian invasion
functionality.
Fixes#1087
