In crafted (hacked) packet sending, people could send the DisplayDollItemSync packet with an entity ID that is not actually a display doll. This would not happen in a normal scenario.
If they send the crafted packet, our hook would have been invoked and it would have contain a null TEDisplayDoll object since we tried to get the TileEntity object as a TEDisplayDoll object.
An event that is called when a player modifies the slot of a DisplayDoll (Mannequin).
I was trying to think from a developer friendly perspective here.
Instead of passing seperate variables for type/stack/prefix, thought I pass an Item object.
As well as, instead of having devs who work with this hook figure out and implement how to get the Item of the DisplayDoll, I just provide it in the hook.
I can imagine this being used for creative purposes in plugins.
This packet is never sent from the client to the server in a normal scenario. Although with modded clients, a packet can be sent to modify the cavernMonsterType of the server world and have the world spawn defined NPC types. Can be used to have the server randomly spawn bosses on players in caverns.
Is it okay to have this simple handling in GetDataHandlers? A seperate class felt like an overkill.
Moved the HandleSyncRevengeMarker packet handler to it's "correct" position, so I won't have merge issues between my last PR. As I've mentioned there, we have the Packets in their numerical order.
This is received from the client when they are trying to display an emoji, this comes in to the server, gets processed, and the server sends back the Emote Bubble packet to the clients.
Can we store the type of the recent projectile as well? This could be used in my upcoming PR regarding the golf packet where I check for recently created projectiles, and their types. Having only the index is not useful in this scenario, because the projectile can already be killed, so cannot access the Main.projectile array to get the projectile type.
Can this be public instead of internal? Developers could make good use of it, instead of having to implement their own version of RecentProjectiles in their plugins.
Update the validation logic to be accurate:
* use pixels and not tiles
* allow master mode
* use npc position and not player position
Cleanup some style inconsistencies in NetHooks_SendData.
