monthly-rewards
Per-rank prizes paid to the top voters when the month rolls over.
monthly-rewards.yml defines the prizes paid to the top voters of
the month that just ended. It sits on top of the per-vote rewards and
the milestones, and it ships disabled so a fresh install never
announces a payout with the example prizes.
Quick example
enabled: true
top: 3
broadcast: true
ranks:
- rank: 1
rewards:
- type: command
value: "eco give %player% 25000"
- type: command
value: "lp user %player% parent addtemp topvoter 30d"
- rank: 2
rewards:
- type: command
value: "eco give %player% 15000"
- rank: 3
rewards:
- type: command
value: "eco give %player% 7500"Reference
| Key | Type | Default | Notes |
|---|---|---|---|
enabled | boolean | false | Master switch. While it is false the automatic month-end run below does not happen at all. |
top | int | 10 | How many players are ranked and archived. The shipped file sets 3. |
broadcast | boolean | true | Sends monthly.header and one monthly.entry line per winner from messages.yml. |
ranks | list | One entry per placement. | |
ranks[].rank | int | The placement this entry pays. 1 is the winner. | |
ranks[].rewards | list | Same syntax as vote-rewards.yml. |
A placement inside top that has no ranks entry gets nothing, with
one exception: an entry with rank: 0 is used for every ranked
player who has no entry of their own. That is the easy way to give
ranks 4 to 10 the same small prize.
Rewards here take %player%, %rank%, %votes% (the winner's votes
that month) and %month% (for example 2026-04).
When it runs
The plugin checks for a new month once at startup and then once an
hour. When the month in general.timezone differs from the last one
it closed out, it:
- Takes the top
topvoters of the month that ended, counted from the vote log. - Saves them to the history shown in the Leaderboard History menu.
- Pays the
ranksrewards, ifenabledistrue. - Resets the monthly counters of everyone who has not voted in the new month yet.
So the payout lands within an hour after midnight on the 1st. If the server was off at that moment, it happens at the next start. Each step is recorded in the database, which is why a restart or a reload in the middle never pays twice.
With enabled: false none of this runs, so the Leaderboard History
menu stays empty. Players' monthly counts still start again from zero
in the new month, because each count is tied to the month it was made
in. If you want the history without paying prizes, close months out
by hand with /voteplus archive <period> confirm, which archives
without paying while rewards are disabled.
/voteplus monthly runs that check on demand instead of waiting for
the next hour, and /voteplus archive <period> confirm closes out
one specific past month. Neither will pay out the month that is
still running. See Commands.
A winner who is offline at payout time only receives the
command rewards. They are saved and run the next time that player
joins. Every other type (money, item, exp, message,
potion, firework, and chance or random even when they wrap a
command) is skipped for an offline winner, and a line in console
says how many were skipped. Since most winners are offline at
midnight on the 1st, build monthly prizes out of commands, as in
the example above.
The very first start
On a fresh install there is no "last month" to pay for. The plugin
records the current month and pays nothing. If you are installing
part way through a community's history and want an older month
closed out, use /voteplus archive.
On a network
With mysql.server-id set, every server keeps its own monthly
standings, so every server runs its own month-end: its own history,
its own winners, its own payout from its own monthly-rewards.yml.
Before v1.3.4 the "this month is done" marker was shared by the whole
database. The first server to notice the new month closed it out and
every other server skipped theirs. If you ran several server ids on
an older version, the other servers' past months were never archived
or paid. /voteplus archive <period> confirm on each of those
servers catches them up.