MCSkylines-Government

Configuration defaults: Values shown for operator-configurable settings are the bundled defaults, and can be changed in the module’s configuration or definitions. The server’s active settings take precedence, so costs, speeds, ranges, durations, chances, effects, recipes, limits and enabled features may differ. Command examples illustrate syntax; fixed mechanics and validation bounds are not configuration defaults.

Government owns job categories/ranks, offers, department management, duty, salary policy, exams, prefixes, elections, terms, succession and recalls. LuckPerms is authoritative for current membership; SQLite stores workflow/history. Install required groups named in the YAML definitions before using them.

Job rules

Each job maps to one LuckPerms group. A player may hold one non-exempt job per configured category. Assigning a new non-exempt job removes only configured, non-exempt groups in the same category. Unrelated LuckPerms groups and nodes are never touched.

limit-exempt: true makes a configured appointment not count against its category. The inherited permission government.jobs.limit-exempt provides a personal bypass when a server needs a broader exception.

Management requires:

1. government.manage.track.<target-track> (or government.admin), and
2. at least one current job whose configured management scope contains the target rank.

This permits a mayor rank to manage a police commissioner while preventing the mayor from directly managing ordinary police ranks unless the configuration explicitly allows it.

Exams and stations

Define an exam under exams in jobs.yml, look at a sign, and run:

/government station exam <exam>

Right-clicking that sign opens the exam. Correct-answer indexes are zero-based. Passing assigns pass-job and may execute the configured console commands after replacing <player> and <uuid>.

Look at a lectern and run:

/government station poll

Right-clicking that lectern lists open elections. Ordinary voters do not receive a remote voting command.

Ballot privacy

The current voter ledger and ballot payloads are separate tables. Election staff may use /government election ballots <key> and /government election count <key> to inspect anonymous ballots and aggregates. Only government.election.audit may correlate a random ballot UUID with its voter through /government election audit-ballot <key> <ballot-uuid>. Replaced ballot revisions remain in the administrator audit mapping but are marked superseded and never counted.

As with any server-side voting system, a person with direct filesystem/database access is ultimately trusted.

Chat prefix selection

Players use /about display <job> or click one of their own jobs in /about. With PlaceholderAPI installed, Carbon can use:

%government_job_prefix%%player_name%: %message%

Available values are job, job_key, job_prefix, job_category, job_track, and job_rank. LUCKPERMS_PERSONAL prefix mode is also available but should be used only when the existing LuckPerms meta stack is understood; the plugin removes only exact configured prefixes at its configured priority.

Economy integration

When Economy is installed and salary payments are enabled, payroll runs once per configured real-world day. Salary calculation follows: individual override, then database rank override, then the configured job salary. Each job may map to a treasury or department account. Economy enforces its configurable payroll attendance threshold (default 15 online minutes within the prior 24 hours), tax/debt withholding, idempotency, and arrears. Without an economy adapter, Government continues operating but does not pay salaries. Other plugins can obtain GovernmentApi from Bukkit's services manager.

Configuration

• config.yml — storage, offers, job limits, prefix behavior, salary schedule metadata, election scheduling, recall timing, and security limits
• jobs.yml — categories, tracks, rank order, management scopes, LuckPerms groups, salaries, prefixes, exemptions, and exams
• elections.yml — offices, groups, seat counts, methods, terms, candidacy requirements, voting permissions, succession, and referendum defaults
• guis.yml — reserved GUI presentation settings
• messages.yml — MiniMessage user-facing text
• data.db — offers, salary overrides, display selections, exams, stations, elections, candidates, ballots, terms, recalls, vacancies, and audits

Configuration reload is all-or-nothing. A database path change requires a restart. Keys must be lowercase-safe identifiers; durations support s, m, h, d, w, mo, and y, including compounds such as 1d12h.

Launch a job department

1. Define the category, track, rank order, LuckPerms group, salary, prefix, and management scopes in jobs.yml.
2. Create every referenced LuckPerms group before assigning players. Government treats LuckPerms as current membership authority and does not mirror membership into SQLite.
3. Grant managers both the dynamic government.manage.track.<track> node and a job whose configured scope reaches the target rank. Permission alone is not enough unless government.admin is used.
4. Test an offer from creation through acceptance and expiry. Acceptance rechecks the player's current groups and replaces only configured, non-exempt jobs in the same category.
5. Map salary funding to the correct treasury or department account and verify the Economy attendance requirement and budget before relying on payroll.

Use exemptions for appointments that should coexist with an ordinary category job. A personal government.jobs.limit-exempt permission is broader than a configured exempt job and should be reserved for deliberate exceptions.

Build and test an entrance exam

Define the exam questions, zero-based correct answers, pass score, cooldown, awarded job, and optional completion commands in jobs.yml. Look at the sign that should become the station and run /government station exam <exam>. Players right-click that bound sign to begin; passing applies the configured job and then executes approved console commands with player placeholders.

Test every answer index, the exact pass boundary, cooldown behavior, a player whose current category job must be replaced, and a player who no longer qualifies at completion time.

Run an election from declaration to certification

1. Define the office in elections.yml, including its LuckPerms group, seats, voting permission, method, term, candidacy requirements, succession, and referendum defaults.
2. Register at least one lectern poll station with /government station poll. Ordinary voters vote through a station, not a remote command.
3. Create the election with its declaration, opening, duration, seat, and ballot-revision settings.
4. Let candidates declare or have staff add them. Eligibility and configured active-play requirements are checked.
5. Open a poll station as multiple eligible test voters. Confirm one UUID-unique ballot per voter and, when enabled, that a revision supersedes rather than double-counts the prior ballot.
6. Close and count the election. Inspect anonymous ballot output and recorded rounds before certification.
7. Certify only after quorum and result checks. Certification changes office groups, creates terms, removes outgoing certified holders, and applies normal category replacement rules.

For two-round voting, create the runoff from the reported finalists. For IRV and STV, retain the round records so recounts are explainable. A referendum tied exactly at the threshold resolves to the status quo NO. A failed-quorum election cannot be certified.

Recalls, vacancies, and succession

Create a recall against an active term, collect the configured number of unique signatures before expiry, and allow Government to schedule the secret recall referendum. Certifying YES vacates the term and applies the office's configured succession. Test ordinary term expiry and manual vacancy handling on staging as well; election groups should never be managed by ad-hoc LuckPerms commands during an active certification workflow.

Privacy and audit boundaries

Election staff can inspect anonymous ballots and aggregates. Only government.election.audit can correlate a random ballot UUID with a voter, including superseded revisions. Limit that permission to the smallest trusted group. Direct database/filesystem administrators remain part of the system's trust boundary.

Infrastructure department permissions

For Utilities, assign utilities.grid.connect to infrastructure staff who connect/disconnect meters and register lamps. Grant utilities.grid.manage separately for creating grids and utilities.plots.manage for approving machinery plots. These permissions do not grant access to private machine inventory. Owners grant machine operators separately.

Batteries, reservoirs, and fuel reserves must be supplied by players. Government can own and fund reserves through gameplay; Utilities does not add automatic treasury billing or an NPC emergency supply.

Duty and salary

/duty <track> begins active service in an employed government track without changing the underlying job. When already on duty, /duty ends service without a track argument. Department/fire dispatch can use duty state. Rank salaries and individual overrides are policies; Economy handles funded daily payroll and online-time eligibility. Track management needs both its permission and a configured rank scope, not just a broad job title.

Election methods and voter workflow

Voters right-click a registered polling lectern and select an open ballot. Choices retain selection across pages; submit is in the footer. One UUID owns one ballot, with revisions only if enabled. FPTP selects a single choice; approval accepts multiple choices; two-round can require a separately created runoff; IRV eliminates/transfers rankings; STV allocates multiple seats by fractional transfer with Droop quota; referendum records YES/NO and enforces quorum/approval thresholds. Count stores recountable rounds and deterministic ties; referendum ties preserve NO/status quo. Certification awards groups/terms and removes outgoing certified officeholders. Quorum failure is not certifiable.

Web elections and remote-voting policy

The City desktop consumes GovernmentPanelApi through Technology's authenticated server bridge. It uses the same elections, candidates, eligibility permissions, voting methods, voter ledger, secret-ballot records and ballot revision rules as polling stations. Browser activity does not earn playtime, duty pay or candidacy qualification. The game server must remain running even when the voter is offline.

Remote voting starts disabled. Assign government.remote-voting.manage to the authorized government group to change it in the Government application, with a 1–500 character reason. Each change records actor, previous/new value, reason and time. Drafting/enacting a law alone does not change the policy. When disabled, web ballots are blocked and players use a polling station; there is no illegal remote vote mechanic. Existing accepted ballots are retained.

Policy, current election status and the opening/closing schedule are rechecked in the serialized ballot transaction. A stale open browser cannot bypass a policy revocation or an election moving to counting. Retrying the same immutable submission returns its accepted ballot, while altered submissions are rejected. Web and polling-station votes cannot count independently for the same voter.

The panel uses static server-context LuckPerms permissions, including each office's configured voter permission. government.vote retains its default basic access; custom undefined voter nodes do not grant eligibility. Explicit false overrides operator fallback. Missing bridge/authority stops protected operations.

Government's SQLite schema is 5. Retain the startup backup and back up the live module database before upgrading; rollback to older code needs the older database backup. Configure the separate web service using the backend guide; no website process should open Government's SQLite file or submit console commands to vote.

Reading command syntax

Configuration defaults: Values shown for operator-configurable settings are the bundled defaults, and can be changed in the module’s configuration or definitions. The server’s active settings take precedence, so costs, speeds, ranges, durations, chances, effects, recipes, limits and enabled features may differ. Command examples illustrate syntax; fixed mechanics and validation bounds are not configuration defaults.

<argument> is required; [argument] is optional. Replace the placeholder, including its brackets, with your value. Choices separated by a vertical bar mean choose one. ... accepts the remaining words. Do not type quotation marks around multiword names unless the command specifically requires them. A bare command has no required arguments. Examples use sample players/IDs: substitute entries from your server and use Tab for configured IDs.

player means a username; operational actions usually require that player online. amount and price are currency values such as 25.00, unless the row specifies items, levels, or units. reason, memo, message, name, and statement accept text where supported. duration uses the module's duration format (for example 10m, 2h, or 7d); it is not a bare number of minutes unless stated. id is the exact identifier displayed by that system, not its friendly name. Permissions and ownership/state/location checks both apply.

Jobs, stations, and duty commands

job, track and exam come from jobs.yml. Salary amount is a currency policy, not a payment immediately minted. Examples: /government hire Alex police_officer New recruit; /government station exam police_exam with your own configured IDs.

Election commands and arguments

Election management requires government.electioneer or admin; declaration/signing/voting retain eligibility checks. Delays and duration use formatted times such as 10m, 1h, 2d. Keys are configured-safe unique IDs; term and recall IDs come from records. Percentages are numeric percentages; revisions is true or false.

Example: /government election referendum roads 1h 2h 40 50 false Approve the road budget?. This is a server gameplay election, and values should match the configured office/voter policy.

Root commands and aliases

These are the registered command entry points. The subcommand tables above describe their complete operations. Alias names use the same arguments as their root.