About Vote System
Collect votes from supported server-list providers, keep provider identities correctly separated, and turn verified vote totals into points or optional server rewards.
At a glance
- Poll Top-Serveurs, Top-Games, and Rust-Servers.net from one configurable service.
- Keep Top-Serveurs and Top-Games nickname ledgers separate until an administrator binds each nickname to a Steam ID.
- Use the authenticated Steam ID returned by Rust-Servers.net when its Steam ranking feed supplies one.
- Expose a stable points API for player-facing integrations.
- Optionally mirror accepted points into Custom Rewards or Economics.
- Preserve accepted vote data before invoking an optional external reward effect.
How it helps
Vote System centralizes provider polling and attribution so server owners can build voting rewards without treating an untrusted display name as a Steam owner. Each provider has separate configuration, points, interval, and storage boundaries.
Key features
- Three independently enabled provider configurations.
- Empty tokens and disabled providers by default.
- Minimum polling interval enforcement and bounded point multipliers.
- Provider-specific nickname-to-Steam bindings for Top-Serveurs and Top-Games.
- Authenticated Steam ledger for Rust-Servers.net.
- Checked point arithmetic and durable wipe generations.
- Optional Custom Rewards and Economics effects.
- Clear warnings for unbound votes and post-save effects that require administrator review.
How it works
Top-Serveurs and Top-Games historical feeds return a provider nickname but do not authenticate its Steam owner in the vote list. Vote System records that nickname's vote, then applies owner-scoped points only when the administrator has configured a binding for that provider.
Rust-Servers.net is different: the configured request asks for Steam ranking, and only a valid steamid returned by the provider enters the authenticated Steam ledger. A nickname-only row is rejected.
votesystem.wipe
The administrator console command begins a durable wipe generation, captures a fresh Rust-Servers.net baseline when that provider is enabled, and resumes polling only after the new state is stored.
Requirements and compatibility
- Rust server using Oxide or Carbon.
- Provider account and token for every feed you choose to enable.
- Optional Custom Rewards for owner-point mirroring and reward UI integrations.
- Optional Economics for deposits.
- Vote Reward is an optional separate product that supplies the familiar player chat commands and opens the Custom Rewards UI.
Provider accounts, availability, rules, and pricing are owned by their respective provider. They are not included with Vote System. Review the current provider terms and any free access or charges before enabling a feed.
Setup
- Install VoteSystem.cs in the framework plugin directory.
- Keep all providers disabled while reviewing the generated configuration.
- Obtain each API token directly from the provider and store it only in the server configuration.
- For Top-Serveurs or Top-Games, add reviewed nickname-to-Steam bindings before expecting owner-scoped points.
- Decide whether Custom Rewards and Economics should be enabled; disable any integration you do not use.
- Back up the oxide/data/VoteSystem directory.
- Enable one provider at a time and watch the server log for validation or attribution warnings.
Commands and permissions
CommandPurposeAuthorization
votesystem.wipeStart a durable vote-baseline resetRust administrator or votesystem.admin
votesystem_wipeHistorical compatibility alias for the same operationRust administrator or votesystem.admin
Vote System has no player chat command. Install Vote Reward only if you want the historical /vote-style command layer.
Configuration highlights
The following example keeps all providers disabled until tokens, bindings, and integrations have been reviewed:
{ "Data Version": 2, "Plugin Extensions": { "CustomRewards": { "Enabled": true, "Custom Rewards Template Name": "VoteSystem" }, "Economics": { "Enabled": false, "Multiplicator": 100 } }, "Vote Servers Settings": { "TopServer": { "Enabled": false, "API Token": "", "Points by vote": 1, "Nickname to Steam ID bindings": { "provider nickname": "76561198000000000" }, "Routine Settings": { "Check Interval (seconds)": 30 } } } }
Bindings are provider-specific. Multiple nicknames may map to one Steam ID, but changing a binding later reallocates that nickname ledger's existing balance. Review ownership before enabling the provider and avoid later reassignment.
Practical tutorials
Tutorial: enable Top-Serveurs safely
- Back up oxide/data/VoteSystem.
- Add the Top-Serveurs token and keep the provider disabled.
- Add every known provider nickname to Nickname to Steam ID bindings.
- Confirm each value is the intended 17-digit Steam ID.
- Set a positive points value and an interval of at least 15 seconds.
- Enable Top-Serveurs and monitor the first responses.
- Treat an unbound-vote warning as an attribution task; the vote is stored but creates no owner-scoped reward.
Tutorial: enable Rust-Servers.net
- Configure the provider token and keep the shipped Steam-ranking URL.
- Verify that Steam OpenID voting is enabled on the provider side.
- Leave nickname bindings empty; Rust-Servers.net attribution uses the returned authenticated Steam ID.
- Enable the provider and confirm that invalid or nickname-only rows are rejected.
- Run the administrator wipe command only when you intend to capture a new baseline.
Recovery tutorial
Stop polling before recovery. Restore the last known-good oxide/data/VoteSystem backup, including the wipe epoch and player vote files, then reload the plugin. Do not merge nickname and Steam ledgers or rename files to force ownership.
Provider data and privacy
Vote System sends the configured provider URL, server token, and request parameters to the selected provider. It receives vote identities and counts defined by that provider's response. It does not send Custom Rewards catalogues, Economics balances, server chat, or unrelated player data.
Tokens remain in local configuration and should be redacted from logs and support messages. Vote ledgers remain on the server. The plugin does not provide a provider account or change a provider's privacy policy.
Limits and failure behavior
- Providers are disabled when configuration is invalid.
- Unsafe identities, malformed JSON, stale periods, negative values, and arithmetic overflow are rejected.
- An unbound Top-Serveurs or Top-Games vote is stored but has no owner-scoped effect.
- Accepted state is stored before optional hooks or Economics deposits.
- A failed optional effect is not retried automatically because retrying could duplicate a deposit; the log supplies a reconciliation key.
- Provider caching, rate limits, outages, and response changes remain external to the plugin.
Troubleshooting
- A provider stays disabled: verify its token, URL, interval, and positive points value.
- Top votes are stored but points remain zero: add the missing provider-specific nickname binding.
- Rust-Servers.net rows are rejected: confirm the feed returns a valid authenticated steamid and uses Steam ranking.
- Economics did not deposit: check the reconciliation warning before making a manual adjustment.
- Polling does not resume after a wipe: restore or repair the wipe state and obtain a valid Rust-Servers.net baseline.
FAQ
Are display names matched automatically?
No. Top-Serveurs and Top-Games require administrator bindings. Numeric-looking nicknames are not treated as Steam IDs.
Does every accepted vote grant an Economics deposit?
Only when the provider identity is owner-scoped, Economics is enabled, and the deposit call succeeds after the vote is stored.
Was every real provider validated live?
No. A real provider request was not executed for every supported provider during the final historical validation.
Support
Use the Codefling support section with the plugin version, framework, provider name, redacted error, and whether the identity was a provider nickname or authenticated Steam ID. Never include provider tokens or full player ledgers.