Bedrock Edition beta scripting documentation

This is the scripting documentation for Bedrock Edition beta 1.13.0.5. New features, components, and capabilities in this release are not final and might change without notice before the final release (1.13.0). Be sure to check the documentation once the release is out of beta if the add-on isn't working properly. Resource and behavior packs created for the beta are not guaranteed to work on the final release.

Scripting system
The Minecraft Script Engine uses the JavaScript language. You can write JavaScript scripts and bundle them with Behavior Packs to listen and respond to game events, get and modify data in components that entities have, and affect different parts of the game.

Demos
Here are some demos to help you get started with scripting. Unzip them to check out the code, or import them as a to play with them

Known Issues
This is the list of currently known issues with the Minecraft Script Engine

Breaking changes
While we continue to work and refine the experimental Scripting API we might need to make changes that break your current scripts. Please check this section if your scripts aren't working as expected.

Prerequisites
This section lists minimum and recommended software you need to make your own scripts. NOTE: Scripts are only supported on Windows 10 PCs at the moment. If you try to open a world with scripts on a device that doesn't support scripts, you see an error message letting you know you can't enter the world.

Getting started
First you need to download the latest Vanilla Behavior Pack. You can get this from the following link: https://aka.ms/behaviorpacktemplate Once you have downloaded the Behavior Pack, unzip it to a folder. Inside the Behavior Pack is the scripts folder which contains all the scripting files you want to run. In the scripts folder are two folders: one for client scripts and one for server scripts. Once you have chosen whether you are making a client or server script, simply add a new blank text file with .js extension to the appropriate folder, and open it in your preferred code editor. Then code away! You can have as many or as few JavaScript files as you want here (the name of the files doesn't matter) and they all run independently of each other!
 * Server Scripts: These scripts run on the server side of the game. This includes spawning new entities, adding components, or modifying components on an entity.
 * Client Scripts: These scripts run on each individual player's side of the game. This is a good place to respond to events and manage anything specific to the player.

Once you have finished making changes and wish to test the script in game, compress the file to .zip format then change the extension from ".zip" to ".mcpack". Double click on the .mcpack file to import it into Minecraft. Make a world and activate the pack in your world to test it. https://www.minecraft.net/en-us/addons/

NOTE: For scripts to be run by the game, you need to enable Experimental Gameplay on the world where scripts are run. This is necessary while scripting is still in beta. When entering a world that has client scripts in it, you are prompted to accept that you wish to run scripts on your device (this appears both for local worlds as well as multiplayer worlds). Additionally, if your pack contains client scripts, you need to include a client_data module in the pack's manifest. This tells the game anything in the scripts/client folder needs to be sent over to the clients. Please refer to the Add-on Documentation page for more information on the pack's manifest contents.


 * Folder structure


 * Example of manifest module needed for client scripts


 * vanilla_behavior_pack

root folder /scripts /client > myClientScript.js        /server > myServerScript.js   > manifest.json > pack_icon.png

Structure of a script
In this section you can find a quick description of the basic structure of a JavaScript script file for the Minecraft Script Engine. If you would like to learn more about JavaScript or want to follow a fundamentals tutorial, you can check the official documentation on the Mozilla Developer Network here: https://developer.mozilla.org/docs/Web/JavaScript These are, in a way, the required parts of a script but they are by no means the only parts you can have. You can create additional methods as needed - just make sure they are called from somewhere in one of the methods below!

1. System registration
First off we need to register the system for our file. This signs up our script to be set-up either on the client or server threads of the game. Generally speaking, you choose based on whether you put the script file in the client or server folders. To do that simply call registerSystem on either the client or server and give it the version of the API you require.


 * Parameters


 * Code examples:


 * Client system


 * Server system

2. System initialization
This is the first method that gets called immediately after the system is registered. It runs as soon as the script loads at world start. You can use this to set up the environment for your script: register custom components and events, sign up event listeners, etc. This runs before the world is ready and the player has been added to it. This function should be used to initialize variables and setup event listeners. You shouldn't try to spawn or interact with any entities at this point! You should also avoid interaction with UI elements or sending messages to the chat window since this is called before the player is ready.


 * Code example:

3. System update
This method gets called once every game tick. The server and client tick at 20 times per second. This is a good place to get, check, and react to component changes.


 * Code example:

4. System shutdown
This method gets called when the Minecraft Script Engine is shutting down. For the client this is when they leave the world; for the server this is after the last player has exited the world.


 * Code example:

Debugging
Your script isn't working or doing what you want it to do? Fret not! We have built some debugging capabilities into the Script Engine to help you figure out what's going on with your script. If you are new to programming or want to learn more about debugging we suggest checking out the documentation about debugging with Visual Studio available here: https://docs.microsoft.com/visualstudio/debugger

There are two ways to tell what happened when something goes wrong with a script: in-game and advanced, which we will describe below. You only need the game and your script to debug in-game, but you will need a Windows 10 PC and Visual Studio installed for the advanced debugging.

In-game
When running a script in-game, the game will automatically print out the message "Something went wrong..." upon reaching an error. You can enable much more descriptive debugging information to be printed to the chat by sending a minecraft:script_logger_config event in the script's System.initialize hook: When you run the script in the game, the Script Engine prints out error messages whenever something goes wrong. For example, if you try to get a component that the script engine doesn't know about, you get an error. To look at these messages you can open the chat screen which has all the generated error messages there; or you can open the log file that the game generated. The location of the log file varies by platform. On Windows 10 you can find the log file in  We strongly encourage you to build further debug messages and tools into your scripts while working on them. This helps you discern when something isn't working quite right. Reach out on the official Discord channel if you need additional help: https://discord.gg/Minecraft

Real-time (advanced)
If you have a Windows 10 PC with Visual Studio installed, you can attach the Visual Studio debugger and debug your script in real-time.

If you installed Visual Studio with the components mentioned in the "Recommended" section of this document you will have installed and enabled the Just-In-Time Debugger. This tool pops up a message from Visual Studio whenever an exception occurs in your script and allow you to open Visual Studio on the line of your script that broke.

Additionally, you can connect to the Script Engine manually and debug your code. You can use remote debugging to connect and debug Minecraft running on another device. Please refer to the Visual Studio Debugger documentation above for instructions on how to use remote debugging.

First you need to start up Visual Studio. If this is the first time you have launched Visual Studio after installation, we suggest setting up your environment for JavaScript development and logging in to your Microsoft account when prompted. This will set up the Visual Studio interface with the most important tools you will need.

Once you have Visual Studio open you should launch Minecraft. Then create a new world with Experimental Gameplay enabled and apply the Behavior Pack containing your scripts.

After creating the world go back to Visual Studio and click on the Debug menu. Then click on "Attach to Process". In the window that opens there will be a search box titled Filter Process. Click on it and type Minecraft.

Once the list is narrowed down to only the instance of Minecraft running, you can verify that the Script Engine is running by looking at the Type column. This will say Script and either x86 or x64.

Select the process and click on Attach to attach the debugger to the game. Now you can press the Pause button to pause the Script Engine when the next line of script code runs. This allows you to inspect the values of variables in your script and break into Visual Studio if an error occurs in your code.

WARNING: When you hit a breakpoint to step through code with a debugger, it is possible for a client to time out and disconnect or for the server to disconnect all players.

Script API objects
Here you can find the definition of some objects returned by the script API.

Ticking area JS API object
There are two types of ticking area objects. Entity and Level. When a function calls for a ticking area it can take either type as an argument.

Script bindings
Bindings are the capabilities of the Minecraft Script Engine to change or modify things in the game.

createEntity
Creates an empty entity with no components and does not place it in the world. The empty entity will be of type custom and have a blank identifier. This is NOT a valid entity that exists in the world, just an empty one that only scripts know about.

NOTE: Entities are created first on the server, with the client notified of new entities afterward. Be aware that if you send the result object to the client right away, the created entity might not exist on the client yet.


 * Return value

createEntity(Type, TemplateIdentifier)
Creates an entity and applies the specified template as defined in JSON. This allows you to quickly create an entity from the applied Behavior Packs as the base for an entity created in scripting. The entity will be spawned into the world with all the components, component groups, and event triggers that are defined in the JSON file of the identifier specified. Only works on scripts registered on the server.

NOTE: Entities are created first on the server, with the client notified of new entities afterward. Be aware that if you send the result object to the client right away, the created entity might not exist on the client yet.


 * Parameters


 * Return value

destroyEntity(EntityObject)
Destroys an entity identified by the EntityObject. If the entity exists in the world this removes it from the world and destroy it. This also makes the EntityObject no longer valid - you should only destroy an entity after you are done with it and no longer need to reference it again. This does NOT kill the entity. There isn't an event for its death: it is removed.


 * Parameters


 * Return value

isValidEntity(EntityObject)
Checks if the given EntityObject corresponds to a valid entity.


 * Parameters


 * Return value

registerComponent(ComponentIdentifier, ComponentData)
Creates a custom component that only exists in script. It can be then added, removed, and updated from entities. These custom components only exist while the Script Engine is running.


 * Parameters


 * Return value

createComponent(EntityObject, ComponentIdentifier)
Creates the specified component and adds it to the entity. This should only be used with custom components which need to be registered first. If the entity already has the component, this retrieves the component already there instead.


 * Parameters


 * Return value

hasComponent(EntityObject, ComponentIdentifier)
Checks if the given entity has the specified component.


 * Parameters


 * Return value

getComponent(EntityObject, ComponentIdentifier)
Looks for the specified component in the entity. If it exists, retrieves the data from the component and returns it.


 * Parameters


 * Return value

applyComponentChanges(EntityObject, ComponentObject)
Applies the component and any changes made to it in script back to the entity. What this means for each component can be slightly different: it makes the component reload on the entity with the new data as if it had just been added to the entity.


 * Parameters


 * Return value

destroyComponent(EntityObject, ComponentIdentifier)
Removes the specified component from the given entity. If the entity has the component, it is removed. Currently this only works with custom components and can't be used to remove components defined for an entity in JSON.


 * Parameters


 * Return value

Event bindings
These are the bindings used to handle events. For a list of events you can react to or trigger, check the Events section of this document.

registerEventData(EventIdentifier, EventData)
Registers the Event to the script engine. This allows you to create Event Data by calling createEventData and have it initialized with the correct default data and fields. Only custom events need to be registered.


 * Parameters


 * Return Value

createEventData(EventIdentifier)
Creates an object with all the required fields and default data for the specified event. If the event is a custom event, it needs to have been previously registered.


 * Parameters


 * Return value

listenForEvent(EventIdentifier, CallbackObject)
Allows you to register a JavaScript object that gets called whenever the specified event is broadcast. The event can either be a built-in event or an event specified in script.


 * Parameters


 * Return value

broadcastEvent(EventIdentifier, EventData)
Allows you to trigger an event with the desired data from script. Anything that signed up to listen for the event will be notified and the given data delivered to them.


 * Parameters


 * Return value

Entity queries
Entity Queries are a way for you to filter for entities based on their components. Once you have registered a query, you can request all the entities that are captured by it. Entity Queries only ever return entities that are currently active in the level. If your query extends into chunks that are not currently loaded, entities there are not included in the query.

registerQuery
Allows you to register a query. A query contains all entities that meet the filter requirement. No filters are added by default when you register a query so it captures all entities.


 * Return value


 * Code example:


 * Query Registration

registerQuery(Component, ComponentField1, ComponentField2, ComponentField3)
Allows you to register a query that will only show entities that have the given component and define which fields of that component will be used as a filter when getting the entities from the query. You can either provide just the component identifier, or the component identifier and the name of 3 properties on that component to be tested (If you do specify property names, you must specify 3).


 * Parameters


 * Return value


 * Code Example:


 * Query Registration

addFilterToQuery(Query, ComponentIdentifier)
By default no filters are added. This allows queries to capture all entities.


 * Parameters


 * Code Example:


 * Query Filtering

getEntitiesFromQuery(Query)
Allows you to fetch the entities captured by a query.


 * Parameters


 * Return value


 * Code Example:


 * Entity Fetching

getEntitiesFromQuery(Query, ComponentField1_Min, ComponentField2_Min, ComponentField3_Min, ComponentField1_Max, ComponentField2_Max, ComponentField3_Max)
Allows you to fetch the entities captured by a query that was created with a component filter built-in. The only entities that will be returned are those entities that have the component that was defined when the query was registered and that have a value in the three fields on that component that were defined in the query within the values specified in the call to getEntitiesFromQuery.


 * Parameters


 * Return value


 * Code Example:


 * Entity Fetching

Slash Commands
You can use the traditional Slash Command system from scripts. Currently you can either trigger an event ("minecraft:execute_command") or use the executeCommand binding. Commands in scripts are restricted to server scripts, they can't be run from the client's side at the moment.

executeCommand(Command, Callback)
Allows you to execute a Slash Command on the server. The command will be queried and executed at the end of the current frame. All data output from the command will be compiled on a JavaScript Object and sent to the Callback object specified in the second parameter.


 * Parameters


 * Example

Block Bindings
These functions define how you interact with blocks.

getBlock(Ticking Area, x, y, z)
Allows you to get a block from the world when provided an x, y, and z position. The block must be within a ticking area.


 * Parameters


 * Return value

getBlock(Ticking Area, PositionObject)
Allows you to get a block from the world when provided a JavaScript object containing a position. The block must be within a ticking area.

Parameters


 * Return value

getBlocks(Ticking Area, x min, y min, z min, x max, y max, z max)
Allows you to get an array of blocks from the world when provided a minimum and maximum x, y, and z position. The blocks must be within a ticking area.


 * Parameters


 * Return Value

getBlocks(Ticking Area, Minimum PositionObject, Maximum PositionObject)
Allows you to get an array of blocks from the world when provided a minimum and maximum position. The blocks must be within a ticking area.


 * Parameters

{| class="wikitable" ! Type !! Name !! Description Parameters
 * Ticking Area JS API Object
 * Ticking Area
 * The ticking area the blocks are in
 * JavaScript Object
 * Minimum PositionObject
 * A JavaScript object with the minimum x, y, and z position of the blocks you want
 * Minimum PositionObject
 * A JavaScript object with the minimum x, y, and z position of the blocks you want


 * JavaScript Object
 * Maximum PositionObject
 * A JavaScript object with the maximum x, y, and z position of the blocks you want
 * A JavaScript object with the maximum x, y, and z position of the blocks you want


 * Parameters


 * }


 * Return value

Script components
This is the documentation for the attributes, properties, and components available from the Minecraft Script Engine.

There are two kinds of components: server components and client components. The sections below go into more detail.

Components can be added, retrieved, updated, and removed from entities. They do not exist on their own. Currently only user-defined components can be added and removed from entities. A component must be in an entity in order to retrieve or update it.

Check the Script Engine Bindings section to see how to add, remove, retrieve, and update components. This section deals with the specific API of each component.

Level components
These are the components that belong to the level. They can only belong on the level object and cannot be removed from it. You can get the components and change their data through the global server object.

minecraft:ticking_areas
This component gives access to the static ticking areas in the level. The component contains an array of ticking areas. The ticking areas can be accessed by name or by UUID if they were not given a name.

minecraft:weather
The weather component allows users to change the level's weather. Rain and lightning levels can be changed independently and the default weather cycle can be turned off completely.


 * Parameters

Server components
These are the components that run on the server and are synced with all the clients (players) in the world. As much as possible, the API of each component matches its JSON counterpart (with some differences noted).

minecraft:armor_container
This component represents the armor contents of an entity. The component contains an array of ItemStack JS API Objects representing each slot in the armor container.

NOTE: Currently items and containers are read-only. Slots are ordered from head to feet.

minecraft:attack
This component controls the Attack Damage attribute from the entity. It allows you to change the current minimum and maximum values. Once the changes are applied, the current attack of the entity will be reset to the minimum specified. With the minimum and maximum changed to the values specified. Any buffs or debuffs will be left intact.


 * Parameters

minecraft:collision_box
Controls the collision box of the entity. When changes to the component are applied the entity's collision box is immediately updated to reflect the new dimensions.

WARNING: If the change of the collision box dimensions would cause the entity to be inside a block, the entity might become stuck there and start suffocating.


 * Parameters

minecraft:damage_sensor
Defines an array of damages and how the entity reacts to them - including whether the entity ignores that damage or not. Currently Minecraft triggers can't be properly serialized so any existing triggers will be completely replaced when applyComponentChanges.


 * Parameters

minecraft:equipment
Defines the loot table the entity uses to defines its equipment. Once the changes are applied, the equipment is re-rolled and a new set of equipment is chosen for the entity.


 * Parameters

minecraft:equippable
Defines how many and what items the entity can be equipped with.

slots

List of slots and the item that can be equipped.


 * Parameters

minecraft:explode
Controls the entity's explosion, timer until the explosion, and whether the timer is counting down or not.


 * Parameters

minecraft:hand_container
This component represents the contents of an entity's hands. The component contains an array of ItemStack JS API Objects representing each slot in the hand container.

Note: Currently items and containers are read-only. Slot 0 is main-hand Slot 1 is off-hand.

minecraft:healable
Defines how the entity can be healed by the player. This doesn't control how much health the entity can have; you must use the Health component for that instead.


 * Parameters

minecraft:health
Defines the current and maximum possible health of the entity. Upon applying the component back to the entity, the health changes. If it reaches 0 or below, the entity dies.


 * Parameters

minecraft:hotbar_container
This component represents the hotbar contents of a player. The component contains an array of ItemStack JS API Objects representing each slot in the hotbar.

NOTE: Currently items and containers are read-only. Slots are ordered left to right.

minecraft:interact
Defines the ways the player can interact with the entity to which this component is applied.


 * Parameters

{| class="wikitable" ! Type !! Name !! Default Value !! Description
 * Array
 * spawn_entities
 * An array of entity identifiers to spawn when the interaction occurs
 * String
 * on_interact
 * An event identifier to fire when the interaction occurs
 * JSON Object
 * particle_on_start
 * Particle effect that will be triggered at the start of the interaction
 * An event identifier to fire when the interaction occurs
 * JSON Object
 * particle_on_start
 * Particle effect that will be triggered at the start of the interaction
 * Particle effect that will be triggered at the start of the interaction
 * Particle effect that will be triggered at the start of the interaction


 * Parameters


 * Decimal
 * cooldown
 * 0.0
 * Time in seconds before this entity can be interacted with again
 * Boolean
 * swing
 * false
 * If true, the player will do the 'swing' animation when interacting with this entity
 * Boolean
 * use_item
 * false
 * If true, the interaction will use an item
 * Integer
 * hurt_item
 * 0
 * The amount of damage the item will take when used to interact with this entity. A value of 0 means the item won't lose durability
 * String
 * interact_text
 * Text to show when the player is able to interact in this way with this entity when playing with Touch-screen controls
 * JSON Object
 * add_items
 * Loot table with items to add to the player's inventory upon successful interaction
 * Parameters
 * Text to show when the player is able to interact in this way with this entity when playing with Touch-screen controls
 * JSON Object
 * add_items
 * Loot table with items to add to the player's inventory upon successful interaction
 * Parameters
 * Loot table with items to add to the player's inventory upon successful interaction
 * Parameters
 * Parameters


 * JSON Object
 * spawn_items
 * Loot table with items to drop on the ground upon successful interaction
 * Loot table with items to drop on the ground upon successful interaction
 * Loot table with items to drop on the ground upon successful interaction


 * Parameters


 * String
 * transform_to_item
 * The item used will transform to this item upon successful interaction. Format: itemName:auxValue
 * Array
 * play_sounds
 * An array of sound identifiers to play when the interaction occurs
 * }
 * play_sounds
 * An array of sound identifiers to play when the interaction occurs
 * }
 * }

minecraft:inventory
Defines the entity's inventory (size, restrictions, etc.). Currently this does not allow changing the entity's inventory contents.


 * Parameters

minecraft:inventory_container
This component represents the inventory contents of an entity. The component contains an array of ItemStack JS API Objects representing each slot in the inventory. NOTE: Currently items and containers are read-only.Slot 0-8 is the hotbar, 9-17 is the top row of the player's inventory, 18-26 is the middle row, 27-35 is the bottom row

minecraft:lookat
Makes the entity look at another entity. Once applied, if an entity of the specified type is nearby and can be targeted the entity will turn toward it.


 * Parameters

minecraft:nameable
Nameable component describes an entity's ability to be named using a nametag and whether the name shows up or not once applied. Additionally, scripting allows setting the name of the entity directly with the property 'name'.


 * Parameters

minecraft:position
This component allows you to control an entity's current position in the world. Once applied the entity will be teleported to the new position specified.


 * Parameters

minecraft:rotation
This component allows you to control an entity's current rotation in the world as well as the entity's head rotation. Once applied, the entity will be rotated as specified.


 * Parameters

minecraft:shooter
Defines the entity's ranged attacks. This doesn't allow the entity to use a ranged attack: it only defines what kind of projectile it shoots.


 * Parameters

minecraft:spawn_entity
Controls the entity's ability to spawn an entity or an item. This is similar to the chicken's ability to lay eggs after a set amount of time.


 * Parameters

minecraft:teleport
This controls the entity's ability to teleport itself (similar to the Enderman). If you wish to teleport the entity once use the Position component instead.


 * Parameters

minecraft:tick_world
The tick world component is a read-only component that allows users to access the ticking areas on entities as well as the ticking area's data.


 * Parameters

Client components
These components only run on the client where the script ran and can only be used from client scripts.

minecraft:molang
The MoLang component gives access to the MoLang variables in an entity. To learn more about MoLang varibles review the add-on documentation. In scripts, you can get and set these varibles that are defined in the entity's JSON files. Because of how the MoLang variables are formatted (variable.isgrazing for example) you must use the [] operator on the object to access the variable. The example below shows how to use the [] operator to access the variable.


 * Code example:

Block components
These components are only found on block objects and can only be on block objects

minecraft:blockstate
This component contains all the blockstates on a block object. Blockstates control all different aspects of blocks from their orientation to the type of wood they are. Blockstates are represented by numbers, bools, or strings. Please see the Blockstates Documentation to see the valid values for each state. This component allows for the getting and setting of these states.


 * Code Example:

User-defined components
User-defined components are a special kind of component that can be defined in script and no built-in game system acts on it.

The component needs to be registered with the Script Engine by giving it a name and a set of fields in the format name:value. Once applied, the component behaves like any of the built-in components: you can get it from an entity, modify its values, and apply the changes.

Currently User-defined components are the only components that can be dynamically added and removed from an entity using scripts. They don't need to be previously defined in an entity's JSON file. In the current version these components are not saved out or loaded back in: they exist only while the entity is there and need to be added back when reloading the level.


 * Code example:


 * Component Registration

Script events
Here you can find the list of events that you can listen for and respond to in your scripts.

Listening events
The following Minecraft events are events the Script Engine is listening for and to which you can react in scripts.

minecraft:client_entered_world
This event is fired whenever a player joins the world.

minecraft:hit_result_changed
This event is triggered whenever the reticle changes from pointing at a block or air to pointing at an entity and the other way around. Up to 1000 blocks away.

minecraft:hit_result_continuous
This event is triggered every update and tells you what entity the reticle is pointing to in the world up to 1000 blocks away.

minecraft:pick_hit_result_changed
This event is triggered whenever the mouse pointer changes from pointing at a block or air to pointing at an entity and the other way around. Up to 1000 blocks away.

minecraft:pick_hit_result_continuous
This event is triggered every update and tells you what entity the mouse pointer is pointing to in the world up to 1000 blocks away.

Trigger-able Events
The following Minecraft Events can be triggered from scripting and cause the game to respond accordingly.

minecraft:display_chat_event
This event is used to display a chat message to the specific player that is running the client script. The event data is the message to be displayed in plain text. Special formatting is supported the same way it would be if a player was sending the message.

minecraft:load_ui
This event is used to show a UI screen to the specific player running the client script. This event adds the UI screen to the top of the UI screen stack. The screen is shown immediately after the event is triggered. Only screens defined in a HTML file can be shown using this event.


 * Event Data Parameters

minecraft:send_ui_event
This event is used to send UI events to the UI Engine for the specific player running the script. After the event is triggered, the UI event will be sent immediately. Custom UI is based on HTML 5. Review the scripting demo for an example of a custom UI file.

minecraft:spawn_particle_attached_entity
This event is used to create a particle effect that will follow an entity around. This particle effect is only visible to the specific player that is running the client script where you fired the event. Any effect defined in a JSON file (both in your resource pack and in Minecraft) can be used here. MoLang variables defined in the JSON of the effect can then be used to control that effect by changing them in the entity to which it is attached.

minecraft:spawn_particle_in_world
This event is used to create a static particle effect in the world. This particle effect is only visible to the specific player that is running the client script where you fired the event. Any effect defined in a JSON file (both in your resource pack and in Minecraft) can be used here. Once the effect is spawned you won't be able to control it further. Unlike the server version of the event, the client version will spawn the particle in the dimension the player is currently in.

minecraft:unload_ui
This event is used to remove a UI screen from the stack of the specific player running the client script. The event data contains the name of the screen to remove as a string. After the event is triggered the screen will be scheduled to be removed from the stack the next time the UI Engine can do so. Only screens defined in a HTML file can be removed using this event.

minecraft:script_logger_config
This event is used to turn various levels of logging on and off for client scripts. Note that turning logging on/off is not limited to the script that broadcasted the event. It will affect ALL client scripts including those in other Behavior Packs that are applied to the world. See the Debugging section for more information on logging.

Listening events
The following Minecraft events are events the Script Engine is listening for and to which you can react in scripts.

minecraft:player_attacked_entity
This event is triggered whenever a player attacks an entity.

minecraft:entity_acquired_item
This event is triggered whenever an entity acquires an item.

minecraft:entity_carried_item_changed
This event is triggered whenever an entity changes the item carried in their hand.

minecraft:entity_created
This event is triggered whenever an entity is added to the world.

minecraft:entity_death
This event is triggered whenever an entity dies. This won't be triggered when an entity is removed (such as when using destroyEntity).

minecraft:entity_dropped_item
This event is triggered whenever an entity drops an item.

minecraft:entity_equipped_armor
This event is triggered whenever an entity equips an item in their armor slots.

minecraft:entity_start_riding
This event is triggered whenever an entity becomes a rider on another entity.

minecraft:entity_stop_riding
This event is triggered whenever an entity stops riding another entity.

minecraft:entity_tick
This event is triggered whenever an entity is ticked. This event does not fire when a player is ticked.

minecraft:entity_use_item
This event is triggered whenever an entity uses an item.

minecraft:block_destruction_started
This event is triggered whenever a player starts to destroy a block.

minecraft:block_destruction_stopped
This event is triggered whenever a player stops destroying a block.

minecraft:block_interacted_with
This event is triggered whenever a player interacts with a block.

minecraft:piston_moved_block
This event is triggered whenever a piston moves a block.

minecraft:player_destroyed_block
This event is triggered whenever a player destroys a block.

minecraft:player_placed_block
This event is triggered whenever a player places a block.

minecraft:play_sound
This event is used to play a sound effect. Currently, sounds can only be played at a fixed position in the world. Global sounds and sounds played by an entity will be supported in a later update.

minecraft:weather_changed
This event is triggered whenever the weather changes. It contains information about the weather it is changing to.

Trigger-able events
The following Minecraft events can be triggered from scripting and the game responds, accordingly.

minecraft:display_chat_event
This event is used to send a chat message from the server to the players. The event data's message is sent as a string. Special formatting is supported the same way it would be if a player was sending the message.

minecraft:execute_command
This event is used to execute a slash command on the server with the World Owner permission level. The event data contains the slash command as a string. The slash command will be processed and will run after the event is sent.

minecraft:play_sound
This event is used to play a sound effect. Currently, sounds can only be played at a fixed position in the world. Global sounds and sounds played by an entity will be supported in a later update.

minecraft:spawn_particle_attached_entity
This event is used to create a particle effect that will follow an entity around. This particle effect is visible to all players. Any effect defined in a JSON file (both in your resource pack and in Minecraft) can be used here. MoLang variables defined in the JSON of the effect can then be used to control that effect by changing them in the entity to which it is attached.

minecraft:spawn_particle_in_world
This event is used to create a static particle effect in the world. This particle effect is visible to all players. Any effect defined in a JSON file (both in your resource pack and in Minecraft) can be used here. Once the effect is spawned you won't be able to control it further.

minecraft:script_logger_config
This event is used to turn various levels of logging on and off for server scripts. Note that turning logging on/off is not limited to the script that broadcasted the event. It will affect ALL server scripts including those in other Behavior Packs that are applied to the world. See the Debugging section for more information on logging.

基岩版beta脚本文档