This replaces IgnoreActionsForCheating in TSPlayer with a new
IsDisabledForStackDetection field that tracks the same basic data.
The previous way we did this was storing a string as the "reason"
why a player was disabled for cheating, but it only stored the last
hacked item stack that caused the check to fail. Since we already
have OnSecondUpdate which notifies on _all_ items, we don't need
to store this info in such a useless way anyway. They'll find out
in one second what they need to remove in a more alarmist way.
This is the first commit in a series to rewrite CheckIgnores()
into whatever its replacement becomes.
IgnoreActionsForInventory was probably used by the SSC system prior
to when we had in-game support for SSC (ergo, when we just checked
to make sure you had removed all items before joining and worked
our way up in inventory data to track it). I could be wrong about
this though.
Now, IsDisabledForSSC tracks only if a player is shut down due to
SSC, rather than a reason that gets broadcast.
This reverts commit 3f79a904da.
If prefix is < 1 and we block this event, clients can no longer
delete picked up items. This is what caused what Joshwoo reported.
http://rubyonrails.org/doctrine
The problem with most programmers is that they refuse to see any
logic in thinking about a problem from the other side, even just
once. You can't argue with someone over what opinionated "programmer
happiness" things are because logically you'll always be outmatched
with "well you can just do it this other way."
Take this example. How is !args.Player.HasProjectilePermission any
easier to understand than args.Player.LacksProjectilePermission?
-> One is direct: it focuses on what a player doesn't have.
-> The other is indirect: it's the inverse of have.
You can read one in a sentence and think "so if a player lacks a
permission then this happens" whereas the other is like "invert
if a player has a permission." In this soupy mess of a codebase
where you're trying to sort out what 300 magic numbers mean and
what everything else is trying to do, then it's kinda nice to
be able to read something and understand it immediately.
TShock used to call the StartInvasion method in Main with a type
and a size, but then in some update it stopped taking a size. So
you have to change a field to change the size, but the problem is
that the field is reset when StartInavsion is called. This means
that any effort to manually change the size would have failed due
to the fact that the field is reset at the end. The order has been
changed to account for this.
In addition, the start size is now set, so the game can report
progress correctly on the current invasion.
The current initial setup system would re-enable if setup.lock
was removed even if an account was in the database. This is
because when we switched to "owner" being the primary target
of the setup system, we failed to anticipate that an account with
superadmin would never exist in the database in an ideal
condition.
This is better verbiage. If you think about it, you never really
want the "authentication system" to shut off. Doesn't that mean
that the server doesn't authenticate people anymore?
