Re-exports§
pub use admin::AdminRecord;pub use admin::Admins;pub use banlist::Ban;pub use banlist::BanEntry;pub use banlist::BanError;pub use banlist::BanErrorKind;pub use banlist::BanInfo;pub use banlist::BanKind;pub use banlist::BanOperation;pub use banlist::BanOperationError;pub use banlist::BanRecord;pub use banlist::Banlist;pub use server_description::ServerDescriptions;pub use whitelist::Whitelist;pub use whitelist::WhitelistInfo;pub use whitelist::WhitelistRecord;
Modules§
- admin
- Versioned admins settings files.
- banlist
- Versioned banlist settings files.
- editable 🔒
- server_
description - Versioned server description settings files.
- server_
physics - List of players which are not allowed to use client side physics, to punish abuse
- whitelist
- Versioned whitelist settings files.
Structs§
- Editable
Settings - Combines all the editable settings into one struct that is stored in the ecs
- Gameplay
Settings - Moderation
Settings - Settings
Enums§
- Calendar
Mode - Invalid
Settings Error - Protocol
- Server
Battle Mode - Setting
Error - Errors that can occur during edits to a settings file.
Constants§
- ADMINS_
FILENAME 🔒 - BANLIST_
FILENAME 🔒 - CONFIG_
DIR 🔒 - MIGRATION_
UPGRADE_ 🔒GUARANTEE - Our upgrade guarantee is that if validation succeeds for an old version, then migration to the next version must always succeed and produce a valid settings file for that version (if we need to change this in the future, it should require careful discussion). Therefore, we would normally panic if the upgrade produced an invalid settings file, which we would perform by doing the following post-validation (example is given for a hypothetical upgrade from Whitelist_V1 to Whitelist_V2):
- SERVER_
DESCRIPTION_ 🔒FILENAME - SERVER_
PHYSICS_ 🔒FORCE_ FILENAME - SETTINGS_
FILENAME 🔒 - SINGLEPLAYER_
SERVER_ NAME - WHITELIST_
FILENAME 🔒