Starter Pack

Here, take this! It’s a great place to start from. It doesn’t have anything in it yet, but it has a good folder structure to start with for following along with this documentation, as well as a starter pack.mcmeta so you don’t forget that.

cobblemon-confirm-release-starter-pack.zip

Release Guard

In order to add a new release guard that will prompt the confirmation workflow with the user, create a new JSON file in the /data/confirm_release/release_guard directory of your addon.

{
  "matcher": {
    "properties": "shiny"
  },
  "message": "confirm_release.feedback.reasons.shiny",
  "priority": 0
}

Properties

matcher

A PokemonMatcher as defined by Tim Core. For more details on what properties it takes, please click on the PokemonMatcher link. With a PokemonMatcher, you can match Pokémon based on the bucket they spawned from, labels on their form’s data (legendary, mythical, etc), PokemonProperties (think the /pokespawn and /pokeedit commands), as well as data stored on a particular Pokémon’s persistent data.

message

The message to display to the user in the confirmation prompt, in regards to why this Pokémon requires confirmation. This can help players second guess themselves with purpose!

priority

Release Guards are organized into priorities, the goal being to figure out which one should be used when giving the player feedback as to why. For example, if they’re releasing a shiny Mewtwo, and you have shinies and legendaries set up to be warned for, but you want legendary to be the message they receive over the one for shinies, you would have a setup like below:

{
  "matcher": {
    "properties": "shiny"
  },
  "message": "confirm_release.feedback.reasons.shiny",
  "priority": 1
}
{
  "matcher": {
    "labels": ["legendary"]
  },
  "message": "confirm_release.feedback.reasons.legendary",
  "priority": 0
}

The priority being set to 0 in the legendary.json means it will match first over the shiny.json, and the message that will be displayed to the player as to why they’re confirming this release would be the legendary message.

Messages - Lang Entries

As you can see above, my standard is to use lang file entry keys for messages to the player. This is because I would like to be able to translate any information I give to whichever language the player is playing Minecraft in, for their convenience, and I would like to be able to do so for all players on a server at the same time. By using a lang entry key like this, all I need is:

{
  "confirm_release.feedback.reasons.shiny": "It's a shiny Pokémon!",
	"confirm_release.feedback.reasons.legendary": "It's a legendary Pokémon!"
}