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.
UsingBiomeTorches: Whether or not the player has the torchgod biometorches ability enabled
HappyFunTorchTime: Whether or not the player has fought the torchgod before (for logic that checks for torchgod spawning)
unlockedBiomeTorches: Whether or not the player has the torchgod biome torches ability unlocked
This fixes a ridiculous typo in GetDataHandlers where we were setting
the UsingBiomeTorches flag based on having unlocked biome torches,
rather than actually being used. Thanks to @Arthri for the tip!
If a player has the tshock.ignore.ssc permission, odds are that they may
want to know that their data isn't being saved or not. This change
allows users to be notified if they have SSC data stored in the DB but
they aren't having it loaded due to the aforementioned permission.
This permission causes great confusion, but we can't really change it
because we would break existing setups. This is an easy change that
gives people a reason why they suddenly "have no items."
This new option can be turned off in the config file for SSC if it's not
desired.
This change also modifies some of the log messages so that it's clear
why the SSC save didn't occur for a given player.
Reverted default (when no duration is specified) buff duration to 60s, added formula instead of hard coding max duration as per Quake's recommendation, made error message more self-explanatory
Since this check is based on damage and healing amount is based on 20% of the damage, it makes more sense to skip the check if the player has ignoredamagecap (trustedadmin and higher).
This adds the follows permissions to the following items:
- tshock.tp.tppotion: Teleportation Potion
- tshock.tp.magicconch: Magic Conch
- tshock.tp.demonconch: Demon Conch
With 1.4.2.2, we no longer need to offer an escape hatch due to the
underlying bug involving godmode being permanently applied to local
players now having been fixed.
- The command now tells the user that the operation succeeded.
Previously it would be a silent command, potentially leaving the user
wondering if it worked
- Add /ungodme to allow unstucking godmode for involuntarily godmodded
characters
- Warn player about disabling Godmode before disconnecting
- Minor change to command format to reduce code copypaste.
