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.
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.
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.
This commit adds a fallback to address problems with FindByNameOrID
potentially returning ambiguous results. Now, in response to a multiple
match error, a player can specify tsi:[number] or tsn:[exact name] to
match a user ID or name exactly. This behaves analogous to the old
behavior of the search method.
Currently, the TSPlayer FindbyNameOrID method aborts if it finds an
"exact match" based on this criteria:
1. If the player ID is on the server, it must be the thing we're looking
for. Therefore, return that.
2. If the case sensitive "exact match" is on the server that isn't an
ID, that must be what we're looking for. Therefore, return that.
3. Just yolo and downcase everything and return any number of matching
players next.
This commit changes the behavior because some players have been joining
servers with ambiguous names, like `1`. In the current system, this
player is difficult to query because they're an "ID" and therefore an
exact match will be returned even if a player name exists that matches
the criteria.
This also alleviates the issue of a case exact match falling down the
same trap. It's ambiguous enough in all of these situations that an
admin should just be using a player ID instead.`
