U
/u/arcmaster25
Guest
Ran into an interesting AutoRank quirk while building rank-up requirements for my Towny economy server (Luxville), and figured I'd share the fix in case anyone else hits it.
I wanted rank-ups gated on FOUR requirements simultaneously:
AutoRank handles the first three natively. Playtime is "time played >= X", money is "money >= X", mcMMO integrates cleanly, and PlayerPoints even has a native REQUIREMENT type: "playerpoints points >= X". So gating on Seals worked fine.
The issue is the DEDUCTION step. AutoRank has native result types for money ("money take"), XP, and a handful of others - but NO native result type for PlayerPoints. Meaning: I could REQUIRE the player have 500 Seals to rank up, but I couldn't automatically DEDUCT them as part of the promotion.
Use AutoRank's "command2:" result type (runs as console) to call PlayerPoints' own command. Example YAML for a Hussler -> Vendor rank-up:
Two gotchas that cost me some time:
I've got three separate LuckPerms tracks (trading, construction, political), each 6 ranks. Because AutoRank uses "lp user &p parent set X" in the result (rather than "parent add"), it REPLACES the caste group rather than adding a second one. So it's structurally impossible for a player to end up on two tracks at once - caste choice becomes permanent without any custom plugin logic. Small thing but I liked how clean it fell out of the config.
Anyone using AutoRank with non-standard economy plugins found a cleaner deduction pattern than the command2 workaround? Or has anyone submitted a PR to AutoRank adding a native PlayerPoints result type? Would happily use one if it exists.
submitted by /u/arcmaster25
[link] [comments]
Continue reading...
The problem
I wanted rank-ups gated on FOUR requirements simultaneously:
- Playtime (hours)
- Vault money (Dollars, EssentialsX)
- mcMMO power level
- A second premium currency called "Seals" (PlayerPoints) - earned only from voting, quests, and events, never bought
AutoRank handles the first three natively. Playtime is "time played >= X", money is "money >= X", mcMMO integrates cleanly, and PlayerPoints even has a native REQUIREMENT type: "playerpoints points >= X". So gating on Seals worked fine.
The issue is the DEDUCTION step. AutoRank has native result types for money ("money take"), XP, and a handful of others - but NO native result type for PlayerPoints. Meaning: I could REQUIRE the player have 500 Seals to rank up, but I couldn't automatically DEDUCT them as part of the promotion.
The fix
Use AutoRank's "command2:" result type (runs as console) to call PlayerPoints' own command. Example YAML for a Hussler -> Vendor rank-up:
Hussler: requirements: - 'time played >= 3000' - 'money >= 5000' - 'mcmmo powerlevel >= 200' - 'playerpoints points >= 500' results: - 'command1: lp user &p parent set vendor' - 'command2: pp take &p 500' - 'command3: eco take &p 5000' - 'command4: broadcast &p promoted to Vendor' - 'message: &aYou have been promoted to Vendor!' Two gotchas that cost me some time:
- The placeholder is "&p" (AutoRank's own), NOT "%player%" - AutoRank doesn't parse PlaceholderAPI in its result strings.
- Each command must have a unique key ("command1", "command2", "command3"...) - if you reuse a key it silently overwrites the previous line. Learned that one the hard way.
Bonus: making caste tracks one-way
I've got three separate LuckPerms tracks (trading, construction, political), each 6 ranks. Because AutoRank uses "lp user &p parent set X" in the result (rather than "parent add"), it REPLACES the caste group rather than adding a second one. So it's structurally impossible for a player to end up on two tracks at once - caste choice becomes permanent without any custom plugin logic. Small thing but I liked how clean it fell out of the config.
Question for the sub
Anyone using AutoRank with non-standard economy plugins found a cleaner deduction pattern than the command2 workaround? Or has anyone submitted a PR to AutoRank adding a native PlayerPoints result type? Would happily use one if it exists.
submitted by /u/arcmaster25
[link] [comments]
Continue reading...