Lidded containers closing issue

[Jakush]

Expected behavior

I should be able to close any container implementing Lidded interface using method close().

Observed/Actual behavior

Every lidded container remained opened when there were viewers (even though it should be closed because the method for closing was called).

Steps/models to reproduce

Call Lidded#close(); on PlayerInteractEvent

Plugin and Datapack List

Mine and luckperms.

Paper version

This server is running Paper version 1.21-130-master@b1b5d4c (2024-08-10T10:02:42Z) (Implementing API version 1.21-R0.1-SNAPSHOT) You are running the latest version Previous version: 1.21-129-4d7cef3 (MC: 1.21)

Other

No response

[Jakush]

I tried searching on the internet everything I could and it should work, I tried the same code which other people said it worked for them on older version and nothing worked (only a trick by giving you spectator for a tick, but that still has some issues with it and I would like to search for cleaner option)

[Machine-Maker]

I'm not sure this has ever worked in the way you are imagining... It looks like every 5 ticks, the game re-checks the open status and will re-send the block event for opening/closing to clients in range. Additionally, the close method will only have an effect if the open method was called first. You can see this if you just call open right before close, you can see the chest start to close, but then open back again (cause 5 ticks have passed).

I'm not sure what the correct fix is here. It seems this API is fundamentally broken. We could add something like a force-closed boolean that prevents any opening from being sent to any clients. Plugins could toggle that on/off (or a force open). But tieing that into the existing Lidded API doesn't seem feasible.

[Jakush]

From the documentation, I thought close() should always force-close the chest no matter what so I would count with it being closed and not open again. Although I could research more, sorry for that, the PR I wanted to make does not make that sense after this being told.

So from what you've said, maybe adding a new setter & getter with enum LiddedStatus would be good approach by me. Lidded status would have 3 values, FORCE_OPEN, FORCE_CLOSED, DEFAULT. FORCE_OPEN would force Lidded to be opened no matter what, FORCE_CLOSE would force Lidded to be closed and DEFAULT would make it behave normally (for example if someone wants to reset it custom behavior). With that Lidded#isOpen could be overriden to work normally again and it would return its current status (even if it is forced).

What do you think? (btw i can try make it in new pr, i mean i somehow broken patch um)

[456dev]

I've also had a look at this, and I think I've got a patch exposing the ability to force open/force close containers lids

I also got a new feature working, a flag to automatically remove the force flag (once the first real viewer opens it for for forced open, or once the last real viewer has closed it for forced closed)

The enum based API sounds sensible though, since all the states are mutually exclusive