search

PaperMC / Paper

The most widely used, high performance Minecraft server that aims to fix gameplay and mechanics inconsistencies
https://papermc.io/
Other
9.7k stars 2.27k forks source link

Client desynced blockstates when disableNoteBlockUpdates is enabled #9496

Closed Boy0000 closed 8 months ago

Boy0000 commented 1 year ago

Expected behavior

When setting is enabled there should be no updates to the block server and client side.

Observed/Actual behavior

For majority of the cases this is what happens, except minor flickering before client acknowledges the block again Main case I could trigger a consistent client-side desync was with exploding TNT

There was a similar issue with Tripwires where client was predicting the Powered-state when walked over. Fixed when the disableTripwireUpdates setting is enabled or EntityInsideBlockEvent was cancelled Making this as I wasn't sure what would be needed done in a PR to fix this. Since tripwires just return before a checkPressed method is called

Steps/models to reproduce

  1. enable BlockUpdates.disableNoteblockUpdates in paper-global.yml
  2. Via a plugin or /setblock, place a noteblock that isnt the default blockdata
  3. Explode it with TNT
  4. Neighbouring Noteblocks will be desynced on client until resent via an interaction etc

Plugin and Datapack List

plugins [12:52:13 INFO]: Server Plugins (0):

datapack list [12:52:26 INFO]: There are 2 data pack(s) enabled: [vanilla (built-in)], [file/bukkit (world)] [12:52:26 INFO]: There are no more data packs available

Paper version

version [12:52:15 INFO]: Checking version, please wait... [12:52:16 INFO]: This server is running Paper version git-Paper-81 (MC: 1.20.1) (Implementing API version 1.20.1-R0.1-SNAPSHOT) (Git: fe780d0)

Other

https://github.com/PaperMC/Paper/assets/62521371/4e93e2b4-1f10-4aa2-8d2b-6ee68b2992dc

electronicboy commented 1 year ago

I mean, this sounds peak "it does what it's configured to do", idk if we should be special casing trying to send updates for this stuff back to clients, imho, that kinda falls out of our responsibility in a sense

lynxplay commented 1 year ago

I honestly also think this is outside of the configuration option. It promises no block updates to the blocks, not that the server also actively prevents clientside desyncs. This should be relatively straight forward to also fix on the plugin side by doing what the server would do, resend the block state ?

KillerCreeper112 commented 3 weeks ago

There's currently no way for a plugin to reliably fix this though. The point of the disable-noteblock-updates setting is so plugins don't need to listen to physics events, right? Yet, to implement a decent fix for this, a plugin would need to use listen to physic events anyway.

electronicboy commented 3 weeks ago

Welcome to the rabbit hole that is capturing every single case where client predictability causes a desync between the client and the servers state. The general understanding that was made when we accepted Thais as a feature is that we would not be chasing all of these.

On Tue, 27 Aug 2024 at 19:12, KillerCreeper @.***> wrote:

There's currently no way for a plugin to reliably fix this though. The point of the disable-noteblock-updates setting is so plugins don't need to listen to physics events, right? Yet, to implement a decent fix for this, a plugin would need to use listen to physic events anyway.

— Reply to this email directly, view it on GitHub https://github.com/PaperMC/Paper/issues/9496#issuecomment-2313214172, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJMAZEBBPFN3FOB5MHTLO3ZTS6RTAVCNFSM6AAAAAA2LHCPDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGIYTIMJXGI . You are receiving this because you commented.Message ID: @.***>