Vote System

Vote System 2.1.3 — user guide

This guide covers the Codefling version 2.1.3. The separate 2.1.4 beta changes provider-response handling; select the configuration version installed on your server.

Installation order

1. Back up oxide/data/VoteSystem and the existing configuration.
2. Install VoteSystem.cs.
3. Install Custom Rewards only if you want owner-point mirroring or a reward UI.
4. Install Economics only if you want deposits.
5. Install Vote Reward last if players need the historical /vote-style chat commands.

All providers ship disabled. Obtain tokens directly from each provider and never publish them in configuration examples or support messages.

The configurator exports VoteSystem.json. Install it as oxide/config/VoteSystem.json (the corresponding config directory on Carbon), then reload VoteSystem. Keep exported files private: they contain any tokens you entered. The site does not save configurations on its server.

Provider identity model

Top-Serveurs and Top-Games return historical nickname vote feeds. Those nicknames do not authenticate a Steam owner. Add a separate Nickname to Steam ID bindings entry under each provider before expecting owner-scoped points or rewards.

Rust-Servers.net uses the valid authenticated Steam ID returned by its Steam-ranking response. Nickname-only rows are rejected and are not matched to a connected player's display name.

First provider example

{
  "TopServer": {
    "Enabled": false,
    "API Url": "https://api.top-serveurs.net/v1/votes/last?server_token=%token%",
    "API Token": "",
    "Points by vote": 1,
    "Nickname to Steam ID bindings": {
      "provider nickname": "76561198000000000"
    },
    "Routine Settings": {
      "Check Interval (seconds)": 30
    }
  }
}

Insert this structure in Vote Servers Settings, add the real token locally, verify the binding, and enable the provider only after review.

Optional integrations

• Custom Rewards: optional. The configured reward type defaults to VoteSystem. Custom Rewards contract V2 and its owner-points capability are checked before points are granted.
• Economics: optional. The multiplier converts accepted points into a deposit amount. Accepted vote state is saved before the deposit.
• Vote Reward: optional player command and UI bridge. It requires both Vote System and Custom Rewards.

Disable unused integrations explicitly. If an optional effect fails after the vote is saved, review the reconciliation warning before making a manual adjustment.

Commands and permission

• votesystem.wipe starts a durable wipe generation.
• votesystem_wipe is the historical alias.
• Both require a Rust administrator or votesystem.admin.

During the operation, polling pauses, prior-generation callbacks are ignored, and a fresh Rust-Servers.net baseline is stored when that provider is enabled.

Backups and recovery

Back up the complete oxide/data/VoteSystem directory before changing bindings, upgrading, or starting a baseline reset. Keep nickname, Steam, player, and wipe files together.

If state is unreadable or unsupported, the affected path fails closed and a quarantine copy is attempted. Restore a complete known-good backup. Do not import a nickname file into the Steam namespace or change a binding to make an existing balance belong to another account.

Provider data and cost

The operator owns each provider account and reviews its current pricing, limits, and privacy policy. Vote System sends the configured server token and request parameters to the provider and receives the provider's vote response. It does not send Custom Rewards catalogues, Economics balances, or server chat.

Troubleshooting

• Provider disabled: review URL, token, interval, and points value.
• Top vote has no player effect: add the nickname binding under the correct provider.
• Rust-Servers.net row rejected: ensure Steam OpenID voting and Steam ranking are enabled.
• Economics effect failed: use the reconciliation key and avoid blind retries.
• Polling blocked after wipe: repair or restore the wipe state and obtain a valid baseline.

Validation limits

The historical release passed a bounded load/runtime smoke. Real provider ingress was not exercised, the complete player UI/claim flow was not repeated for the exact final lot, and Carbon runtime parity was not exercised.