tulonsae / tulsys Goto Github PK

Design component versioning.

Add javadoc documentation headers to the code.

Design an integrity check method for config/data.

Design a generic Abstract Component to handle most of the common infrastructure.

• Include getLogger method for Component level logger.

Change command syntax from:

kitadm new -> kitadm-new

Update plugin.yml to have each command with its own usage.

Add enable/disable command to TulSys for kit component.

User story:

• Admin loads TulSys initially and all components turned off.
• Admin then enables kit component.
• Kit component is loaded.
• Kit component enabled is set to true in config.

User story:

• Admin disables kit component.
• Kit component is unloaded.
• Kit component enabled is set to false in config.

Add save-on and save-off commands to Kit Component.

Save-on (default) enables saves to config and data files. Reloads config and data files first.

Save-off disables saves to config and data files. Saves config and data files first.

User story:

• Admin needs to modify kits and finds it easier to do manually.
• Kit component needs to continue running.
• Admin issues save-off command.
• Admin edits config/data files.
• Admin issues save-on command.

A command for the kit's contents to be set to the contents of the user's inventory who called it.

Add edit command.

Ex: kitadm edit kitname /items 2_item:0, 5_item /description This is a description.
Possibly use | instead of /

User story:

• For advanced user who wants to edit several values at once.

Kit class save and load methods using same config information.

Refractor this to avoid duplication.

Implement command to add items to kit.

kit-item kitname [num *] item [, [num *] item] ....

Item ids or names may be used. If number is not specified, then quantity is 1.

Item may also consist of
name:type

which maybe either id or name.

Or a name which includes the type, e.g., blackwool.

Add kitadm newdesc command.

Adds a description to a kit, only if kit exists and no existing description.

When kit is initially created, have it be disabled so it can't be used until ready and enabled.

in config,
kit:
kits:
test: true or false

Allow kits to contain other kits.

Add appropriate commands.

Determine how to allow changing of kit defaults via commands/config.

When a command is turned off (or not registered), it's usage from the plugin.yml is still displayed.

Since bukkit does this for onCommand, need to remove the command usage from plugin.yml and do it within the plugin.

Probably a usage.yml or commands.yml.

Optionally allow kits to be added when a new kit is created.

Refractor Constants and TulSys to move more of the kit config and strings into the kit package.

Change config.yml to have
components:
comment: name is true if enabled, false if disabled
: true or false

Each component then has direct control over their config section in the config.yml.
The data should really go into a separate yml file so that other data sources can be easily added.

Change

KitCommands -> Commands
KitComponent -> Component

Note: leave Kit in name of data classes where this identifies them specifically.