As pointed out by @QuiCM, TShock.Players is actually an array and not a
smarter collection, so length will return the total collection size and
not the active players. An earlier commit was added that gives TSPlayer
an ICollection<TSPlayer> that contains only active players. This is now
the basis of determining the number of active players on the server.
This is not a great method, but it's actually the only method in TShock
that interpolates the %map% and %players% variables and it used in at
least three places in the codebase. Since it's already so specialized,
it's not worth changing it to take an actual File object, in my humble
opinion.
This also clarifies what the method does and what makes it special, as
opposed to being fairly generic.
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.
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.
This just changes IgnoreActionsForClearingTrashCan to meet the
same naming scheme for the rest of the old ignore checks. For
consistency. Consistency is nice.
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 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?
Frontend still doesn't work properly. In particular:
1. Need a way to list bans by account name.
2. Need a way to unban by account name.
3. Really need a way to change the IP on a ban lol.
Ban system still needs to be be rebuilt fully, but at least this
doesn't necessarily character ban someone if you were going for an IP
ban.
Fixes#1412
/su elevates you to superadmin for 10 minutes.
Account creation instructions tell you to use the "owner" group.
If you fail to run a command but have the su permission, you're told
that you can override it.
Fixes#1505
/ban add now replaces add, addtemp, and addip.
New syntax: /ban add <target> [time] [reason]
Examples:
- /ban add Shank 10d Rewrote the ban system.
- /ban add Ash
- /ban add 127.0.0.1 5d Go work on homework.
Note that if you want to specify a reason and a permaban, you need
to use 0 (zero) as the duration.
Examples:
- /ban add Ash 0 Love ya.
- /ban add Shank 0 Hacking.
Closes#1510
As pointed out by @hakusaro, in order to prevent any damage during the process all database calls need to be done in a transaction. Transactions allow us to rollback from a pending state in case something goes wrong.
