Custom Rewards 2.0.4

Turn player engagement into a clear, visual reward journey with configurable catalogues, secure claims, and administrator-controlled delivery.

At a glance

• Create independent reward types with their own points, catalogue, commands, permission, language, and visual theme.
• Let players browse paginated rewards, see locked or claimed states, and claim eligible rewards from an in-game UI.
• Deliver items, server commands, permission grants, and group grants through one reviewed reward definition.
• Keep point ownership compatible with integrations such as Vote System while retaining administrator control.
• Recover safely from reloads and partial delivery without replaying completed actions.

How it helps

Custom Rewards gives server owners one reusable reward layer instead of a separate UI and claim implementation for every event. Each reward type can represent voting, playtime, seasonal progress, VIP benefits, or another server-owned points source.

Key features

• Multiple reward catalogues, each stored in its own JSON file.
• Configurable show commands and dynamic customrewards.<type>.use access.
• Common, Rare, Epic, and Legendary presentation with configurable colours.
• Per-page browsing with visible available, locked, and claimed states.
• Server-side eligibility checks repeated when a reward is claimed.
• Item, command, permission, and group actions.
• Owner-scoped point APIs for integrations.
• Durable claim progress and administrator-visible reconciliation when an external action has an uncertain result.
• Safe migration of supported legacy player data.

Player workflow

1. An administrator enables a reviewed reward type and grants its use permission.
2. The player runs one of that type's configured chat commands.
3. The UI displays the current catalogue and the player's claim state.
4. The player changes page if needed and selects an eligible reward.
5. The server validates points, prerequisites, and claim state again before delivery.

The visible screen distinguishes rewards that are available, already claimed, or unavailable. Administrators decide which commands display each catalogue and which groups can access it.

How it works

Each file in oxide/data/CustomRewards_rewards/ defines one reward type. Its filename is the exact type used by permissions and integrations. Player balances and claim progress are stored separately so an interrupted delivery can resume without repeating confirmed actions.

customrewards_give VoteSystem 76561198000000000 5

The example grants five owner points to the VoteSystem reward type. Run administrator commands from the server console or with the administrative permission.

Requirements and compatibility

• Rust server using Oxide or Carbon.
• The standalone CustomRewards.cs file from this product.
• No required plugin dependency.
• Optional integrations must use the documented compatibility APIs and the same reward-type name.

Setup

1. Back up existing oxide/data/CustomRewards_* files.
2. Install CustomRewards.cs in the framework plugin directory.
3. Let the plugin create oxide/data/CustomRewards_rewards/.
4. Copy and rename the supplied example configuration for each reward type you need.
5. Review every item name, server command, permission change, group change, image URL, and eligibility rule.
6. Set Enabled to true only after that review.
7. Grant customrewards.<type>.use and test the configured show command with a non-administrator account.

Commands and permissions

CommandPurposeAuthorization

Reward-type show commandsOpen the configured catalogue UIAdministrator or customrewards.<type>.use

customrewards_give <type> <player> <quantity>Add points to one playercustomrewards.admin

customrewards_wipe_owner <type> <owner>Remove one owner's contribution from a balancecustomrewards.admin

customrewards_wipe_all <type>Clear all balances for one reward typecustomrewards.admin

customrewards_changepageInternal player paging actionPublic, arguments validated by the server

customrewards_claimInternal player claim actionPublic, eligibility rechecked by the server

The historical CustomRewards.Admin and CustomRewards.<Type>.Use forms remain accepted for existing installations.

Configuration highlights

New reward types are disabled by default. Start with a small catalogue and a test-only permission:

{ "Enabled": false, "Commands for show UI": ["vote_rewards"], "UI Settings": { "Max Reward By Page": 5, "Show Description": true }, "Rewards Settings": { "Rewards List": [ { "Rarity (Common - Rare - Epic - Legendary)": "Common", "Quantity": 100, "Item Shortname (optional)": "wood", "Server command (optional)": [], "Grant Permissions :": [], "Grant Groups :": {}, "Needed Permissions :": {}, "Needed Groups :": {} } ] } }

Only %steamid% is accepted as a command placeholder. Keep reward configuration restricted to trusted administrators because configured commands and access changes are privileged actions.

Practical tutorials

Example: create a voting catalogue

1. Create VoteSystem.json in oxide/data/CustomRewards_rewards/.
2. Set a safe show command such as vote_rewards.
3. Add one low-value test reward and leave the type disabled.
4. Reload Custom Rewards and resolve every validation error.
5. Grant customrewards.votesystem.use to a test group.
6. Enable the type, add test points, open the UI, and claim the reward.
7. Add the remaining catalogue only after the complete test succeeds.

Example: integrate another points source

Use the owner-points API with a stable owner name. Keep the reward type identical in both plugins, check that it is enabled, and open the UI through the structured UI method so a failure can be reported without exposing an incomplete screen.

Troubleshooting

• The show command is unknown: confirm the reward type is enabled and its command is unique.
• The UI says access is denied: grant customrewards.<type>.use or test with an administrator.
• A catalogue does not load: review the first validation error for invalid actions, empty rewards, unsafe placeholders, or contradictory access rules.
• A claim is pending review: inspect the administrator diagnostic before retrying; do not edit player data to bypass an uncertain external action.
• Images do not appear: verify direct HTTPS image URLs and keep custom URLs under administrator control.

FAQ

Can two reward types use different themes?

Yes. Each reward-type file owns its catalogue, UI settings, colours, commands, and access permission.

Can a reward combine actions?

Yes. One reward can contain an item plus reviewed commands, permission grants, or group grants. Each action is tracked separately during delivery.

Does Custom Rewards require Vote System?

No. Vote System is an optional points source. Custom Rewards can run with administrator grants or another compatible integration.

Support

Use the Codefling support section with the plugin version, framework, reward-type name, the first relevant error, and a redacted configuration excerpt. Never include API tokens or private player data.