Migrate from MCDR 1.x to 2.x

Migrating from MCDR 1.x to MCDR 2.x is easier than migrating from 0.x for most plugins. Some of the MCDR 1.x plugins can work as expected without any modification

Other than plugins, the permission / configuration parts of MCDR has no changes, so you can just continuously use your MCDR 1.x files

Plugin

The most changes between MCDR 1.x and MCDR 2.x is the plugin system

Metadata

You can no longer use RText instance as the value of your plugin metadata. name and description fields in RText class will be automatically converted into str for compatibility

This changes is to ensure the consistence between Solo Plugin (the plugin format before MCDR 2.x) and Multi file Plugin which use a .json file to declare their metadata

Event

There are several changes to plugin event about plugin lifecycle to make the lifecycle more complete

Plugin Removed event is removed
Plugin Unload event will be dispatched when MCDR stopped

With that the plugin lifecycle can be covered with 2 events, Plugin Loaded and Plugin Unloaded

Modules

Due to how MCDR 2.x plugin loading logic works, you can no longer places your external libs modules into your plugin/ folder and import them, since MCDR will not append the plugin folders into sys.path any more

For example, the following codes with the given files structure won’t work in MCDR 2.x, although it works in 1.x

plugins/
    my_lib/
        __init__.py
        my_tool.py
    my_plugin.py

# my_plugin.py
from my_lib import do_something

do_something()

To resolve this issue, you can reorganize your plugin file structure into the Multi file Plugin format and insert your lib your multi file plugin

ServerInterface

APIs used for plugin registry operation related to current plugin in ServerInterface class is now split to a derived class PluginServerInterface, other general MCDR control APIs are not affects

For example, these APIs are moved to PluginServerInterface

But these APIs are not affected

When invoking the event listener callback of you plugin, MCDR will send a PluginServerInterface as the first parameter, so the usability of the server interface API is not affected

These changes should not affect your plugin’s runnability, but it will probably mess up the type checking code inspect in your IDE to make the IDE displays a warning

Command

The original ArgumentNode class is now split into AbstractNode and ArgumentNode. Most of the functionalities are inside AbstractNode, but the name field is moved to ArgumentNode

For your custom command node classes, you might only need to change some related type hints