Added usage examples for:
- banning offline player by account
- banning offline player by ip
- banning online player by index
Added ban help examples after ban help commands and fixed a few minor visual/grammar issues relating to ban help
Added config based checks so error messages only tell what is relevant to the user. Doesn't make any sense to tell them you can do /login when UUID is set to false because they will just get the same error message again. Also added an additional info message to the onboarding/password registration process so the next steps will be more obvious for first time users.
now this should be more in line with how other boss summons are currently handled, also made the sundial user messages better thx to quake's suggestions
There are 3 different ways Bouncer uses these:
- Not checking `TilePlacementValid` at all.
- Checking `TilePlacementValid`, rejecting, but then doing a
`SendTileSquare` to that player.
- Checking `TilePlacementValid`, rejecting. _(this is what we should
always be doing)_
Not checking `TilePlacementValid` can allow for placement outside of the
world (unknown results), and checking `TilePlacementValid` and sending a
`SendTileSquare` on rejection causes the server to try to frame that
square. In the case of invalid coordinates (negative), framing takes
much longer than expected.
If the player does not have permission to summon bosses, they should not be able to kill Prismatic Lacewing, which summons the Empress of Light.
Using the Enchanted Sundial while ForceTime is set to day or night (via config) will conflict with TShock's continued attempts to set it back to day or night, this makes the world appear very glitchy.
The rate limiting error message used the term "tokens," which could be
easily misconstrued to refer to REST auth tokens, and not rate limit
leaky-bucket tokens. Since we don't expose the internals of the leaky
bucket to end-users, this error message is essentially just not good.
Without knowledge of a leaky bucket/GCRA, it really makes no sense.
Therefore, this changes the message to indicate that the "tokens" are
rate-limit tokens. It also adds a hint that there's a config setting
that can be changed to raise the limit, which further makes it more
understandable, and also provides a reasonable hint as to what setting
to change to alleviate this problem immediately. This makes it easier
for users to debug and less likely they have to read old docs/wait for help.
This allows server operators to more easily locate their world paths,
particularly on Linux and macOS, where it isn't very obvious. To
determine where the actively loaded world is, simply run `/worldinfo`.
The default guest group is critical and shouldn't be removed without
either TShock doing something like automatically recreating it if it
doesn't exist, or not having a huge problem if it doesn't exist.
I chose to take the easiest path, preventing users from removing it. In
theory the message gives enough context to imply "okay, go change the
group now."
This should be a relatively small edge case but I wanted to resolve it
while I was here.
@punchready reported that there was an issue with the /warp send command
checking for position != (0,0). I tried to figure out what was going on
here, and I came up dry. I think this is vestigial from some other
database or file format storage. When @MarioE converted everything to
the new warp system, he preserved the check. The problem is that the
check seems to be based on the idea that a non-existent warp would
return the default constructor (which would contain Point.Zero).
Instead, a warp not found returns a null now.
Therefore, the proper thing to do, as implied by @punchready, is to
simply nullcheck this value instead.
