Coding Style

Play nice with other scripts

It is important to recongize that Drustcraft may not be the only Denizen scripts present on the Minecraft server. Below are some coding styles that are needed to be followed by Drustcraft scripts ensure that the engine plays nice and fair with other scripts.

Feature?

A Denizen file in Drustcraft is known as a Feature, as they generally add a feature to the game or engine. Whenever you reference your feature in code, it should be in lowercase, replacing spaces with an underscore.

As an example the feature "Region Town" which adds Town regions to Drustcraft, is referenced as region_town in scripts.

Coding style

• Denizen scripts should end in .dsc and not .yml
• Each file should only contain a single topic or function. This makes it easier to debug and disable features
• Tab spacing is be 4 spaces
• Scripts start with the prefix drustcraft<type-character>_<feature> with the exception of command script containers
• Command script contains are prefixed with drustcraftc_ followed by the command name
• Flags are prefixed with drustcraft.<feature>.

Container types

Script type	Character	Example
assignment	a	drustcrafta_example
book	b	drustcraftb_example
command	c	drustcraftc_example
custom	x	drustcraftx_example
data	d	drustcraftd_example
economy	y	drustcrafty_example
enchantment	h	drustcrafth_example
entity	e	drustcrafte_example
format	f	drustcraftf_example
interact	i	drustcrafti_example
inventory	v	drustcraftv_example
item	o	drustcrafto_example
map	m	drustcraftm_example
procedure	p	drustcraftp_example
task	t	drustcraftt_example
world	w	drustcraftw_example

File locations

The Drustcraft Engine tries to keep itself neat and tidy so please place features into one of the following directories

Feature type	Directory	Details
Command	/Denizen/scripts/drustcraft/commands/	A feature that is run from a command that is used by a player.
Core	/Denizen/scripts/drustcraft/	Core Drustcraft engine files
Jobs (NPCs)	/Denizen/scripts/drustcraft/jobs/	NPC Jobs that a NPC can be set to become
Patches	/Denizen/scripts/drustcraft/patches/	Game patches to correct issues between the Engine and the Server or Players
Player	/Denizen/scripts/drustcraft/players/	Player based modifications
Region	/Denizen/scripts/drustcraft/regions/	Region types that show/hide titles, announcements or change entity interactions
World	/Denizen/scripts/drustcraft/worlds/	World based modifications
Server	/Denizen/scripts/drustcraft/server/	Server wide features that are not particularly tied to a world or entity

Documentation is important!

Make sure that your files contain relevant documentation and that you include updates to this guide to explain how to use your feature.

At a minimum, please include the following header in your file which helps identify what your feature is about, what it requires and who to contact for issues.

# Drustcraft - My example file
# Written by: My name (contact?)
#
# This example file adds no particular feature, but you would add
# a quick summary here. Also include any plugin requirements, etc.
#
# Drustcraft Engine: https://github.com/drustcraft/drustcraft
# License: GPL-3.0

Consider the release cycle

We try to follow Semantic Versioning. Breaking the Engine is not an option outside major releases. Servers can download the latest main branch which contains the latest stable code outside of a stable release.

Semantic Commit Messages

• <type>: <summary in present tense>
  • feat: (new feature for the user, not a new feature for build script)
  • fix: (bug fix for the user, not a fix to a build script)
  • docs: (changes to the documentation)
  • style: (formatting, missing semi colons, etc; no production code change)
  • refactor: (refactoring production code, eg. renaming a variable)
  • test: (adding missing tests, refactoring tests; no production code change)
  • chore: (updating grunt tasks etc; no production code change)

Coding Tips

Make sure the Drustcraft Engine is loaded

Scripts that use the events server start or script reload use the following code to ensure that the Drustcraft core is loaded first:

- wait 2t
- waituntil <server.has_flag[drustcraft.feature.core]>

Save your data!

The Drustcraft engine does clear out server, entity and player flags that begin with the drustcraft. prefix on server start or script reload.

This is to ensure that scripts are loaded with fresh, clean data.

If you have data that needs to be saved for it to be retrieved later, consider saving it when a player runs a command, or on a timed schedule.

Check your requirements

Drustcraft Features

Features should check that there requirements are available before attempting to use them, even if they are part of the current release!

Most features have a world container, so you can verify if a feature is installed by checking if its world container is present:

- if !<server.scripts.parse[name].contains[drustcraftw_region]>:
  - announce to_console 'Drustcraft Railway: Drustcraft Region is required to be installed'
  - stop

The above checks that the Drustcraft Feature is installed.

After checking a feature is installed, scripts should wait until it is ready before using it by waiting for its feature to be published:

- ...[code before required feature]...
- waituntil max:10s <server.has_flag[drustcraft.feature.region].or[<server.has_flag[drustcraft.fail.region]>]>
- ...[code using region feature]...

Plugins

If your feature uses a plugin, it should check that it is installed and active by using the following example:

- if !<server.plugins.parse[name].contains[LuckPerms]>:
    - announce to_console 'Drustcraft groups requires LuckPerms installed'
    - stop

The above checks that the plugin LuckPerms is installed and active