Tutorial Simple Guidelines for porting plugins from AmaiBeetroot to ZekkouCake

Now you have a plugin in AmaiBeetroot. The following guidelines can help you change it into a ZekkouCake plugin.

1. Create a plugin folder of your plugin name.
2. Create file "plugin.yml" in your plugin folder.
3. In /plugin.yml, write these:
   1. Name. It is necessary for a plugin. Write "name: ThisIsMyPluginName" on the first line
   2. API version. This tutorial is for API 1.0.0 so write "api: [1.0.0]" on the next line
   3. Plugin version. Use your favoured version code name. E.g. "version: 1.0.0"
   4. Load order. It can be either "STARTUP" or "POSTWORLD". If you don't strictly need STARTUP, use POSTWORLD. E.g. "load: POSTWORLD"
   5. Main class name. This class name is same as the old API one. However, note that plugin developers are encouraged/required to use namespaces in their plugins. Therefore, an example is "main: pemapmodder\exampleplugin\Main"
   6. The following are optional attributes:
      1. Author(s). If there is only one author, use "author: YourName". If there are multiple, use "authors: [MyName, YourName, HisName]". If you don't want to it are too lazy to specify the author, just skip this line.
      2. Website. The key is "website".
      3. Prefix. If left rmpty, it will be your plugin name. Prefix will be used if you use $this->getLogger()->log($msg) when you console.
      4. Dependencies. If your plugin requires another plugin to work with, name them. E.g. "depend: [SimpleAuth, PocketFactions]"
      5. Soft dependencies. If the plugin is not strictly required but it is better that it is there, use soft dependencies. E.g. "softdepend: [xEcon]'
4. Create folder /src/ in your plugin folder.
5. Create subfolders as your namespace like on java packages. E.g. if your namespace is pemapmodder\egplugin, create folders to /src/pemapmodder/egplugin/.
6. Create a file according to your class name in the namespace. E.g. if your main class is pemapmodder\egplugin\Main, create file "/src/pemapmodder/egplugin/Main.php". Note that in the new API, with the SPL class loader, classes must be placed according to their namespaces and names in order to be loaded, unless you are doing the discouraged way of all classes in one file.
7. Now, copy all your code in the old API plugin into the new one. The /*__PocketMine a plugin__ ...*/ thing can be omitted since they will be ignored. PocketMine-MP will only load those at "plugin.yml".
8. After <?php:
   1. Add line "namespace your\namespace;".
   2. Add line "use pocketmine\plugin\PluginBase;
   3. Replace "implements Plugin" with "extends PluginBase".
9. Add namespace class references at the beginning, e.g. "use pocketmine\Player;". The references can be found at the documentation.
10. Replace the initialization:
    1. __construct(ServerAPI $api, $server=false): remove it
    2. init(): change it to onEnable().
    3. Commands. For $this->api->console->register("cmd", "<usage>description", array($this, "onCommand"); and $this->api->console->alias("c", "cmd");:
       1. Use code method:
          1. Instantiate a new object of pocketmine\command\PluginCommand: $cmd = new PluginCommand("cmd", $this); where $this must be the plugin object.
          2. Set the description, usage and aliases: $cmd->setDescription("description"), $cmd->setUsage("/cmd <usage>"), $cmd->setAliases(array("c")
          3. Handle the command at onCommand(pocketmine\command\CommandSender $issuer, Command $cmd, $label, array $args) where the command name can be given by $cmd->getName(), and $sender can be an instance of pocketmine\Player or pocketmine\command\ConsoleCommandSender (or RCon, class pocketmine\command\RemoteConsoleCommandSender, subclass of pocketmine\command\ConsoleCommandSender.
          4. Use $issuer->sendMessage() instead of returning a string to send a message.
          5. Return a Boolean (true or false) value. If true nothing will happen. If false a usage information will be sent to the issuer.
       2. Use plugin.yml
          1. Add new key commands. "commands" is an array with string keys (a map as in YAML terms)
          2. Add a new element in the array. The key is the command name. The value is another string key array (map).
          3. For description, usage and aliases, add them with the values you add in method 1. E.g. " aliases: [c]
          4. Handle the command at onCommand()
       3. Create a subclass of PluginCommand or Command+PluginIdentifyableConmand.
    4. Events.
       1. Find the class name of the event you want to handle. Find them at https://github.com/PocketMine/PocketMine-MP/blob/Core-Rewrite/src/pocketmine/event where usually the events are located in the subdirectories in the link.
       2. Create functions of any name. Each function must only have one parameter. The parameter must have a type hint of the event class.
       3. Add your code to handle the events inside the functions.
       4. Add this line in onEnable(): $this->getServer()->getPluginManager()->registerEvents($this, $this);
    5. Scheduling
       1. Create a new class that extends pocketmine\scheduler\PluginTask.
       2. In the constructor of the class, add line "parent::__construct($plugin);", where $plugin is an instance of your plugin. You can get the plugin instance using Server::getInstance()->getPluginManager()->getPlugin("PluginName").
       3. Add the code to run in function onRun($ticks).
       4. Schedule the task to be run using $this->getServer()->getScheduler()->scheduleDelayedTask($task, $delayTicks)|scheduleRepeatingTask($task, $interval).
    6. Use onDisable() instead of __destruct().
    7. Replace $playet->entity with $player directly!
    8. Replace $player->addItem(), $player->setSlot() and other inventory-related methods with $player->getInventory()->...()
11. Replace $player->sendChat() with $player->sendMessage().
12. Replace $this->api->... methods with correct function names. Common usages are $this->getServer()->getPlayer() and $this->getServer()->getLevel().
13. Use DevTools with FolderPluginLoader enabled to test your plugins.
14. Compile your plugin by using command /makeplugin of DevTools and distribute/release your plugin in the compiled .phar file.

I'll add permission later since I need to look more into the code.

So... Many... Words...

lol a lot of steps

Well... I totally forgot about updating your plugin! Sorry, but I'm busy! But I've started the basic things you need, you just need to look at $plauer->getInventory()->setItem($slot, $item);

:O Wow I just read this a little more and I had no idea some of this stuff was added.

Great work as usual @PEMapModder

Ok I'll look into it

Added 10.7 and 10.8

way way way too complected

Yes but its worth it in the end.

It would be great if someone created a plugin porter.

I'm thinking about one since these guidelines are quite computer-executable enough

What about writing and reading YAML config files? Is that the same?

No its not. You have to create a "sample" config.yml and then get the resource (i belive its $this->getResource("config.yml"); ) or something like that.

So like:

PHP:

$config = new Config(path\to\desiredspot\name.yml, config::name);
$config->set("this", "that");
$config->save();


???

No i think you go to the folder with your plugin.yml (NOT 100% SURE) then create the default config that people should see
Example:

Code:

boolean: true
string: this is a string
numeric: 1

the on your plugin (in onEnable function) add

PHP:

$this->getResource("config.yml");

OOOOH I get it, the config.yml is a part of the .phar? And you just include the config.yml with the rest of your source code and use $this->getResource();
and you will be good. No need to create one when it's already included in the phar.

Thank you! I get it, I was all used to that sort of thing in the old api, there's a lot I still need to get used to. I am starting to realize that this is more down to earth PHP coding and less PM involvement. You make your own configs and package them and extend off of events.