Journey files

Journey files #

Each YAML file in journeys/ defines one journey. The highest-priority enabled journey matching an enrollment trigger is selected. The bundled first-hour journey uses FIRST_JOIN, so installing the plugin does not enroll players who already played on the server.

Supported progress triggers:

  • FIRST_JOIN, JOIN
  • ACTIVE_PLAYTIME, MOVE_DISTANCE
  • BLOCK_BREAK, BLOCK_PLACE, ITEM_CRAFT
  • ENTITY_KILL, PLAYER_KILL, DEATH
  • COMMAND, CHAT, ADVANCEMENT
  • CLICK for a deliberate menu interaction

Every step can define its own icon, slot, display-name, lore and click-actions. A journey can also define a 9-54 slot menu with custom header and status items. Journey files without these fields use the automatic layout.

Use match to restrict event-driven steps to a particular value. Matching is case-insensitive, accepts one value or a list, and ignores the minecraft: prefix for vanilla keys.

yaml
steps:
  visit_spawn:
    order: 1
    title: "Visit Spawn"
    trigger: COMMAND
    target: 1
    match: [spawn, hub]
    icon: COMPASS
    slot: 20
    display-name: "&bStep 1 &f- Visit Spawn"
    lore:
      - "&7Use the server's spawn command."
    click-actions:
      - "[close]"
      - "[player] spawn"

For a click-to-complete guide card, use trigger: CLICK and target: 1. A failed player-command click action does not complete a CLICK step. Put [close] before a command that opens another inventory.

Supported actions:

  • [message] text
  • [actionbar] text
  • [title] title|subtitle
  • [sound] ENTITY_EXPERIENCE_ORB_PICKUP 1 1
  • [player] command
  • [console] command {player}
  • [close]

Invalid triggers, duplicate step orders, invalid reminders and unknown actions are refused with the file name and the reason, without replacing the working configuration.

A config.yml from an older VelorJourney is upgraded to the current version with your values, comments and unknown sections preserved. The original is stored as config.yml.bak-v1 before the replacement is written. Existing journey and language files are never overwritten. A config.yml from a newer version is refused and left untouched.