There are 3 different ways Bouncer uses these:
- Not checking `TilePlacementValid` at all.
- Checking `TilePlacementValid`, rejecting, but then doing a
`SendTileSquare` to that player.
- Checking `TilePlacementValid`, rejecting. _(this is what we should
always be doing)_
Not checking `TilePlacementValid` can allow for placement outside of the
world (unknown results), and checking `TilePlacementValid` and sending a
`SendTileSquare` on rejection causes the server to try to frame that
square. In the case of invalid coordinates (negative), framing takes
much longer than expected.
This is the first commit in a pattern that I'd like to follow. The
concept is that we specifically create handlers for things that are
"illegal per se." That is, there are no possible situations (in the
current protocol) where a packet of this type is received from a client.
In this case, I moved the emoji handler out of the Handler just for
emoji, since it seemed like an obvious case.
The rule of thumb is simple: if something is illegal per se, there
should be no possible way in the vanilla client to achieve this result.
If a player sends this combination of packets they *must* be hacking.
Not that there is a 99.9% chance they're hacking, but that there is a
100% unambiguous chance that they're hacking.
Something is illegal per se if it can only be created by a hacked
client. If there's a crashing bug that a normal player can do with a
complex series of vanilla events, that is not illegal per se.
The goal of this namespace and class of handlers is to handle exactly
one type of protocol violation, and remove the packet accordingly. If it
is ever reported that the packet can be sent from a vanilla client, the
check must be removed as it is no longer a per se violation of the
protocol.
This fixes false positive cheat detection when throwing rotten eggs at town NPCs while wearing Frost armor set. Also made the debug and kick messages more clear for future reference.
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).
OnFire3/Hellfire - New magma stone debuff that deals 15 dps instead of 4 dps
Frostburn2/Frostbite - Frost armor new set bonus 25 dps instead of 8 dps
BoneWhipNPCDebuff - Debuff applied from new Spinal Tap whip
We do not allow piggybank and safe to be placed if SSC is enabled.
The DefendersFroge and VoidVault have the same functionality as far as I know. So adding these two missing tiles.
I moved the block that checks for max tile and wall types to the start of the method where it checks for the editData (type) being smaller than 0.
I merged these checks, so it gets caught under the same hood.
We had a block that was a bit chaotic and hard to understand.
I've split it up so its a bit clearer. It checks if the tile data that is being placed, comes from the item they are selecting. There were additional checks merged in it, because terraria does not set the createTile of some items, so without the check it would have get caught as invalid placement.
I added a valid placement check for one of these, which is the Ice Rod/Ice block placement.
Handle action if the player is using icerod but not placing ice block.
There is no need for a check here on Dirtbomb, because the player only sends the projectile, the tiles are being placed by the server.
This fixes#1980 .
The issue came from checking for recently created ropecoil projectile. But didn't actually check if the player is holding a ropecoil item.
Because of this, users could not place regular ropes.
**This commit does not have any effect on actual gameplay as of current project state, but it does let valid projectile creation pass through instead of getting caught up in Bouncer. That catch is currently disabled for the time being, until all valid projectile creation check is added.**
Things would have get caught up in our bouncer eversince 1.4. We commented out the catch (the disable and handling) for now, but none of these new projectiles were added to let them pass.
Renaming stabProjectile to directionalProjectile. Adding staffs to directionalProjectiles
Adding check for GolfClubHelper projectile.
Left in a debug check for golfball projectile. I would want to see if the reject gets triggered in a proper server enviroment. I didn't want to handle the projectile just yet.
Adding GolfBallItemIDs list in Handlers.LandGolfBallInCupHandler.cs
