- AssertGroupValid now both sends the message and kicks the player
depending on input parameter.
- /login and DataHandler code is now an identical assert check.
- Server will no longer start up when the guest or default groups cannot
be located.
- Players joining with unknown groups assigned to them will be
disconnected with an error
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.
This re-enables command input when backgrounded. To disable this
behavior, pass -disable-commands. This patch is from @DeathCradle, who
we love immensely. Please give him all of your money. It's the ethical
thing to do.
Fixes#1450.
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.
TShock.ConfigFile was deprecated and therefore changes applied in
previous commits were not applied until now.
See:
* f567486c47
* 39147355c1
* 597e403d50
This commit allows server operators to disable build permission failure
notices. This is because some servers wish to have a "silent" operation
mode where the server doesn't send out these messages to users. This
makes sense, e.g., when the server is a "museum" and isn't intended to
be changed.
The default value for the respawn timer was 5 seconds, but this always
looked wrong because the default game respawn time is at least 10
seconds for classic characters. This can always be changed in the config
file, but looks significantly better when it matches the default imho.
This commit fixes an issue where players could bypass the respawn timer
by using /home. Specifically, TShock rejects the command if the player
is dead.
Basically Color.Green looks ugly and Color.LightGreen looks less ugly. I
could see changing the default to something like pure green, but I think
this might cause people to be like "yo why is this so bright."
Now arguably this should be configurable but I'm not going to
revolutionize the world by abandoning far more important work to allow
more artful messages. I just think that Color.Green is ugly enough that
I can't tolerate it.
Long ago in the early days of TShock someone asked why CTRL + C wasn't
handled and there was an explanation given along the lines of "something
something not supported on mono something something" or similar.
Attempts were made to try to handle console interrupts unsuccessfully
and the code was ripped out.
However, it's 2021, and we can now handle this signal and do the right
thing (which, ostensibly, is to save the world and shut down). Many
people like me reflexively hit CTRL + C because they want to shut down
the process. It's very infuriating that the current behavior results in
the server just dying and nothing being cleaned up properly.
Therefore, this commit changes the behavior to handle the interrupt,
save the world, and shut down nicely.
(If you still want to shutdown without saving the world, use off-nosave,
or idk, send SIGKILL).
Like all of the other server mods I've used use /slay and not /kill and
it's really frustrating to type the wrong thing so I'm just going to add
an alias and hope nobody else minds.
This partially implements ISO8601 + RFC3389 dates for backup filenames.
As noted in the changelog, this was a sponsor request, and also, it's
impossible to put the `:` literal in most files in most filesystems. So
as a result, this is technically not compliant with ISO8601 or RFC3389
but it is closer.
Also, wait, I don't even know because I don't have enough money to buy
ISO8601 so we'll just assume this is compliant. Job = done.
This reverts changes to the TSAPI submodule because if you're unlucky,
you can get git into a nasty state where it doesn't know up from down
anymore. This leads to bad things. Very bad things.
If you get git into a nasty state use:
1. rm -rf git/modules/TShockScaffoldAPI
2. git submodule deinit --all -f
3. git submodule init
4. git submodule update
