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.
It looks like the only time the client informs the server of the spawn location is via the PlayerSpawn packet. In SSC, understandably, we don't trust any updates from the client if we can avoid it. In this scenario, we have code in PlayerSpawn to check for beds when they attempt to spawn, but no code to handle negative spawn locations. The client sends -1,-1 coordinates when the player has no spawn. We should trust this.
The reimplementation of Terraria player sync was first created by
@Zidonuke when introducing better antihack and the item ban system. He
added this because he was probably attempting to correct the client that
sent that sent bad data. The primary purpose was to send data back to
the client, not necessarily for the purpose of doing anything for the
server. This is demonstrated by the fact that when we added player
update handling, we started rejecting the packets outright and not
sending the player any packets. This means that functionally we don't
run this code hardly ever if someone is actually disabled.
Some of those code was related to /confuse. That is also being removed.
These are high priority checks we really want to look at. I want to add
more of these debug statements to all checks in Bouncer and other parts
of GetDataHandlers, but I think this is good enough for now.
