Configuration¶
Understanding Syntax¶
In this manual commands or paths may be written in a certain style that tells how to use it.
Note that the style itself is not written, but it's used as an indicator to tell if a parameter is optional or not.
Example syntax of a command:
zr_class_modify <classname|"zombies"|"humans"|"admins"> <attribute> <value> [is_multiplier]
Some paths may look like:
cfg/sourcemod/zombiereloaded/<mapname>.cfg
How to read syntaxes like this is explained below.
Optional Parameters¶
Optional parameters is not required and usually have a default value or action. They are marked with brackets.
Example:
zr_somecommand [number]
Usage examples:
zr_somecommand
zr_somecommand 10
Required Parameters¶
Required parameters must be specified for the command to function. Usually if no parameters are written the command replies with some info about the syntax.
Less than (<) and greather than (>) symbols marks required parameters.
Examples:
zr_somecommand <number>
zr_infect <target>
Usage examples:
zr_somecommand 100
zr_infect "unnamed"
Multiple Options In The Same Parameter¶
Some commands have parameters that support multiple pre defined options. Usually it's specifying a name, a index or a predefined value. Each option is separated by a "|" symbol. Only one of the options listed is used in a command.
Example:
zr_do_something <index|name|"all">
Usage examples:
zr_do_something 1
zr_do_something "all"
zr_do_something "unnamed"
Text As Parameters¶
Since parameters are separated by spaces, text (strings) should be quoted. It's a good habit to do this on all string parameters to avoid parsing mistakes.
Example:
zr_infect "unnamed" "player"
zr_do_something "example text. test."
Example of bad usage:
zr_do_something example text. test.
The last example actually have 3 parameters while it should be only one. This may cause unexpected results and is an example of why strings should be quoted.
Configuration Files¶
These are the default configuration files. The paths are relative to the "cstrike" folder.
Default Configuration Files Type: File: Main conf. cfg/sourcemod/zombiereloaded/zombiereloaded.cfg Map config. cfg/sourcemod/zombiereloaded/<mapname>.cfg Post map conf. cfg/sourcemod/zombiereloaded/<mapname>.post.cfg Hitgroup conf. addons/sourcemod/configs/zr/hitgroups.txt Class conf. addons/sourcemod/configs/zr/playerclasses.txt Weapon conf. addons/sourcemod/configs/zr/weapons.txt Download list addons/sourcemod/configs/zr/downloads.txt Model list addons/sourcemod/configs/zr/models.txt
The post map configuration file is executed after all features of ZR is done loading. Commands that modify loaded data must be put in post configuration files. How to configure each file is explained in their own sections.
Configuration files also can be reloaded in-game when testing or tuning stuff.
Configuration File Console Commands Syntax: zr_config_reload <file alias> Reloads a config file.
Parameters:
file alias The module to reload. Available options:
modelsdownloadsclassesweaponshitgroupszr_config_reloadall Reloads all config files.
Logging¶
The log system used in Zombie:Reloaded is pretty powerful and customizable. It's based on logging flags and a module filter.
The flags tell what kind of events to log. Those flags are stored as a numeric value in a bit field where each bit tell wether to log a certain event or not. See Bit field for technical details.
The module filter is a list of modules to enable log events from. This filter gives extra control of what stuff to log. Use console commands below in the main configuration file to add or remove modules to the filter.
These commands might not work properly until bug 3828 in SourceMod is fixed. It's a bug where console commands in plugin configuration files are executed late so a command like zr_log_add_module is too late.
There are console variables for different log settings and exceptions. Place them in the main configuration file.
Log Console variables Console variable: Default: zr_log "1" Enable logging of events in the plugin. Fatal errors or errors are independendt on this setting and always logged.
Options:
0 or 1zr_log_flags "2" A bit field that specify what event types to log.
Options:
Number - See Log Flags (3.3.1)zr_log_module_filter "0" Enable module filtering. Only log events from listed modules will be logged. Use console commands below to add or remove modules from the filter.
Options:
0 or 1zr_log_ignore_console "1" Don't log events triggered by console that are executed by the console itself, like commands in configs. Enable this command to avoid spamming logs with events like weapon restrictions.
Options:
0 or 1zr_log_error_override "1" Always log error messages no matter what logging flags or modules filters that are enabled.
Options:
0 or 1zr_log_print_admins "0" Print log events to admin chat in addition to the log file.
Options:
0 or 1zr_log_print_chat "0" Print log events to public chat in addition to the log file.
Options:
0 or 1
Log Console commands Syntax: zr_log_add_module <module> [modules...] Adds one or more modules to the module filter. Use short module names, see List Of Modules (3.3.2).
Parameters:
module Name of the module to add. modules Additional modules to add. zr_log_remove_module <module> [modules...] Removes one or more modules from the module filter. Use short module names, see List Of Modules (3.3.2).
Parameters:
module Name of the module to remove. modules Additional modules to remove. zr_log_list Lists current log flag settings and module filtering settings.
Log Flags¶
Log Flags Flag: Bit No.: Value: Description: LOG_CORE_EVENTS 1 1 Log events from the plugin core like config validation and other messages. LOG_GAME_EVENTS 2 2 Log admin commands, console commands, and game related events from modules like, suicide attempts and weapon restrictions. LOG_PLAYER_COMMANDS 3 4 Log events that are triggered by players, like chat triggers, teleporting and class changes. LOG_DEBUG 4 8 Log debug messages, if any. Usually only developers need to enable this log flag. LOG_DEBUG_DETAIL 5 16 Log additional debug messages with more details. May cause spam depending on module filter settings. Usually only developers need to enable this log flag.
To combine several logging flags use the sum of their values. A combination could be "3", which is these log flags:
LOG_CORE_EVENTS + LOG_GAME_EVENTS
1 + 2
Most server setups donesn't need different flag settings. Default is fine.
To decode the value you must convert it from decimals to binary, and count from right to left what bits that are 1. Look up the bit number (not value) in the table above.
As an example on using the number 11 it's 1011 in binary. Counting from right we see that the following bit numbers are on: 1, 2, and 4. That is the flags:
LOG_CORE_EVENTS + LOG_GAME_EVENTS + LOG_DEBUG
1 + 2 + 8
Most operating systems or distributions have a calculator that can convert between binary and decimal numbers with scientific mode enabled. An online unit converter like below can also be used.
List Of Modules¶
List Of Modules Short name: Description: account Money manager antistick Anti-Stick feature config Configuration file manager cvars Console variables damage Damage manager downloads File download manager hitgroups Hit group feature infect Infection manager models Model list file manager playerclasses Class manager veffects Visual effect manager seffects Sound effect manager tools Helper functions (offsets) volfeatures Volumetric features weapons Weapon manager weaponrestrict Weapon restriction manager zspawn Spawn command manager ztele Teleport manager
Custom Map Configuration Files¶
Configuration files for each map is supported. They're executed after the main configuration files are executed, and are ideal for customizing map settings. These files are just regular configuration files and can also have standard console commands like setting map time. Map configuration files are optional.
The main purpose of these files is to make it possible to change settings for Zombie:Reloaded on certain maps. That could be scaling knockback, restricting certain weapons, changing class attributes or changing ambience sound.
Other map configuration plugins should also work if certain features that doesn't exist in Zombie:Reloaded map configurations is needed.
Types¶
There are two kinds of map configs; pre and post. Pre map configuration files are executed before the modules and data is loaded. They're useful for changing configuration sets for certain modules like classes. Post map configuration files are executed after the modules are loaded. Certain stuff have to be placed in this one to be effective, like changing class attributes.
Map Configuration File Types Type: Executed: Path: Pre Before modules and data loading cfg/sourcemod/zombiereloaded/<mapname>.cfg Post After modules cfg/sourcemod/zombiereloaded/<mapname>.post.cfg
If not explicit specified in the module documentation, use pre configuration.
Model Configuration¶
The model configuration file is a list of models used on the server stored in Valve's key/value format.
The models listed in this file are also precached when the server starts. Custom models used, but not listed in this file will cause a "model not precached" error on the server, so they must be listed in this file.
In addition models can be restricted to certain groups using the "access" attribute.
List of available model attributes:
Model Attributes Attribute: Value type: name text File name of model file, without extension.
path text Path to model files. Must end with "/". Windows servers can use "\" in paths, but they also work with "/".
The path is relative to "cstrike".
team text What team the model belongs to.
Options:
zombies Zombie players. Includes mother zombies. humans Human players. access text Access mode of the model.
Options:
public Everyone can use the model. Included in public random selections. admins Model can only be used by admins. Included in public random selections but only applied to admins. hidden Model is excluded from public random selections. motherzombies Model can only be used by mother zombies. group Use group authentication. See "group" attribute. group text Name of SourceMod group to use for model authentication if access is "group". If access is anything else than "group" this setting is ignored and can be blank ("").
Only players that is a member of this group can use this model. Root admins can't use this model if they're not a member.
For example usages see examples in default model configuration.
Put the list of models in:
addons/sourcemod/configs/zr/models.txt
Download List¶
Custom materials and overlays must be listed in the download list so clients will download them. Use one line per file, with paths relative to the "cstrike" folder.
List files to be downloaded in the following file:
addons/sourcemod/configs/zr/downloads.txt
Look at the default downloads in that file for an example on how to list files to be downloaded.
Note: The ambience sound file doesn't need to be listed.