The world INI file controls many options that cannot be changed from the World Features Dialog. This controls what universe the world will connect to, as well as who the world caretakers are. Generally, the world will need to be restarted for changes to the world.ini file to take effect.

If you are running a world in a universe other than the default Active Worlds Universe, you will need to modify the world.ini file to contain the location information of your universe server so that the world server can find it on startup. This process is also described in the installation instructions for the Active Worlds UniServer.

To specify a different universe, add a new section to the world.ini file called "[universe]", and under that add a new entry "host=" to specify the domain name or IP address of the universe server. For example:

[universe]

host=universe.mydomain.com

You can also specify an optional "port=" entry here if your universe is not running on the default port 5670:

port=1234

In addition to the options for connections and caretakers, please note there are also the following options:

[misc]

build_on_own_prop_only=1

encroach_caretakers=0

disallow_url_actions=1

neighbor_range=9000

neighbor_limit=50

If this value is set, users will only be able to place objects in a cell if they already own an object in that cell. This means that users can't claim property on their own. Land needs to be given to them (by building an object with their citizen number on it) by a caretaker or by a bot running under caretaker privileges.

If this value is set, the world server will perform encroachment checks against caretaker-owned objects, thus enforcing encroachment rules onto the world caretaker.

If this is set, non-caretakers will not be allowed to create objects which activate or open webpages. More precisely, any commands they make top open a web page via bump or mouse-click will be ignoed by the browser.

This is the maximum number of other users that each user will be able to hear in chat. Note that on the client side, users can control how many of these avatars will be rendered, but this option goverens how many will be available to the client, and superceedes whatever choice the client may make. That is, if this limit is set to 20, and the user tells their browser to render the closest 30 avatars, they will still never see more than 20 avatars at a time.

This number specifies (in centimeters) how far away users will be able to hear the chat of others. Note that this is not a guarantee that all users will hear one another within the given distance. The client will hear the chat of the closest avtars up to neighbor_limit (see above) that fall within this range.