Configuration file

Storage

Multiple storage facilities can be used to store parkours configurations and scores. Here is a list of available implementations:

Nitrite DB

A powerful NoSQL database using the H2’s storage engine

Document oriented

Default

Yaml files

The ugly yaml files you all know

MySQL

a relational database management system based on SQL. The most popular open source database

Relational

MongoDb

a NoSQL replicable database

Document oriented

Coming soon

Prefer using a document oriented implementation as these are the fastest to handle YJump operations. Other solutions are maintained to support your needs but can slow down the plugin (not that much, but still).

Nitrite DB

This is de default setting and the most supported implementation by the plugin. To configure the plugin to use nitrite, you must set the implementation to either nitrite, nitrite-database, nitrite-java, nooor no2.

storage:
  implementation: "no2"

The implementation will create a data.nitrite.db file in the YJump folder. this file has a binary structure managed by nitrite. As any managed database files, you should not try to edit these files. This file can be open in read-only mode with the Nitrite explorer.

YAML files

To use yaml files, you simply need to set the implementation to either yaml, yml, flat file, flat files, flat, file or files.

storage:
  implementation: "yaml"

This will result in the flowing file structure under the YJump directory:

├── guis
│   └── ... (all gui files)
├── jumps
│   ├── <Some parkour UUID>.yml
│   ├── <Another parkour UUID>.yml
│   └── ...
├── locals
│   └── ... (all local files)
├── players
│   ├── <Some player UUID>.yml
│   ├── <Another player UUID>.yml
│   └── ...
└── config.yml

Parkour files are structured as follows:

jump:
  ==: Jump
  id: # unique id of the parkour (same as the file name)
  item: # icon of the parkour
  name: # name of the parkour
  description: # description of the parkour
  fall distance: 5
  world: # world of the parkour
  spawn: # coordinates of the spawn point
  start: # coordinates of the start point
  end: # coordinates of the end point
  checkpoints:
  - # coordinates of a checkpoint
  best scores:
  - ==: score
    date: # timestamp of the score
    score: # duration of the passage (millis)
    player: # UUID of the player

Player files are structured as follows

<UUID of a parkour>: # duration of the first 10 passages (or value configured in config.yml) in millis
<UUID of another parkour>: # same for another parkour

MySQL

MySQL’s storage is still a beta feature and can break with any patch version

To configure the plugin to use MySQL and connect to a remote server, you must set the implementation to either mysql or sql and set remotes access credentials:

storage:
  implementation: "mysql"
  remote:
    host: "serverip"
    port: 3306 # (default for mysql)
    name: "database name"
    user: "user name"
    pass: "password"