The backpack API contains no features that tell you when or whether the backpack is open or not. I would love if an event was fired for whenever backpacks are opened or closed, or at least a boolean property that’s readily available.
Currently in my game, pressing backquote is not enough to make the backpack accessible when the Player’s CameraMode is set to LockFirstPerson. I need to place a transparent GUI with modal set to true somewhere. While this makes the inventory accessible, reliably setting the UI’s modal property back to false becomes impossible.
I’ve tried checking for clicks in various ways (including seeing if gameProcessedEvent is true). Just via userinput as well as frames. But there’s no way to easily guess the scale of the actual backpack UI, UI Constraints are also of no help here. Estimating the exact correlation between Size and Viewport is extremely difficult. I’ve tried covering the surrounding area with transparent frames so they can capture any mouse clicks. However that does not work.
The only way I’d see this working is if I made a function that scales + positions UI based off the Camera.ViewportSize on some kind of loop, and then detect if any input resides outside of said area. I think this approach is pretty far fetched, especially since you’d have to guess how the backpack UI size is correlated with the Window/Camera Viewport size.
None of these fixes are a guaranteed fix.
An event for when the backpack is closed would be appreciated addition to the existing API.
apparently you can find all of the coregui by setting this toggle to true. However this is still inaccessible by code during runtime.
the UI is found under
I couldnt easily find any size correlation because it’s
After pasting the legacy UI into a blank file, I managed to decently estimate how the scaling works around the borders.
I guess I’ll just have to capture mouse input with this method, since there’s no better options.
This approach does not work either because the backpack relies on being closed when clicking on no UI objects at all. no UI objects must be capturing input.
This does “solve” my issue to some degree, although I’d argue that I’m worsening UX by sinking input when it comes to closing this.