plugin.yml

#Name of your plugin. This is self-explanatory. Plugin names SHOULD NOT contain spaces.
name: DumpBadLogins

#Fully-qualified class-name of your plugin's main class. This is usually the one that extends PluginBase.
#Since PocketMine-MP's autoloader is PSR-0, your plugin's main-class namespace will usually be the same as the folder path.
main: dktapps\DumpBadLogins\Main

#Version name/number of your plugin
version: 0.0.1

#API version that your plugin supports. If your plugin's API is not compatible with that of the server, the server will refuse to load your plugin.
#The API version is changed when:
# - Breaking changes are made to a development version, things that might cause your plugin to crash.
#     This is denoted by an API suffix, for example 3.0.0-ALPHA4. If the version does not match as a whole on a development version, the plugin will not be loaded. (Suffixes are non-case-sensitive.)
# - Breaking changes are made to a release version, things that might cause your plugin to crash.
#     This usually warrants a major API bump, e.g. 2.0.0 -> 3.0.0. If the major version does not match, the plugin will not be loaded.
# - Feature additions which do not break existing plugins.
#     This is denoted by a minor API bump, e.g. 2.0.0 -> 2.1.0. The server will load plugins with an equivalent or older minor version.
# - Minor bug fixes or insignificant alterations to the API.
#     This is denoted by a patch bump, e.g. 1.13.0 -> 1.13.1
api: [3.0.0-ALPHA8, 3.0.0-ALPHA9]

#When to load the plugin. There are currently two options for this: STARTUP and POSTWORLD. Usually POSTWORLD will do fine.
load: POSTWORLD

#Name of the person who wrote the plugin. This can be anything you like.
author: dktapps

#Simple description of what the plugin is or does. Try to keep this short.
description: Skeleton plugin generated by PocketMine-MP DevTools

#Website for your plugin. This could be a GitHub repository URL, a website of your own, or anything you like. This is optional.
website: https://github.com/pmmp/PocketMine-DevTools

#Commands that your plugin has. You can capture the execution of these via the `onCommand()` method in your PluginBase, or the registered CommandExecutor for the command.
#This node is optional and can be removed if your plugin will not have any commands.
commands:
 #Name of the command. This is what people will type to execute the command.
 examplecommand:
  #Description to show in the Help command
  description: "Skeleton plugin example command"
  #Usage message shown to the user if they type the command in incorrectly.
  usage: "/examplecommand"
  #Permission required to execute the command. This should be the name of a permission defined in the section below.
  permission: skeleton.command

#Define permissions used in your plugin here. You can check whether permissibles have permissions in your plugin to allow or disallow actions such as command execution.
permissions:
 #Root permission node
 skeleton:
  #Default state of this permission. `op` means that only server operators will have this permission by default.
  default: true
  #Description of what the permission does or doesn't allow.
  description: "Example root permission node"
  #Child permission nodes. If the parent permission node is true, the children will have the values set here. If false, all child permissions will be inverted.
  children:
   skeleton.command:
    default: true
    description: "Allows the use of /examplecommand"