Vote Reward

Vote Reward 2.1.4 — user guide

This guide covers the Codefling version 2.1.4. The PimpMyCUI visual profile is part of the separate 2.2.0 beta, not this version.

VoteSystem configuration on PimpMyRust

The Hub now configures VoteSystem 2.1.5, including inside VoteReward. Replace the older VoteSystem dependency before installing this new configuration. The VoteReward Codefling archive has not been repackaged. Its dependency check verifies API contract 1, not the minimum VoteSystem version. Follow the VoteSystem 2.1.5 guide for provider tokens, SteamID64 votes and migration.

Bundle contents and installation order

The Vote Reward download includes Custom Rewards 2.0.4, Vote System 2.1.3, Vote Reward 2.1.4, and a matching enabled Custom Rewards catalogue named VoteSystem.

1. Back up existing configuration and data files.
2. Copy the included oxide directory into the server root.
3. If reloading manually, load Custom Rewards first, Vote System second, and Vote Reward last.
4. Configure providers in VoteSystem; use the 2.1.5 guide above for new Hub exports.
5. Review the included VoteSystem reward catalogue before granting access.

Custom Rewards and Vote System remain required runtime components, but the matching versions are bundled with Vote Reward. There is no optional Vote Reward dependency; Economics is an optional Vote System integration.

Configuration

Export VoteReward.json from the configurator and install it in oxide/config/VoteReward.json (the corresponding config folder on Carbon). Reload VoteReward after saving. This file configures only the bridge; provider credentials belong in VoteSystem and rewards belong in CustomRewards.

{
  "CustomRewards reward type": "VoteSystem",
  "Commands for show UI": [
    "vote",
    "votes",
    "vote_rewards",
    "vote_reward",
    "votes_reward",
    "votes_rewards"
  ],
  "UI parent": "Overlay"
}

The reward type must match Vote System and the enabled Custom Rewards filename exactly. Keep Overlay unless another accepted always-present parent is required by your UI composition.

Player access

Vote Reward registers the configured chat aliases but declares no separate permission. Grant the Custom Rewards use permission for the selected reward type:

customrewards.votesystem.use

Test with a non-administrator account. The bundled Custom Rewards catalogue leaves its show-command list empty so Vote Reward can register all supplied aliases.

End-to-end flow

1. Vote System stores provider votes and resolves owner points.
2. The player runs /vote.
3. Vote Reward verifies both dependency contracts and the exact reward type.
4. Vote Reward reads points from Vote System.
5. Custom Rewards opens the catalogue, validates the claim, stores progress, and delivers the configured actions.

Vote Reward stores no player balance and performs no reward delivery.

Upgrade and recovery

Back up the Vote System and Custom Rewards data directories before upgrade. Vote Reward has no player data to migrate.

If a dependency check fails, restore or reload the affected dependency, confirm the shared reward type, then reload Vote Reward. Do not bypass the checks by editing compiled code or player files.

Troubleshooting

• Missing Vote System: restore or reload the bundled required version.
• Missing Custom Rewards: restore or reload the bundled version and verify the catalogue.
• Type mismatch: use one exact name across all three products.
• Disabled type: review and enable the Custom Rewards catalogue.
• Permission denied: grant customrewards.votesystem.use.
• Zero points: diagnose the provider and vote identity in VoteSystem.
• Duplicate command: keep each chat alias registered in only one plugin configuration.

Validation limits

The historical release passed a bounded load/runtime and dependency-handshake smoke. The complete player /vote UI and claim campaign was not repeated for the exact final lot, real provider ingress was not exercised, and Carbon runtime parity was not exercised.