This commits adds rudamentary support for dirt bombs. There's probably
some edge cases in here but the entire handler really needs to be
rewritten. This is total spaghetti and completely unreadable and
unrecognizable.
This is in response to discussion #1859. Due to the nature of this
already terrible handler, I refuse to add any other types of checks for
whether or not this item is banned and lava. If you want to ban lava,
ban a lava bucket. Don't ban an infinite lava bucket, because finite
lava is still infinite lava in this topsy turvy game where the client
rules the world.
This type of change is designed to make it easier to debug problems with
Bouncer's anticheat checks and antigrief checks by allowing server
operators to send better reports. In particular, the logs will help us
diagnose precisely which checks are tripping, and they can cross
correlate the item with the check to adjust the precise check.
More work is needed to add more checks in more places, but you can't
just do this naively and need to actually think when adding things.
It looks like the only time the client informs the server of the spawn location is via the PlayerSpawn packet. In SSC, understandably, we don't trust any updates from the client if we can avoid it. In this scenario, we have code in PlayerSpawn to check for beds when they attempt to spawn, but no code to handle negative spawn locations. The client sends -1,-1 coordinates when the player has no spawn. We should trust this.
It was discovered that LastNetPosition is being checked to see if it's
zero in Bouncer. Then, Bouncer rejects the update. The default is zero
and potentially this can be zero in other ways. The original code in
master (checked at 9f4892f in GetDataHandlers) had an additional write
on LastNetPosition to update it, but this write was not moved over to
Bouncer. Thus, there is a high probability that players are "desync'd"
after LastNetPosition gets stuck at zero and never updates.
The reimplementation of Terraria player sync was first created by
@Zidonuke when introducing better antihack and the item ban system. He
added this because he was probably attempting to correct the client that
sent that sent bad data. The primary purpose was to send data back to
the client, not necessarily for the purpose of doing anything for the
server. This is demonstrated by the fact that when we added player
update handling, we started rejecting the packets outright and not
sending the player any packets. This means that functionally we don't
run this code hardly ever if someone is actually disabled.
Some of those code was related to /confuse. That is also being removed.
