I was wrong, not all bobbers are named "Bobber".
Just found that Projectile now has an extra field which determines if the given type is a bobber. This field is set in Projectile.SetDefaults method in the following logic
`((type >= 360 && type <= 366) || type == 381 || type == 382 || type == 760 || type == 775)`
I think it is reasonable to use the bobber field, as it would be updateproof too.
Tested and working. Fixes#1985
The actual issue was a missing `!` beind IsInRange. If player was doing a valid fishing event, it handled the NPC spawning.
I've split up the checks to make clearer debug messages.
Main.projectile objects are never null. Bobber projectile is never killed when the FishOutNPC event occurs. The projectile type in the check can only be 0 if no recent projectile found that has the name Bobber.
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.
I know, this is not something important, but I'm going through the new packets one by one and adding events developers can work with, patching exploits, and thought this could be a core permission.
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.
Fixes#1774.
This commit is designed to fix the clientside door desync issue. Based
on the order of events that I've been able to see, the way that door
opening works is like this:
1. Client sends a door open request.
2. Server echoes request back to client.
3. Both server and client simulate door opening.
4. The client that requests the initial door open sends a tile square to
the server for some reason.
In TShock, under all circumstances, we send a tile square back to the
client that sends one in, unless you have the
`tshock.ignore.sendtilesquare` permission. This adds a deviation: it
does not network data back if the event is just a door change. Doing
this is safe from the perspective of actual gameplay. A previous
iteration of this commit synchronized data to other clients, but that
seemed superfluous.
This does not really solve the underlying problem or answer the question
as to why sending a tile square back to the client seems to throw it
off, but it does. I was not able to replicate the desync issue anymore
with this branch. I expect that it will be safe to keep, because the
improved logic will only happen if the tile square had no effective
changes in addition to the door changes.
Run /sync if your doors disappear. This will resync your local client
with the server state. For more information, please see the associated
changelog entry.
Per packet debug logs are redundant for people with the packet monitor
plugin. If you need packet monitoring, please install the packet monitor
plugin.
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.
