Previously, I updated the SIGINT handler so that it would safely shut
down. This is because I'm an idiot and like most people like me, I use
CTRL + C as my exclusive way to close all programs in the command line
environment. This poses a risk because it doesn't save the world and
shuts down improperly.
However, I forgot that Terraria has interactive menus that you can't
exit from. So, in these menus, the only way out was CTRL + C. @Onusai
reported this, so this changes the behavior a second time.
Now, when passing SIGINT, you can pass it twice. This will cause the
program to actually exit on the second time, such as when you're stuck
at a menu. Hooray.
- GroupManager now validates core groups in the constructor.
- EnsureCoreGroupsPresent -> AssertCoreGroupsPresent.
- Fix indentiation in some places.
- Clarify the intent of this PR in CHANGELOG.md.
- 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
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).
TShock was originally designed to handle many things that Terraria did
not. Therefore, TShock always "took over" for the server password
prompt. We then added the ability to login via the password prompt if
you had an account, so that you could play on a server and login without
having to run /login in the chat window. Then, UUIDs were introduced,
and we added the ability to login via UUID.
This has created a cascading scenario where users are potentially
affected by many different things. We have always treated a user's
runtime intent as the most important: if a user sets something on the
console, it should be taken as the "most true" setting. In other words,
we believe that the most recent choice the user made is the valid one.
But for some of the config settings we have, we've made it opaque as to
how this decision making works. We also aren't clear what certain things
do by default.
Currently, if UUID login is enabled, a user will login "magically" and
bypass any password prompt. Even if this is disabled, though, users are,
by default, allowed to enter their passwords at the password prompt
instead of the server password. Both of these take priority over the
runtime setting.
The problem is that we haven't really made it clear if we should
override the runtime setting here. This is because the Terraria
interactive prompt asks for a server password, and one of the two
"bypass" settings is not a password setting at all. What do we respect?
I decided that the best approach is to just communicate really loudly
about these settings. If a runtime password is set, we'll warn users if
either of the bypass settings are "in play." If it's not set, we'll warn
users if the server password was set in config.json, just so they know
which password is being used.
If UUID logins are enabled we'll also warn users about that and the
security risks attached, no matter what. I don't know that we should
really have this feature, but we shouldn't get rid of it, imho.
The only thing I don't think we need to warn about is if login before
join is enabled. Login before join just acts as a way to speed up logins
for registered users. In an ideal world, users who shouldn't be able to
login should be banned. But I split the difference since we're warning
about UUID logins.
The only real downside to this change is that the PostInit hook gets
bigger. But dumping this stuff in another file/area/etc., seems dumb
since some of the logic exists here already. I think we can refactor
this later, but it's not my most pressing priority.
This whole change was inspired by the fact that @Onusai tried to lock
down their server but failed because of these settings enabled. We need
to be more transparent about logins, and this is a good first step.
- Previous Bouncer checks for GodMode (namely, Hurt) were removed.
- The command now uses the GodmodePower from core Terraria
- The toggle powers (which this command will now make use of) are now
reset on disconnect to prevent accidentally "gifting" godmode to an
unsuspecting player.
Can we store the type of the recent projectile as well? This could be used in my upcoming PR regarding the golf packet where I check for recently created projectiles, and their types. Having only the index is not useful in this scenario, because the projectile can already be killed, so cannot access the Main.projectile array to get the projectile type.
Can this be public instead of internal? Developers could make good use of it, instead of having to implement their own version of RecentProjectiles in their plugins.
Per packet debug logs are redundant for people with the packet monitor
plugin. If you need packet monitoring, please install the packet monitor
plugin.
Update the validation logic to be accurate:
* use pixels and not tiles
* allow master mode
* use npc position and not player position
Cleanup some style inconsistencies in NetHooks_SendData.
This reverts commit 7ad46abced. This
reintroduces the worldpath argument as per request from #1914, but at a
different name. This is because users have configurations like this,
which no longer work:
-world + -worldpath = crash
If you want to use -worldselectionpath to specify a world, you should be
able to use -worldname, but don't use -world unless you specify an
absolute path to a world.
No matter how we solve this we get a support headache (-worldpath +
-world = crash). This temporary stopgap should work to help address
issue #1914 until we can figure out a final solution. Since users are
impacted by this change, temporarily adding this back is the best move.
To be 100% clear, though:
-world + -worldselectpath without specifying an absolute path will
result in a crash that is unhelpful. Please don't do that.
