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.
This is called when a player is placing a fruit (item) in a plate.
Adding checks to see if they have permission to place or replace a fruit in the item.
Checks if they are within range. And a check to see if they are legitimately placing the item from their hand, and not by sending a raw packet.
This change applies @AxeelAnder's suggeted patch from #1845 to attempt
to resolve spawn point issues. If you remove your bed spawn point it
should send you back to the map spawn point with this.
This commit changes the logic for sending and accepting journey research
requests -- only processing those requests in SSC makes sense. This
stops sending extra data to clients that may not know what to do with it
when it's not relevant (not in both SSC and journey mode).
This also stops us from accepting erroneous journey mode NPC spawn rate
update requests when journey mode isn't on but SSC is on due to a weird
client glitch in 1.4.0.4.
