Creating a long row of grass with vines below and then mowing it without breaking the vines below could cause a tile framing stack overflow due to all vines being cleared at once if one of them is being broken on the server or if the client simply loads the corresponding section.
Warning: this does not fix eventual existing worlds that are already in such a state.
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 commit will modify the RequestTileEntityInteractionHandler to use HasBuildPermissionForTileObject when checking for building permissions for Hat Rack and Display Doll to give an accurate response wether or not any part of the object has an overlapping protected region.
In a previous PR I have added the tile entity request packet handler which checks for building permissions to prevent the unauthorized player to open a DisplayDoll and see its content.
This Handler is being added to prevent *Hackers* from modifying a DisplayDoll through direct/crafted packet sending, or by sending raw byte data to the server.
In a valid enviroment, the player couldn't even get to see the content of the doll in the first place, to then try to modify it's items.
Because of this, I do not bother with making sure the player gets their item back.
**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
