Last updated for: ade079827c0165ac5b943f4fecc0f6c7370b4c6c.

Download the Paperclip jar for this pull request: paper-12671.zip

repositories {
    maven("https://maven-prs.papermc.io/Paper/pr12671") {
        name = "Maven for PR #12671" // https://github.com/PaperMC/Paper/pull/12671
        mavenContent {
            includeModule("io.papermc.paper", "dev-bundle")
            includeModule("io.papermc.paper", "paper-api")
        }
    }
}

Something we need to decide is how to handle the "custom all" dialog action. This is the action that sends a full CompoundTag of all the input values back to the server using the new packet. Right now, there's no way to listen for these.

Do we just add an event for both config/game phase that includes the player its from, the id of the payload, and the BinaryTagHolder payload? Or do we do smth like adventure click callback provider?

Do we just add an event for both config/game phase that includes the player its from, the id of the payload, and the BinaryTagHolder payload? Or do we do smth like adventure click callback provider?

I personally would prefer to at least have an event if that allows listening to arbitrary dialogs too but a way to directly react on some form of callback directly from the code that creates the dialog in a plugin would be nice too but I feel the event would be more important. Ideally the data would be in a format that can be easily read e.g. a key -> value map instead of raw NBT.

Width and height range

There really should be org.jetbrains.annotations.Range annotations or javadoc comments stating that the width and height parameters should be at least 1 and max of whatever it is, most commonly it's 1024, but there are exceptions where it's less. For example the width and height parameters for DialogBody.ItemBody have a max value of 256.

These numbers are from the minecraft wiki.

Default values

One other thing I'd like to see is default values being used. So you don't have to specify width/height and use the default.

Ok, I pushed a super duper rough concept of the PlayerCustomClickEvent which includes 2 methods to extract a dialog response. One method takes the dialog instance, and tries to validate its inputs against the received payload, returning null if its not valid. Of course you should be making the payload ids super unique so you know its your dialog.

The other is a raw response wrapper with methods to just get any bool, float, or string in the top level of the response payload (if the response payload exists and is a compound tag).

And of course you can get a BinaryTagHolder and parse it into NBT using whatever library you want.

Ok, I added another approach. You can manually specify a callback that runs. Create it with DialogAction#customAll(Key, DialogActionCallback, ClickCallback$Options) and use it in the actions.

Ok, I added another approach. You can manually specify a callback that runs. Create it with DialogAction#customAll(Key, DialogActionCallback, ClickCallback$Options) and use it in the actions.

why even add a key, feels like this should just create a key internally

Yeah, I think you're right. Will remove.

I did not see a way to make a DialogAction close the dialog? Am I missing something or is that just not a thing? I'd be needed if you don't auto close it.

I know adventure will add a Audience#closeDialog but I'd feel like there should be a predefined DialogAction#close that removed the boiler plate of having do to a customClick

You don't have to specify any action. In say, a confirmation dialog, the dialog will follow the DialogAfterAction on any button click.