Skip to content
Matcha! Mods

Installation Guide

Installation Guide

Section titled “Installation Guide”

ShowdownActions is a Fabric mod. Drop the jar in, start the server, you’re done.

Requirements

Section titled “Requirements”
RequirementDetails
Minecraft1.21.1
Fabric LoaderLatest stable
Java21 or higher
CobblemonCompatible build
Ceremony4.7+
Fabric APIMatching your Minecraft version
Fabric Language KotlinRequired

Optional:

  • fabric-permissions-api or LuckPerms — only needed if any of your actions uses the permission field

Installation Steps

Section titled “Installation Steps”

1. Drop the Jars

Section titled “1. Drop the Jars”
  1. Stop the server.
  2. Place showdown_actions-<version>.jar in mods/ alongside Cobblemon, Ceremony, and Fabric API.
  3. Start the server.

2. Verify the Load

Section titled “2. Verify the Load”

Watch the server console for these lines during startup:

[ShowdownActions] initializing…
[ShowdownActions] config loaded (debug=false)
[ShowdownActions] Molang helpers registered
[ShowdownActions] Registered N action(s)
[ShowdownActions] Registering N Showdown condition(s)…
[ShowdownActions] Subscribed to BATTLE_STARTED_PRE

The “Registered N action(s)” count is the number of .conf files ShowdownActions could parse from config/showdown_actions/actions/. The “Registering N Showdown condition(s)” count is the subset of those whose apply block emits a Showdown-side effect.

If you see content load failed or config load failed, the config files have a HOCON syntax error — the stack trace points to the offending file.

3. Test In-Game

Section titled “3. Test In-Game”
/showdownactions list

Should print every loaded action id. Then:

/showdownactions info <id>

Dumps the resolved match/apply clauses for that action. If the field you set in the .conf shows up here, ShowdownActions parsed it correctly.

Directory Structure

Section titled “Directory Structure”

On first launch, ShowdownActions creates this structure:

config/showdown_actions/
├── config.conf                           # Master switch and battle-type filters
└── actions/                              # One .conf per action
    ├── 00_bible.conf                     # Annotated reference for every option (disabled)
    ├── example_01_minimal.conf           # The smallest possible action (disabled)
    ├── example_02_match_clause.conf      # All match-clause fields (disabled)
    ├── example_03_apply_clause.conf      # All apply-clause fields (disabled)
    ├── example_04_targeting.conf         # SELF / ALLIES / FOES / EVERYONE / FIELD (disabled)
    ├── example_05_raw_showdown.conf      # The tier-3 escape hatch (disabled)
    ├── example_06_molang_predicates.conf # whenMolang cookbook (disabled)
    ├── recipe_friendship_aura.conf       # Friendship-gated aura (disabled)
    ├── recipe_legendary_boss.conf        # Wild legendary boss buff (disabled)
    ├── recipe_low_hp_desperation.conf    # "Last stand" boost (disabled)
    ├── recipe_lycanroc_form_rotation.conf # Time-of-day form swap (disabled)
    ├── recipe_wish_on_switch.conf        # Held-item heal on switch-in (disabled)
    ├── lycanroc_dusk.conf                # Working sample (enabled)
    ├── rainy_swift_swim.conf             # Working sample (enabled)
    └── custom_intimidate.conf            # Working sample (enabled)

The bundled examples and recipes all ship with enabled = false. They’re meant to be read like documentation — copy one into a new file with enabled = true and your own id when you want to use it.

00_bible.conf is the canonical reference. Every field ShowdownActions supports lives there with its type, default, and re-evaluation behavior described inline.

Hot Reload

Section titled “Hot Reload”
/showdownactions reload

Re-parses config.conf and every .conf in actions/. Reloads are idempotent and never restart Showdown. Battles that are already in progress keep the conditions they were registered with at battle start; new battles pick up the new rules.

If a reload fails on a single file, the rest of the ruleset is preserved — ShowdownActions logs the failing file and keeps the previous version of that action live.

Troubleshooting

Section titled “Troubleshooting”

“No actions are currently registered” : Either actions/ is empty or every file in it has enabled = false. Check /showdownactions list.

An action’s match is correct but the effect never appears in battle : Run /showdownactions debug on and re-trigger the battle. The [ShowdownActions] log lines walk through every match attempt and every Showdown hook fire. See Debugging Actions for the full debug-log decoding guide.

A whenMolang predicate parses fine but the action never matches : Almost always the predicate evaluates to 0.0 for reasons that aren’t obvious. With debug = true, the matcher logs the compiled Molang and the match/miss result for every candidate — read Molang Predicates for the bindings and helpers available.

“Failed to execute action command” : The command field runs as the server console. Use full vanilla syntax with {player} for the trainer’s username.

Next Steps

Section titled “Next Steps”
  1. Read the Configuration page to learn what config.conf controls.
  2. Skim Action Files for the anatomy of a single .conf.
  3. Open the bundled 00_bible.conf — it doubles as inline reference and the displayName field is “ShowdownActions — full option reference” for a reason.