Rewards
The three prize pools, who each one pays, and how to control the number of prizes handed out.
Rewards are console commands the plugin runs on a player's behalf. Because they are just commands, anything your other plugins can do is fair game. Give money, hand out a crate key, run a broadcast.
The three pools
| Pool | Rolled | Paid to |
|---|---|---|
rewards.hit | Every hit that lands | The player who hit |
rewards.death | Once when the piñata breaks | Everyone who landed at least one hit, each rolled separately |
rewards.last-hit | Once when the piñata breaks | Only the player whose hit broke it, on top of their death rewards |
Keep hit rewards small. A party with ten players online needs thirty hits at the default settings, so a hit reward can fire dozens of times in one party.
Writing a reward
Each numbered entry under a pool is one reward. The number is just a label, so name entries whatever you like as long as they are unique.
rewards:
hit:
'1':
chance: 50.0
commands:
- "eco give %player% 50"
'2':
chance: 25.0
commands:
- "give %player% diamond 1"commands is a list, so one reward can run several commands. They run as console, in order.
| Placeholder | Becomes |
|---|---|
%player% | The name of the player getting the reward |
The key is commands, with an s, even when there is only one command in the list.
How many prizes are handed out
This is the part worth reading twice. A pool works one of two ways depending on whether you gave it min-rewards or max-rewards.
Every entry is rolled on its own and chance is a plain percentage out of 100.
rewards:
death:
'1':
chance: 100.0
commands:
- "eco give %player% 500"
'2':
chance: 50.0
commands:
- "give %player% netherite_ingot 1"Entry 1 always fires. Entry 2 fires half the time. They do not affect each other, so a player can end up with both, one, or nothing.
This is how the hit and death pools ship, and how every pool behaved before this option existed.
Both keys work in any pool. Add them to hit or death if you want the same fixed count behaviour there.
Last hit rewards
rewards.last-hit is the pool for the player who lands the killing blow. It is the reason to keep swinging when the counter gets low.
rewards:
last-hit:
min-rewards: 1
max-rewards: 3
'1':
chance: 50.0
commands:
- "eco give %player% 1000"
- "broadcast &6%player% &elanded the final hit!"A few things to keep in mind:
- The winner still gets their
deathrewards. The last hit pool is extra, not instead. - Only one player can win it. If they log out in the same tick the piñata breaks, the pool is skipped.
- Because a miss does not count as a hit, the winner is whoever landed the last hit that actually registered.
Want to announce the winner? Put a broadcast line in one of the last hit rewards with %player% in it. See Broadcasts for keeping the message free of another plugin's prefix.
A worked example
Rather than describe it, here is one whole party with real numbers.
The setup. Three players are online and hits-multiplier is 3, so the piñata takes nine hits. Steve lands three, Alex lands five, and Mira lands the ninth and last one.
rewards:
death:
'1':
chance: 100.0
commands:
- "eco give %player% 1000"
- "broadcast &6%player% &ewon the grand prize!"
'2':
chance: 50.0
commands:
- "give %player% netherite_ingot 1"
last-hit:
min-rewards: 1
max-rewards: 2
'1':
chance: 60.0
commands:
- "eco give %player% 5000"
- "broadcast &6%player% &elanded the final hit!"
'2':
chance: 30.0
commands:
- "give %player% diamond_block 1"
'3':
chance: 10.0
commands:
- "give %player% nether_star 1"What happens the moment it breaks.
The death pool rolls once per player
All three landed at least one hit, so each of them gets their own roll. Entry 1 is on 100.0, so all three get 1000 coins and a broadcast. Entry 2 is on 50.0, so the netherite ingot is a coin flip each: Alex gets one, Steve does not.
Nothing here is affected by who landed the last hit.
The last hit pool rolls once, for Mira only
This pool has min-rewards: 1 and max-rewards: 2, so the plugin picks a random number in that range. This time it picks 2.
It then draws 2 of the 3 entries, weighted by chance. Entry 1 at 60 is the most likely, entry 3 at 10 the least. It draws entries 1 and 2, so Mira gets 5000 coins, a broadcast, and a diamond block.
Mira ends up with both
She keeps her death pool rewards as well, so her total for the party is 1000 coins from the death pool, plus 5000 coins and a diamond block from the last hit pool.
Steve and Alex get nothing extra. Only one player can win this pool.
Run it again and it differs. The last hit pool could just as easily have picked 1 reward instead of 2, or drawn entry 3 and handed over the nether star. That is the point of min-rewards and max-rewards: the amount is bounded, but which prizes come out is not.
Because chance is a weight here, entry 1 on 60 is not "fires 60% of the time". It is "six times as likely to be drawn as entry 3 on 10". Over a lot of parties with the config above, entry 1 shows up in about 76 in every 100, entry 2 in 54, and entry 3 in 20.
Testing your rewards
- Set
pinata.hits-multiplierto1andpinata.hit-chanceto100.0so a piñata breaks in a couple of hits. - Set
pinata.hit-cooldownto0.1so you are not waiting between swings. - Summon one, break it, and watch the console for any command that failed.
- Put your real numbers back.
If a reward command works when you type it in console but not through the plugin, check that it does not need a player as the sender. Everything the plugin runs is sent as console.