Configuration#

VSU has one properties file with four integer settings. Everything else is either fixed behaviour or lives in kits.json and the SQLite database.

File: config/vonix_server_utilities.properties, written with defaults on first launch.

# Vonix Server Utilities Configuration
# Maximum homes per player
max_homes=5
# Seconds before a TPA request expires
tpa_timeout_seconds=120
# Seconds after death before /backdeath is usable (0 = instant)
death_back_delay_seconds=0

# Minutes of playtime required for each automatic Playtime Key.
playtime_key_interval_minutes=60

Keys#

All four are read with Integer.parseInt on the trimmed value. A value that does not parse falls back to the default for that key with no error beyond a debug-level absence of the setting; the server starts normally.

max_homes#

/sethome counts existing homes for the player and refuses a new name once the count reaches the limit. Overwriting an existing home always succeeds even at the cap, so a player at 5 homes can still move home without deleting anything first.

/homes prints the used and allowed counts, e.g. Your homes (3/5). The value is read from config each time a command runs, so a reload changes the limit without a restart. It does not retroactively delete homes above a lowered limit; they stay and remain usable, they simply cannot be added to.

The limit is global. There is no per-rank override and no permission-based home count.

tpa_timeout_seconds#

A request is stamped with the time it was created. When the target runs /tpaccept, the request is re-checked and refused if it is older than this value. A stale request also stops blocking a fresh one from the same sender.

There is no background task that sweeps expired requests: expiry is evaluated lazily on accept. That means an expired request still sitting in memory can make /tpa report "already has a pending request" until it is evaluated once. Setting the timeout very low shortens that window; it does not remove it.

Accepted values are multiplied by 1000 and stored as milliseconds; negative values produce an already-expired request, which is a way to disable TPA acceptance without disabling the command.

death_back_delay_seconds#

/backdeath compares the death timestamp against the current time and refuses with a countdown when the elapsed time is below this value. The delay applies per death, so dying again restarts the wait.

/back is unaffected. The two stores are separate: /back holds the last teleport origin, /backdeath holds the last death position, and neither overwrites the other. Both are persisted and survive a restart.

playtime_key_interval_minutes#

A tick task runs once per minute, reads each online player's vanilla playtime statistic, and grants one playtime key per completed interval that has not been awarded yet. Progress is stored, so this is cumulative rather than a per-session flush.

The value is clamped with Math.max(1, ...) at load time. A configured 0 or a negative number is read as 1, which is the most aggressive setting, not a disabled one. To make the system effectively dormant, set a very large value.

Interval awards apply only to online players. Time played before the mod was installed still counts, because the source is the vanilla statistic rather than a VSU counter — a player joining for the first time with 100 hours on record will receive every interval they have already completed in one pass.

Reload#

/vonixsu reload re-reads the properties file and then reloads kits.json. It requires vsu.admin.manage at operator level 3.

/vonixsu reload

What a reload does not do:

• It does not re-open the database. Schema and connection state are fixed at start.
• It does not reload crate definitions. Those are database rows, changed through /crate commands.
• It does not re-apply limits retroactively. For example, lowering max_homes leaves existing homes in place.
• It does not restart the expiry sweeper or clear the mute cache.

The reload is safe to run while players are online. There is a brief window where the kit map is being replaced, but claims are serialised against the database, so the worst case is a claim that resolves against the new file.

No remote configuration#

VSU 2.2.0 has no remote feature service, no HTTP client, and no configuration endpoint. Nothing polls a website, and no setting is fetched at runtime.

Two consequences worth stating plainly:

• /vonixsu status prints a fixed module list (homes, warps, kits, TPA, back, admin, world) as a label. It is not a capability report and it is not fetched from anywhere.
• The internal feature-gate keys that appear in command declarations are always open. They exist as compatibility labels; the only access control that runs is the permission gate described on Permissions.

If you find a guide describing a feature-sync command or a server-side config pull for VSU, it describes a build that no longer exists. The 2.2.0 changelog records the removal of the account-link, site, player-sync, and feature-polling paths.

What is not in this file#

Settings that people look for here and will not find:

The database path is not configurable: it is always config/vonix_server_utilities/data.db relative to the server directory.

Changing a value#

1. Edit the properties file.
2. Run /vonixsu reload from console or as an operator.
3. Confirm the Configuration reloaded. message.

A restart is equivalent and slightly safer if you are changing several values at once, because it also re-runs schema checks and cache hydration. If a value seems to have no effect after a reload, check the log for a reload failure and confirm you edited the file under the server's own directory rather than a client instance.

Restarting also re-reads kits.json and rehydrates homes, warps, nicknames, ignore lists, and back locations from the database, which is the clean way to recover from a partial edit.