Overview of LSE Plugin Development

⛳ Start

LegacyScriptEngine, hereinafter referred to as LSE, is a plugin framework for Bedrock Dedicated Server (hereinafter referred to as BDS), the official server of Minecraft Bedrock Edition, providing powerful cross-language script plug-in support and stable development API support.

Welcome to LSE's plug-in development!

From here, you will gradually become familiar with the basic elements and processes of LSE plug-in development.

Before engaging with development, you need to have a systematic understanding of LSE. The documentation here, first of all, will help you establish a general knowledge framework. Familiarize yourself with them first, this will be a very important part of your learning development process.

💊 Data Types

As we all know, the type system is usually a more critical part of a design framework. So, first, you need to be familiar with several data types that you will use frequently when working with API documentation. The nouns of these data types appear frequently in the development documentation, so be sure to be familiar with them first.

Generic Data Type Conventions

Although scripting languages ​​are usually weakly typed, there is no need to pay attention to specific data types, but since LSE supports a variety of different scripting languages, in order to facilitate the docking of the API, some general data types and the mapping relationship to the corresponding scripting language types are defined below.

Any type in the documentation means that a value of any of the types above can be used.

In addition to the above standard types, there are also some engine-defined object types.

• IntPos - Integer coordinate object (see the base game interface for details)
• FloatPos - Floating point coordinate object (see the base game interface for details)
• Player - Player object (see Player for details) - class name actually registered in the engine: LLSE_Player
• Entity - Entity objects (see Entity for details) - class name actually registered in the engine: LLSE_Entity
• Block - Block objects (see Blocks for details) - class name actually registered in the engine: LLSE_Block
• BlockEntity - Block entity object (see Block entity for details) - class name actually registered in the engine: LLSE_BlockEntity
• Item - Inventory item object (see Items for details) - class name actually registered in the engine: LLSE_Item
• Device - Player equipment information object (see player for details) - class name actually registered in the engine: LLSE_Device
• Container - container object (see container for details) - class name actually registered in the engine: LLSE_Container
• Objective - Scored item object (see Scoreboard for details) - class name actually registered in the engine: LLSE_Objective
• Packet - Packet object (see Packet for details) - class name actually registered in the engine: LLSE_Packet
• NBT - NBT Tag object (see NBT for details)
• SimpleForm - Normal form objects (see Form Builder for details) - class name actually registered in the engine: LLSE_SimpleForm
• CustomForm - Custom form objects (see Form Builder for details) - class name actually registered in the engine: LLSE_CustomForm
• Conf - Configuration file object (see configuration file for details)
• DB - Database objects (see Database for details)
• File - File object (see file reading and writing for details)
• WSClient - WebSocket client object (see Network for details)
• Enum - Enumeration type, usually stored in some type, providing some limited range of options.

📌 API Documentation Description Conventions

As we all know, a good help document is naturally inseparable from a unified and concise format and a clear appearance. Therefore, in order to unify and standardize the format of the document, it is necessary to uniformly specify the description convention of LSE's help document.

For all the API documentation you see next, there are writing rules like this:

1. About the description of function parameter types in the documentation: Function parameters are described in the format Parameter Name : Parameter Type
   For example: cmd : String means a variable cmd of type String
   The parameter type Array<...>, represents an array/list containing the variables within <>.

2. About the description of optional parameters in the documentation:
   If optional parameters appears in the parameter descripton, it means that you have the option to not pass this parameter. When you do not pass this parameter, the engine will use the default value given in the description. In API signatures, optional parameters are enclosed in [ ]. For example: pl.tell(msg[,type]), where type is an optional parameter.

After you are familiar with the above infrastructure, you can start to read the documentation for each other specific content step by step. If you come across something you forgot, you can look it up more.

📜 Plugin Development Tips

Here, there are some suggestions when developing plugins, I hope they can help you

• Don't reinvent the wheel When possible, try to use libraries that have been written by others for specific functions, rather than writing each function yourself. In this way, it is conducive to the integration and development of the ecology.
• Think about the user When designing the interface and configuration, it is best to take the user's feelings into account. The content of external interaction such as UI and commands should be as clear and clear as possible, in line with normal usage habits.
• From multiple perspectives, innovation occurs
  Everyone is encouraged to learn from the excellent plugins already available in JE, and everyone is welcome to make their own innovations.

📡 Debug Plugins

You can type these commands to enter the corresponding debug mode:

• jsdebug: JavaScript debug mode
• nodejsdebug: Node.js debug mode
• luadebug: Lua debug mode
• pydebug: Python debug mode

In debug mode, all texts you type will be parsed as scripts and be executed in real time, as the console of developer tools of browsers do. If any error occurs, you will see an error report.

You can type the same command (jsdebug / nodejsdebug / luadebug / pydebug) and press Enter to exit the debug mode.