FAQ

No — not yet. config.yml exposes storage.type and a full set of MySQL connection fields, but nothing in the current codebase reads them. Every player's progress is saved to a per-player YAML file under plugins/AlphaRewards/playerdata/ regardless of what storage.type is set to. Treat those config keys as reserved for a future version, not a working feature today.

No. Vault is declared as a soft-dependency in plugin.yml, but there's no Vault/Economy API usage anywhere in the code. Money-style rewards in the menu YAML files (e.g. eco give {player} 500 or cmi money give {player} 500) are plain console commands that rely on whichever economy plugin you actually have installed providing that specific command — not on Vault's API directly. The Vault soft-dependency currently has no effect either way.

No. DAILY-mode fields (current day, claimed days) and STREAK-mode fields (streak count) are stored completely independently per player. Switching reward-mode in config.yml just changes which set of fields — and which menu file — is active; the inactive mode's data sits untouched and picks up right where it left off if you switch back.

Nothing currently — both keys are defined in messages.yml but never referenced anywhere in the Java code. They're dead/unused as of this version; don't rely on them being sent for any specific event.

Four custom Bukkit events, all under dev.alphastudio.alpharewards.api.events:

• AlphaRewardPreClaimEvent — cancellable, fires after validation but before the claim is recorded. Cancel it to block a claim entirely.
• AlphaRewardClaimEvent — not cancellable, fires after a claim has fully succeeded (data saved, reward commands already run).
• AlphaRewardStreakBreakEvent — not cancellable, fires whenever a streak resets (on join or at claim time). The streak is already reset by the time it fires.
• AutoClaimEvent — not cancellable, fires after a successful auto-claim on join, in addition to (not instead of) the claim event above.

By design. AlphaRewards replaces legacy &e/&6 (yellow/gold) codes with whatever hex is set in colors.primary-gold in config.yml — it also strips bold/underline/italic/strikethrough formatting codes (&l/&n/&m/&o) entirely from item names and lore. This is intentional house style, not a bug.

Almost always tier ordering in the menu YAML. See Permissions → Tier order — tiers are matched top-to-bottom and each match overwrites the last, so a higher tier listed before a lower one gets silently overridden for players who hold both permissions.

No. It only re-reads config.yml, messages.yml, and the menu files. Any change to the plugin's actual compiled code requires a full server restart.