This also kicks those who never finish handshaking upon chat now. (To free up the resources a bit I guess?)
Before a player finishes the connection handshake, the server will check if it's necessary to send them a packet - it checks against a list of necessary packets like:
- ContinueConnecting (Send User Slot),
- PlayerSpawnSelf (CompleteConnectionAndSpawn),
- WorldInfo (Which the server does a further check if the player is at the appropriate state to be sent the world info)
- Status
- Disconnection
- TileFrameSection & TileSendSection
- The player will only finish the handshake once they spawn their player, a normal client would always do this eventually.
- They cannot chat, even if they request world data but just not spawn their player.
- Other clients will not be notified of their join/leave in both cases (dont request WD or do but dont spawn)
- And most importantly, they do not show on the in game player list but still show on the server console /playing cmd.
The `AchievementTagHandler` expects `Main.Achievements` to be non-null,
which is not normally the case on dedicated servers. When trying to
parse an achievement chat tag, it will instead throw.
The tag is parsed when calling `ChatManager.ParseMessage`, which is used
in TShock when writing chat messages to the console. Our `OnChat`
handler uses `Utils.Broadcast`, which will send the message to all
connected clients, write the message to the console and the log. Due to
the order of execution, the message ends up being sent to all connected
clients, but throws whilst trying to write to the console, and never
gets written to the log.
To solve the issue, we make achievements available on the server,
allowing the tag handler to work as expected, and even allowing the
localization of achievements names to appear in the console.
This allows the tshock tile providers to be switched via the config instead of cli args via tsapi, for environments where the command line args cannot be changed.
The previous language was true but slightly unhelpful to non-native
English speakers and users who aren't familiar with server software.
When a fatal startup exception occurs now, TShock tells you what this
means and that it won't be able to start until this is resolved.
There is a slight change the the way QueryResult works in order to satisfy the variances in the new library.
Disposing of the command with the reader appears to solve this, and hopefully, with minimal impact to plugins.
In 44034c7649 I added a magic 0 instead of
a call to an enum because I was looking at an outdated diff that didn't
have `None` as an option. Turns out this was added a day later in a
commit I didn't see originally. Changed to `None` to make code better
documentation wise.
In
8204e2b3f9,
`PlayerAnnounceResult` was introduced, replacing `HookResult`, which changed
the result for `PlayerAnnounce` to a byte called `PlayerAnnounceResult`.
There are two options, `SendToPlayer` and `WriteToConsole`, set to 1 and 2
respectively. Because TShock handles this, we're setting it to 0, i.e.,
don't notify anybody.
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.
