Vote Reward 2.1.4

Connect Vote System points to a Custom Rewards catalogue while preserving the familiar player vote-reward chat commands.

At a glance

• Lightweight bridge between Vote System and Custom Rewards.
• Preserves /vote, /votes, and historical reward-command aliases.
• Verifies both dependency contracts and the exact shared reward type before opening the UI.
• Reads the player's vote points from Vote System.
• Delegates reward eligibility, persistence, delivery, and UI rendering to Custom Rewards.
• Stores no separate player balance and performs no reward delivery itself.

How it helps

Vote Reward keeps the player experience simple while each required product retains one clear responsibility. Vote System collects and attributes votes. Custom Rewards owns the catalogue, claim state, and delivery. Vote Reward checks that the two sides agree before exposing the combined flow.

Key features

• Configurable player chat aliases.
• Configurable Custom Rewards type and CUI parent.
• Contract and capability checks on load and dependency reload.
• Exact reward-type agreement with Vote System.
• Safe handling of missing, malformed, thrown, or mismatched dependency results.
• Structured UI-open result with clear failure diagnostics.
• No duplicated player storage.

How it works

When a player runs a configured command, Vote Reward:

1. verifies Vote System and Custom Rewards are loaded;
2. confirms Vote System contract V1 and its vote-points capability;
3. confirms Custom Rewards contract V2 and its owner-points and UI-open capabilities;
4. confirms both products use the configured reward type;
5. reads the player's points from Vote System;
6. asks Custom Rewards to open the enabled catalogue for that player.

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

Requirements and compatibility

Included required components

The download contains the complete matching stack:

• Custom Rewards 2.0.4 — the catalogue, UI, claim state, and delivery service.
• Vote System 2.1.3 — provider polling, identity attribution, and points.
• Vote Reward 2.1.4 — the player command bridge.
• A preconfigured enabled VoteSystem catalogue, English catalogue text, and matching plugin configurations.

Custom Rewards and Vote System remain required at runtime, but the exact matching deployables are included in this Vote Reward bundle.

Optional dependencies

Vote Reward has no optional dependency. Economics is optional for Vote System, not for this bridge.

Without either required dependency, with an unavailable capability, or with different reward-type names, Vote Reward fails closed and does not open a partial UI.

Setup

1. Back up existing configuration and data files.
2. Copy the included oxide directory into the server root.
3. Review oxide/data/CustomRewards_rewards/VoteSystem.json; it is enabled but contains only a safe example reward.
4. Grant customrewards.votesystem.use to eligible players.
5. Add provider tokens and required identity bindings in oxide/config/VoteSystem.json, then enable only the configured providers.
6. If reloading manually, load Custom Rewards, Vote System, then Vote Reward.
7. Test with a non-administrator account.

Commands and permissions

The shipped chat aliases are /vote, /votes, /vote_rewards, /vote_reward, /votes_reward, and /votes_rewards. They all open the same configured Custom Rewards type.

Vote Reward declares no separate permission. Access is controlled by the Custom Rewards dynamic permission for the selected type. With the default configuration, grant:

customrewards.votesystem.use

The historical mixed-case permission remains accepted by Custom Rewards for existing installations.

Configuration highlights

• CustomRewards reward type must exactly match Vote System and an enabled Custom Rewards type.
• Commands for show UI accepts one or more safe chat command names.
• UI parent defaults to Overlay and must be an accepted always-present Rust CUI parent.

Changing the reward type on an existing installation is an administrator migration. Update all three products together and verify the new catalogue before granting access.

Practical tutorials

Integration example: first /vote flow

1. Give a test account a small number of Vote System points.
2. Grant customrewards.votesystem.use.
3. Join with that account and run /vote.
4. Confirm the VoteSystem catalogue opens and displays the expected points and claim states.
5. Claim one low-value item.
6. Reopen the UI and confirm the claimed state remains visible.

Integration example: dependency reload

Reload Custom Rewards, then Vote System, then Vote Reward. Wait for the compatibility success message before testing /vote. If a dependency is absent during reload, the bridge remains unavailable until both checks succeed again.

Troubleshooting

• Vote System is not loaded: restore or reload the bundled Vote System before Vote Reward.
• Custom Rewards is not loaded: restore or reload the bundled Custom Rewards and verify the VoteSystem type.
• Reward type mismatch: use the exact same case-sensitive type in Vote System, Vote Reward, and the Custom Rewards filename.
• Reward type is disabled: review the catalogue, enable it, and reload Custom Rewards.
• The command opens nothing: grant customrewards.votesystem.use and check for duplicate chat command registration.
• Points are zero: diagnose provider attribution and bindings in Vote System; Vote Reward does not collect votes.

FAQ

Does Vote Reward replace Vote System?

No. Vote System is required and remains responsible for provider polling, identity attribution, and points.

Does Vote Reward deliver items?

No. Custom Rewards performs validation, persistence, delivery, and UI rendering.

Can I use a different reward-type name?

Yes, but the name must match in all three configurations and the Custom Rewards type must be enabled.

Support

Veuillez utiliser la section d'assistance Codefling en précisant les trois versions du produit, le framework, le type de récompense configuré, la commande exécutée et le premier diagnostic de compatibilité. N'incluez pas les jetons du fournisseur ni les fichiers de données du joueur.