mojira.dev
MCPE-159185

Form not opening on chat event

In the Gametest Engine the chat is preventing forms from opening.

 

Steps to reproduce:

  1. listen on beforeChatEvent

  2. create a form for the sender of the message

  3. The chat is still open and prevents the form from opening

A boolean to close the chat window in the event would help Creators to prevent this bug and probably be helpful for other things too.

Comments 8

Hi, could you attach a video or a screenshot showing the issue?

This ticket will automatically reopen when you reply.

Hi,

here the link to a video that shows the bug.

https://www.dropbox.com/s/vjletm21482bvrr/Minecraft%202022-08-09%2011-40-41.mp4?dl=0

The form opens three seconds after the chat event (if the chat is closed).

Hi, thank you for the video.
Could you please also attach an example add-on to your report?

import * as UI from "mojang-minecraft-ui";
import { world } from 'mojang-minecraft';

world.events.beforeChat.subscribe((event)=>{
    form([{type:"textField"}],(result)=>{
        const obj={rawtext:[{
            text:JSON.stringify(result)
        }]};
        event.sender.runCommand(`tellraw @s ${JSON.stringify(obj)}`);
    }, event.sender);
})

export function form(data, onSubmit, playerData) {
    const form = new UI.ModalFormData();
    form.title("Form");
    for (let i = 0; i < data.length; i++) {
        const element = data[i];
        switch (element.type) {
            case "dropdown":
                form.dropdown(
                    element.label || "Dropdown",
                    element.hasOwnProperty("default") ? element.options : [...element.options].concat([""]),
                    element.hasOwnProperty("default") ? element.default : element.options.length
                );
                break;
            case "slider":
                form.slider(
                    element.label || "Slider",
                    element.hasOwnProperty("min") ? element.min : 0,
                    element.hasOwnProperty("max") ? element.max : 100,
                    element.hasOwnProperty("step") ? element.step : 1,
                    element.default
                )
                break;
            case "toggle":
                form.toggle(
                    element.label || "Toggle",
                    element.default || false,
                )
            case "textField":
                form.textField(
                    element.label || "Text Field",
                    element.default || ""
                )
                break;
            default:
                break;
        }
    }
    const promise = form.show(playerData);
    promise.then((result) => \{ if (!result.isCanceled) onSubmit(result) }, debug);
}

this example instantly triggers a form on any message

There is a new 'cancelationReason' property of the ModalFormResponse class (and other script UIs) that can be used to determine whether the form was canceled (by the player or active chat window). To use this, there's a required change in the manifest file: version of the dependent modules (mojang-minecraft, mojang-minecraft-UI and so on) need to be changed from [0, 1, 0] to "1.0.0-beta". For more details please see the official documentation here: https://docs.microsoft.com/en-us/minecraft/creator/scriptapi/mojang-minecraft-ui/modalformresponse

Here's an example of how it can be used:

async function promptUI(player) {
  //create the custom UI
  const ui = new ModalFormData()
    .title(`title`)
    .toggle(`toggle`)
    .slider(`slider`, 0, 10, 1);
  //show the settings UI to the player
  const playerResponse = await ui.show(player);
  //if player is busy (has some other screen currently open), retry
  if (playerResponse.cancelationReason == `userBusy`) {
    promptUI(player);
    return;
  }
}

Please let us know if using the new property fixes the issue. This ticket will reopen automatically when you reply.

 

No, the new property does not fix the issue. I already built a workaround that detects the possible reasons and restarts the form if necessary. As I said an option to close open windows would fix the issue.

Is this still an issue in the latest version? If yes, can you please add it to the affected versions (or mention it if you are not the reporter)?

This ticket will automatically reopen when you reply.

Maximilian Ewald

(Unassigned)

Unconfirmed

Multiple

1.19.10

Retrieved