Hi there just wanted to leave a list of tweaks to improve the custom drops screen after having ran it for a few events on our server.

From player feedback: Probably the number 1 complaint we had from players and one that seems like an overlook. Don't close the UI with the escape button, the regular drops screen doesn't do this no real reason for this one to. It's not a huge deal but it would be a great boost from the user friendly side of things. We all know players tend to do the most random things. It would also reduce the implementation needs for the developer since you'd want some sort of extra cache system for players to reopen their closed screen.

From a developer point of view: While the API itself works fine the client side implementation needs some work, if you want to use this as a new drop screen post battle you technically can't the client will get massive desync and be stuck on some battle camera limbo until they relog. The only work around for this for me was having a hook on the BattleGUIClose packet handler to fire off any drop screens I'd have queued. While this work around is okay it bars out less experienced developers that have no idea on how to override network handlers.
It also partially looses the purpose of using the API in the first place due to the concerns from a user side experience and the fact that if you know how to solve this issue you would just do your custom logic on the ServerItemDrop packet.
Also in the event it gets mentioned im aware theres an event for the Drops after the battle, adding items to this does not allow for custom implementations such as commands, custom logic, etc.

Thanks for checking this out, Licious

Big +1 on this, based on the numerous feedback we received from our community.

This should actually be intentional. some usages of the api may want the user to exit out of the screen.
For example, a plugin could open this gui in place of a chest and allow a player to select only the items they want and then to close the gui leaving the other drops for other players. Esc is a quick and easy way to close the drop menu and should be supported.
The better option here is to expand on the API and allow for the server to receive notice about the closer via another sub event, that way a plugin dev who doesn't want the player to be able to close the drop screen can simply reopen it forcing a player to chose an option.


That's a fault of opening any screen while the battle GUI is still open. and not a problem of the custom drops gui. Its a fault of the camera switching, all screens need to be delayed till after the battle gui has fully shutdown.


This is a stretch, it was not expressly created to literally replace the built in drops screen after battle, but to allow for grander usages. But none the less, we can add a switch into the battle drops screen to use the custom one instead and have all logic redirected to you.

I see the point behind allowing closing but would a boolean on the packet be possible?
The server side event could still be fired if false but it would make for a more coherent user experience if the screen doesn't closed only to be prompted again.

As for the battle UI needing to be closed im aware of this but my point was towards a server side notification being a part of the API, currently the only way to confirm this is by "hacking" our way into BattleGuiClosed although its easily managed in-house it does limit compatibility with external plugins.

Thank you for the feedback and sorry for the late reply.