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.
This is a combination of 3 commits:
* @Olink was right. Adding additional check. Modifying range check.
There are two ways to place food into a plate. One is by having it in hand (mouse) and right clicking, the other is by having the item selected in the... "inventory bar"(?) and right clicking the plate.
Tested range, if player is outside the range, they should not get their item back.
* FoodPlatterHotfix - Update IsInRange range value.
To suggestion of Olink, to consider player lag and increase the range check.
Co-authored-by: Lucas Nicodemus <shank@shanked.me>
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.
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 commits adds rudamentary support for dirt bombs. There's probably
some edge cases in here but the entire handler really needs to be
rewritten. This is total spaghetti and completely unreadable and
unrecognizable.
This is in response to discussion #1859. Due to the nature of this
already terrible handler, I refuse to add any other types of checks for
whether or not this item is banned and lava. If you want to ban lava,
ban a lava bucket. Don't ban an infinite lava bucket, because finite
lava is still infinite lava in this topsy turvy game where the client
rules the world.
This type of change is designed to make it easier to debug problems with
Bouncer's anticheat checks and antigrief checks by allowing server
operators to send better reports. In particular, the logs will help us
diagnose precisely which checks are tripping, and they can cross
correlate the item with the check to adjust the precise check.
More work is needed to add more checks in more places, but you can't
just do this naively and need to actually think when adding things.
It was discovered that LastNetPosition is being checked to see if it's
zero in Bouncer. Then, Bouncer rejects the update. The default is zero
and potentially this can be zero in other ways. The original code in
master (checked at 9f4892f in GetDataHandlers) had an additional write
on LastNetPosition to update it, but this write was not moved over to
Bouncer. Thus, there is a high probability that players are "desync'd"
after LastNetPosition gets stuck at zero and never updates.
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.
