Setup

DayJobs is simple to set up. Simply drop the current release's archive into your plugins folder and unzip. The archive comes with the jar file and a default configuration file.

Dependencies/Suggested Plugins

DayJobs requires the server-side version of Spout to fully unlock it's potential. Though it will function without it, many of it's features will not be available, such as crafting, armor, and smelting restrictions.

Permission Systems

DayJobs supports:

• PermissionsEx
• PermissionsBukkit
• Minecraft's default Op status system

Commands and availability

Please refer to the Permission Nodes page for more information regarding command permission nodes and command availability using the Op system.

Configuration

There are several YAML files included in DayJobs' archive, each one managing a different aspect of DayJobs configuration. The only two you will need to manually modify during setup is 'config.yml' and 'init.yml'.

Config.yml

Most of the options in config.yml are fairly self explanatory. I'll be skipping over the obvious options during this tutorial.

config.override-bed-spawn

Description: This option allows you to set whether or not DayJobs spawn system will override a player's bed spawn. If set to true, a player will always respawn at the set respawn location, falling back to the world's default spawn.

Values: true/false

config.job-options.instant-first-job-change

Description: If set to true, the first job change a player makes (from the default-job to any other job) will be instant, and will not require admin approval. If set to false, the first job change will submit a ticket just like any other job change.

Values: true/false

config.job-options.instant-job-change

Description: If set to true, every job change will be instant and not require admin approval. If set to false, it will submit a ticket as normal.

Values: true/false

config.messages.*

Description: Each option under config.messages allows you to configure the text displayed to a character on certain events. The nodes are pretty self explanatory. Each message node supports Special Characters.

Values: A line of text consisting of the message to display to a user on certain events.

config.all.*

Description: The values under config.all are the default values for every class. Each job inherits from config.all, but can override the values listed. In the next section, I'll cover how to configure new jobs as well as the all parent job.

config.jobs.*

Description: New jobs are defined under config.jobs. In the next section, I'll explain how to define a new job.

Defining a new job

In this section I'll be covering how to define a new job. During this section, keep an eye on the Applies to config.all section for each value. Values marked with Applies to config.all are also useable in config.all.

Throughout this section, I will be constructing the "Redstone Engineer" as an example job.

Step 1: Defining the Job section

In order to begin defining a new job, we need to give it an identifier. A job's identifier is different from it's friendly-name, which will be explained later. It is the value a player will have to enter for commands such as "/job info <job>" and "/job change <new-job>". Since this identifier becomes a section header in the YML file, it must be a single word without spaces, and must begin with a letter.

So, since our Redstone Engineer is more then one word, lets use an abbreviation, RSE. Our config.yml file (only including the config.jobs sub node) now looks like this, with our cursor at the pipe:

config:
    jobs:
        RSE:
            |

Step 2: Friendly name

Applies to config.all: No

Ok, so now you have a name for your job. While a one word name worked perfectly for our Miner job, since it was already one word, it might not look so pretty if you job was actually called Redstone Engineer. And, since your players have to type the name each time they want to get information on it, you might have even abbreviated it to "M" (if you're creating a Miner) or "RE" (in the case of the previously mentioned Redstone Engineer). Since neither of those names are very description, there is the "friendly-name" option. Basically, it's the pretty looking name given to the job. For our job with the identifier "RSE", let's give it a more descriptive friendly name:

config:
    jobs:
        RSE:
            friendly-name: Redstone Engineer

Step 3: Bio

Applies to config.all: No

Each job needs a good bio! A bio should only be a few words long, although there is no hard limit on how long it may be. Keep in mind, though, that the bio must feet on the same screen along with the can-use, -place, -wear, -break, -craft, and -smelt information.

Lets add a bio to our Redstone Engineer job class:

config:
    jobs:
        RSE:
            friendly-name: Redstone Engineer
            bio: Affectionately nicknamed "Stoners", Redstone Engineers are masters of redstone contraptions.

Step 4: Can-use

Applies to config.all: Yes

The "can-use" node defines what a job can and can't use in terms of items. This means right clicking or left clicking with any non-block object in Minecraft. This node uses the Bukkit Enum name of a given item, a list of which can be found here.

Since we're defining a Redstone Engineer, we only want him using redstone related items, as well as perhaps a pickaxe and shovel to clear out blocks they may have placed during design. Let's start by removing any inheritance from config.all that the Redstone Engineer might have:

config:
    jobs:
        RSE:
            friendly-name: Redstone Engineer
            bio: Affectionately nicknamed "Stoners", Redstone Engineers are masters of redstone contraptions.
            can-use:
                - NOTHING

By adding "NOTHING" to the can-use node, we effectively give our selves a clean slate to work with for our Engineer.

Next, we should allow the Engineer to use up to stone pickaxes and shovels, that way they can remove any block they might have placed during construction.

config:
    jobs:
        RSE:
            friendly-name: Redstone Engineer
            bio: Affectionately nicknamed "Stoners", Redstone Engineers are masters of redstone contraptions.
            can-use:
                - NOTHING
                - WOOD_PICKAXE
                - WOOD_SPADE
                - STONE_PICKAXE
                - STONE_SPADE

Although all the items listed are in all caps, they are not case sensitive, and will work so long as they are a case insensitive version of the Material Enum value.

Step 5: Can-place

Allowed in config.all: Yes

The "can-place" node allows us to define what blocks a job class is allowed to place (duh :P). Since this is a Redstone Engineer, they should only have access to redstone related items. Lets give our Engineer job access to Redstone blocks, as well as pistons, doors/trap doors, and normal torches:

config:
    jobs:
        RSE:
            friendly-name: Redstone Engineer
            bio: Affectionately nicknamed "Stoners", Redstone Engineers are masters of redstone contraptions.
            can-use:
                - NOTHING
                - WOOD_PICKAXE
                - WOOD_SPADE
                - STONE_PICKAXE
                - STONE_SPADE
            can-place:
                - REDSTONE
                - REDSTONE_WIRE
                - REDSTONE_TORCH_ON
                - STONE_BUTTON
                - DISPENSER
                - LEVER
                - STONE_PLATE
                - STONE_BUTTON
                - DIODE_BLOCK_OFF
                - WOOD_PLATE
                - TORCH
                - PISTON_BASE
                - PISTON_STICKY_BASE
                - WOOD_DOOR
                - IRON_DOOR
                - TRAP_DOOR

Step 6: Can-wear

Applies to config.all: Yes

The "can-wear" node follows the same format as the other "can-x" nodes. This node defines what armor (or items, if you have a plugin that allows players to wear items) a player can place in their armor slots.

Step 7: Can-break

Applies to config.all: Yes

The "can-break" node defines what blocks a player can break. And again, it follows the same format as the other "can-x" nodes.

Step 8: Can-craft

Applies to config.all: Yes
Requires Spout server-side plugin: Yes

If you have Spout installed on your server, you have access to the "can-craft" node. This allows you to restrict what items a player can craft, in both their inventory crafting grid and a crafting table grid.

Step 9: Can-smelt

Applies to config.all: Yes
Requires Spout server-side plugin: Yes

This option is also only available if you have Spout on your server. It allows you to control what a player can smelt in a furnace. This should be the starting item, not the final result.

Init.yml

The file "init.yml" allows certain features to be enabled or disabled as needed. Since each node is very self explanatory, I won't go in depth on them. Valid values for each node are true (enabled) or false (disabled).

Conclusion

There you have it! A very basic configuration with a single job. Now, this is not a complete configuration, by far. You still need to add a default-job (unless of course you just created one), as well as a few more jobs, if you want to get full use out of this plugin.

If you have any further questions regarding configuration, you can refer to the default configuration provided in any of the DayJobs archives. Any further help can be requested on the forum's Help section.