Vote System

VoteSystem

Beta 2.1.6. The LTS version published on Codefling remains 2.1.5. Downloading the plugin requires sign-in and a verified entitlement for the requested version. Check its product page for available access. Configuration exports remain available without buying the plugin.

VoteSystem checks Top-Serveurs, Top-Games and RustServers for server votes. It tracks each player's vote points and can make them available to CustomRewards or deposit a reward through Economics. Both integrations are optional.

Version 2.1.6. Install VoteSystem.cs in oxide/plugins/. Do not install the separate files under src/.

In the configurator

Voting sites summarizes the three providers: status and points per vote. Click Configure to enter a site’s token and public voting page. The technical API address stays collapsed; change it only if the provider requires it. Integrations and check frequency have their own tabs.

Set up voting

All providers are disabled initially. In oxide/config/VoteSystem.json, select the providers you use, enter their API tokens, set points per vote, then enable them. Keep tokens private. The polling interval must be at least 15 seconds.

For TopServer and TopGames, players enter their SteamID64 in the voting site's nickname/player-name field. Points are assigned to that Steam account automatically. No administrator nickname dictionary is required.

If you want players to vote using their server nickname instead, set `Enable nickname votes` to `true` for that provider. VoteSystem matches the exact name of a player known to the Rust server; it does not use partial name searches. If two accounts have that name, the vote waits rather than choosing one. New unresolved votes are kept and retried at the next provider check or when the player joins.

Nickname voting is less reliable: a freely entered nickname does not prove who cast the vote. Someone can vote for another player's name. Use SteamID64 voting if you do not want that ambiguity. Neither mode proves Steam OpenID authentication on Top-Serveurs or Top-Games.

RustServers keeps its existing SteamID-based ranking workflow. Its API requires the voting site's Steam OpenID support; nickname-only rows are rejected. No new setting is needed for this provider.

Progression and voting links

Under Rewards and integrations, select Points to apply each provider’s points per vote, or Votes to count each vote once. The historical public points APIs keep their weighted behavior.

With VoteReward 2.2.0, use all three files from the same preset: VoteSystem 2.1.6, VoteReward 2.2.0 and the CustomRewards 2.2.0 catalogue. Select Votes in both VoteSystem and VoteReward; select external progression and the Votes display unit in CustomRewards.

Voting page is the public page players visit to vote. It is optional and separate from the private API endpoint: never include a token or API key. VoteReward can show these links through /votesites.

The new APIs expose vote totals and the last observed check state for each provider. Unavailable progress remains unavailable; it is not shown as zero. Observations contain no private API URL or token.

Rewards

• CustomRewards supplies the reward catalogue and item/command rewards. VoteSystem supplies the points, with reward type VoteSystem by default.
• Economics is optional. Disable its integration if you do not use that plugin; Multiplicator controls the deposit per accepted vote.
• Other plugins can use the existing VoteSystem point APIs and hooks. Contract version 1 and the vote-points-api capability remain unchanged.

Upgrading from a previous version

Back up the configuration and both oxide/data/VoteSystem/ and oxide/data/VoteSystem_nodelete/ before replacing the plugin.

Existing explicit nickname mappings are read once to transfer their recorded balances to the specified Steam account. Historical vote tokens are included so the same votes cannot be credited again. Successful mappings are removed from the configuration. Original nickname files remain untouched; no historic Economics payment or reward hook is replayed.

Previously unbound nickname balances are not assigned automatically, even if a player now uses that name. Raw files from pre-V2 releases are also kept, not guessed or imported. If migration reports an error, that provider is blocked until the original data is investigated; do not delete files just to silence the error.

Wipes and recovery

votesystem.wipe starts a durable wipe generation. votesystem_wipe remains its historical alias. Both require a Rust administrator or votesystem.admin. OnNewSave requests the same operation. Old callbacks are rejected and RustServers polling resumes after its fresh baseline is saved. Point APIs and CustomRewards grants remain unavailable while that baseline is pending.

TopServer/TopGames keep their existing lifetime totals. A new Top vote is journaled with its owner before the Steam counter is written. Replays, renames and restarts cannot move that recorded vote to another account. An unfinished vote from an earlier wipe is retained but not credited in the new wipe; committed balances are unchanged.

Top votes and their counters are saved atomically before hooks or deposits. RustServers publishes its copied cache state only after both required writes succeed; this is not an atomic transaction across files. If the files disagree after a restart, its points stay unavailable until the next successful check. External plugin effects are also not transactional: a crash after the counter is saved can miss a notification/payment. They are not automatically retried, to avoid double payment. Hooks and Economics deposits still require the player to be connected when the vote is accepted; stored vote points remain available when they return. Investigate a logged failure before reconciling anything manually.

For data maintenance, unload VoteSystem before editing or restoring its files, then reload it. The plugin caches state; changing files while it runs is unsupported. A missing, corrupt or replaced Steam ledger cannot be reconstructed by guessing from its ownership journals.

Offline compilation and focused tests cover the release files. Real provider responses, optional-plugin calls, wipe hook timing and gameplay effects still need a live-server smoke test.