Piston-Fly bypass (fly outside of claims)

[NO-UUID]

Describe the bug

Players can use pistons to fly outside of claims.

To reproduce

Steps to reproduce the behavior:

• make claim
• enable fly
• push yourself outside of claim using piston
• you can now fly everywhere

Expected behavior

I assume pistons or player movements when pushed by pistons would have to be handled, not sure about performance impact tho...

Screenshots, videos, or logs

There are no errors, video to replicate: https://www.youtube.com/watch?v=Z0IAlvc8lBE

Configs and console errors

N/A

Versions

[12:32:32 INFO]: [GPFlags] Server version: Paper 1.21.4-DEV-519ab29 (MC: 1.21.4)
[12:32:32 INFO]: [GPFlags] GP version: 17.0.0-54-g885c0ee-dirty
[12:32:32 INFO]: [GPFlags] GPF version: 5.13.7.146
[12:32:32 INFO]: [GPFlags] Dependent plugins: SurvivalPlus GSit

[akdukaan]

Thanks for this report. It looks like this issue stems from PaperMC/Paper#8325.

Reading through that, there’s a few approaches I could take

1. Run a repeating task that checks if fly status needs to change every few ticks. Means that fly will be fixed after a short period, but then I need to figure out just how short of a period to use and shorter periods mean worse performance.
2. Listen to the piston event and check if fly status needs to change for all players next to the piston. I think pistons can push a larger radius than just players one or two blocks away, especially if combined with like slime or honey blocks, so I might need a rather large radius.

I think I should also call out that all movement flags are affected in the same way. So I don’t just need to recalculate fly but rather I should trigger a postclaimborderevent so that all flags can catch this behavior.

And for these other flags, like ExitMessage for example, I don’t want them triggering multiple times. I might need to keep track of which movement events have already been correctly caught by the event listeners and which haven’t yet been caught so that I can run a postclaimborderevent on those properly. I don’t think that can be done with full accuracy. So do I just remove those event listeners completely and rely solely on the scheduled task? Feels like it would be a worse experience for there to be a little delay for every movement based flag.

Doesn’t seem like any solution is going to work right. Will need more time to think about this. Might even end up waiting until Paper can address it which could be years from now.

[NO-UUID]

I have a few more considerations for option 2.

• I think up to 8 blocks?
• Check would only have to run on push not on pull?
• Should consider that multiple locations would have to be checked and the fact that BlockPistonExtendEvent can fire A LOT if pistons are used for farming,

I'm not sure what would be a good way to go about this tbh.