Configuring Simulator Parameters
From OpenSimulator
m (Robot: Cosmetic changes) |
m (Robot: Replacing 'OpenSim' to 'OpenSimulator', which is the precise name) |
||
Line 7: | Line 7: | ||
Configuration files can include other configuration files. For instance, a standard standalone configuration will read the following INI files (you can see this order early on in the log and on the console). | Configuration files can include other configuration files. For instance, a standard standalone configuration will read the following INI files (you can see this order early on in the log and on the console). | ||
− | OpenSimDefaults.ini ( | + | OpenSimDefaults.ini (OpenSimulator 0.7.1 and onwards) |
OpenSim.ini | OpenSim.ini | ||
config-include/Standalone.ini | config-include/Standalone.ini | ||
Line 14: | Line 14: | ||
config-include/storage/SQLiteStandalone.ini | config-include/storage/SQLiteStandalone.ini | ||
− | OpenSimDefaults.ini (on | + | OpenSimDefaults.ini (on OpenSimulator 0.7.1 and later) and OpenSim.ini are always checked for on startup. However, the other INI files are loaded as a result of include directives within the preceding INI files. |
− | For instance, at the bottom of the OpenSim.ini file in the [Architecture] section, there are a number of possible architectural includes. For example, a default | + | For instance, at the bottom of the OpenSim.ini file in the [Architecture] section, there are a number of possible architectural includes. For example, a default OpenSimulator 0.7.1 standalone setup will have |
[Architecture] | [Architecture] | ||
Line 50: | Line 50: | ||
The config parameters follow each section. Each has the structure <parameter> = <value> (e.g. whisper_distance = 10). | The config parameters follow each section. Each has the structure <parameter> = <value> (e.g. whisper_distance = 10). | ||
− | In OpenSim.ini.example, if a parameter is commented out with a preceding semicolon (;), then the value in OpenSimDefaults.ini is used instead (in | + | In OpenSim.ini.example, if a parameter is commented out with a preceding semicolon (;), then the value in OpenSimDefaults.ini is used instead (in OpenSimulator 0.7.1 and later) or a default value within OpenSimulator itself. |
To change a parameter, one would uncomment it and edit the value. For instance, if I wanted whisper distance to be 50 meters in my sim, I would change OpenSim.ini so that it had. | To change a parameter, one would uncomment it and edit the value. For instance, if I wanted whisper distance to be 50 meters in my sim, I would change OpenSim.ini so that it had. | ||
Line 59: | Line 59: | ||
When the sim was next started up, the whisper distance would be 50m, overriding any value in OpenSimDefaults.ini if it exists. | When the sim was next started up, the whisper distance would be 50m, overriding any value in OpenSimDefaults.ini if it exists. | ||
− | In | + | In OpenSimulator 0.7.1 and later, we recommend that parameters are changed in OpenSim.ini and not in OpenSimDefaults.ini. This is because various parameters are added or can change name between releases. Common parameters to change are already in OpenSim.ini.example - OpenSimDefaults.ini contains both defaults for these parameters and more obscure ones. If you want override a parameter that is in OpenSimDefaults.ini but not OpenSim.ini.example then we recommend that you copy the relevant section to OpenSim.ini and change it there. |
= Aggregation and Overriding = | = Aggregation and Overriding = | ||
Line 69: | Line 69: | ||
On the simulator's console command line, you can get information about what parameters it's actually using with the "config show" command. This is handy if you want to check that the simulator has loaded the parameters that you want. | On the simulator's console command line, you can get information about what parameters it's actually using with the "config show" command. This is handy if you want to check that the simulator has loaded the parameters that you want. | ||
− | = Using shell environment variables in | + | = Using shell environment variables in OpenSimulator configuration = |
We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign. | We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign. | ||
Line 88: | Line 88: | ||
<source lang="ini"> | <source lang="ini"> | ||
[Environment] ; Our Environment section that defines the shell variables we are interested in | [Environment] ; Our Environment section that defines the shell variables we are interested in | ||
− | RT_ZONE="" ; We might use a zone to setup an instance of | + | RT_ZONE="" ; We might use a zone to setup an instance of OpenSimulator on a server |
HOSTNAME="" ; We might be interested in obtaining the host's name | HOSTNAME="" ; We might be interested in obtaining the host's name | ||
Line 101: | Line 101: | ||
− | When | + | When OpenSimulator picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ... |
<source lang="ini"> | <source lang="ini"> | ||
[Environment] ; Our Environment section that defines the shell variables we are interested in | [Environment] ; Our Environment section that defines the shell variables we are interested in | ||
− | RT_ZONE="" ; We might use a zone to setup an instance of | + | RT_ZONE="" ; We might use a zone to setup an instance of OpenSimulator on a server |
HOSTNAME="" ; We might be interested in obtaining the host's name | HOSTNAME="" ; We might be interested in obtaining the host's name | ||
Revision as of 22:17, 3 March 2012
Contents |
Structure
OpenSimulator has a fairly complicated configuration structure based on Windows style INI files. This is to accomodate its many different uses and possible architectures.
Configuration files can include other configuration files. For instance, a standard standalone configuration will read the following INI files (you can see this order early on in the log and on the console).
OpenSimDefaults.ini (OpenSimulator 0.7.1 and onwards) OpenSim.ini config-include/Standalone.ini config-include/StandaloneCommon.ini config-include/CenomeCache.ini (not found on a default setup) config-include/storage/SQLiteStandalone.ini
OpenSimDefaults.ini (on OpenSimulator 0.7.1 and later) and OpenSim.ini are always checked for on startup. However, the other INI files are loaded as a result of include directives within the preceding INI files.
For instance, at the bottom of the OpenSim.ini file in the [Architecture] section, there are a number of possible architectural includes. For example, a default OpenSimulator 0.7.1 standalone setup will have
[Architecture] Include-Architecture = "config-include/Standalone.ini" ; Include-Architecture = "config-include/StandaloneHypergrid.ini" ; Include-Architecture = "config-include/Grid.ini" ; Include-Architecture = "config-include/GridHypergrid.ini" ; Include-Architecture = "config-include/SimianGrid.ini" ; Include-Architecture = "config-include/HyperSimianGrid.ini"
Lines that start with at least one semicolon (;) are commented out and are not active in the configuration. In this case, when OpenSimulator reads OpenSim.ini it will then go on to read config-include/Standalone.ini, which in turn includes config-include/StandaloneCommon.ini and so on.
If a config file isn't found then it is ignored and it's non-existence is logged.
The OpenSim.ini and OpenSimDefaults.ini files in bin/ concern simulator parameters (chat distance, physics, etc.). The parameters in config-include control the location and parameters of data services (e.g. region database, asset service, inventory service).
Changing Simulator Settings
A configuration file consists of a number of sections, each starting with the name of that section in brackets ([]). For instance, in OpenSim.ini.example you have (ignore the descriptive text)
[Startup] ; save_crashes = false ; crash_dir = "crashes" ...
[SMTP] ; enabled = false ...
[Chat] ; whisper_distance = 10
The config parameters follow each section. Each has the structure <parameter> = <value> (e.g. whisper_distance = 10).
In OpenSim.ini.example, if a parameter is commented out with a preceding semicolon (;), then the value in OpenSimDefaults.ini is used instead (in OpenSimulator 0.7.1 and later) or a default value within OpenSimulator itself.
To change a parameter, one would uncomment it and edit the value. For instance, if I wanted whisper distance to be 50 meters in my sim, I would change OpenSim.ini so that it had.
[Chat] whisper_distance = 50
When the sim was next started up, the whisper distance would be 50m, overriding any value in OpenSimDefaults.ini if it exists.
In OpenSimulator 0.7.1 and later, we recommend that parameters are changed in OpenSim.ini and not in OpenSimDefaults.ini. This is because various parameters are added or can change name between releases. Common parameters to change are already in OpenSim.ini.example - OpenSimDefaults.ini contains both defaults for these parameters and more obscure ones. If you want override a parameter that is in OpenSimDefaults.ini but not OpenSim.ini.example then we recommend that you copy the relevant section to OpenSim.ini and change it there.
Aggregation and Overriding
As we saw above, when multiple config files have the same section, the settings are aggregated. If a later setting has the same name as an earlier setting, then the later setting overrides the earlier setting.
Getting information about parameters
On the simulator's console command line, you can get information about what parameters it's actually using with the "config show" command. This is handy if you want to check that the simulator has loaded the parameters that you want.
Using shell environment variables in OpenSimulator configuration
We will need to use two new things in our configurations: a section [Environment] to tell us what variables we need to look at in the shell and we will need to use the Nini key expansion. Nini, can have keys that look like ${SECTION|VARIABLE} and can expand those to the variables we assign.
In your shell you will export your values and check the ones you want to use that are predefined by your system ...
export RT_ZONE=Zone_00
# You can see your HOSTNAME (It will be set by the system)... echo $HOSTNAME OSERV_00
In the ini you will include an [Environment] section...
[Environment] ; Our Environment section that defines the shell variables we are interested in RT_ZONE="" ; We might use a zone to setup an instance of OpenSimulator on a server HOSTNAME="" ; We might be interested in obtaining the host's name [Startup] regionload_regionsdir=/home/opensim/etc/Regions/${Environment|RT_ZONE}/ ; We set our regionload_regionsdir using the variables ConsolePrompt = "${Environment|HOSTNAME}:${Environment|RT_ZONE} " [DatabaseService] ConnectionString = "Data Source=localhost;Database=${Environment|RT_ZONE};User ID=username;Password=userpass;" ; Here too
When OpenSimulator picks up the variables in your shell and processes all the configurations, the variable keys will be filled in with the variables picked up from the shell ...
[Environment] ; Our Environment section that defines the shell variables we are interested in RT_ZONE="" ; We might use a zone to setup an instance of OpenSimulator on a server HOSTNAME="" ; We might be interested in obtaining the host's name [Startup] regionload_regionsdir=/home/opensim/etc/Regions/Zone_00/ ; We set our regionload_regionsdir using the variables ConsolePrompt = "OSERV_00:Zone_09 " [DatabaseService] ConnectionString = "Data Source=localhost;Database=Zone_00;User ID=username;Password=userpass;" ; Here too