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.
It gets `TPlayer.hostile`.
I also wanted to add the ability to change `TPlayer.hostile`, but noticed a property `TSPlayer.Team`. You can only use the `TSPlayer.SetTeam` method to change it. So it's exactly the same here: You can use the method `TSPlayer.SetPvP` (By the way, it should be renamed to `TSPlayer.SetHostile`)
Due to an issue that stops the SSC config persister thing from working,
I moved the config item that's new back to the config file. I tried
applying the patches from
https://github.com/Pryaxis/TShock/pull/2354/commits but these didn't
actually resolve the issue. I'm keeping the commits here but I'm not
sure they help.
The core problem is this: if you add a new config file item to the ssc
config, the ssc config is overwritten with the default config items
instead of being merged automatically with the new items. This is a
critical issue as it means that SSC is disabled on all servers that had
it enabled and results in "data misplacement" which is alarming enough
to cause users to think they had data loss, which is not ideal.
Until the issue with the SSC config is resolved, I'm not willing or
confident to change it.
Inferring from the usage of it, this method was expected by its callers to be a square centered around the given coordinates (x, y), hence this being a fix.
