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.
