Estate Support

From OpenSimulator

Revision as of 11:19, 12 December 2013 by Justincc (Talk | contribs)

Jump to: navigation, search


Contents

Introduction

Documentation is a work-in-progress

Estates in OpenSimulator are supported at the simulator level - these are not stored in a ROBUST service.

Tools for manipulating estates in OpenSimulator are currently extremely poor. The only support in the console is a mechanism for setting up a new estate when a new region is setup. Commands for better managing estates (creation, deletion, change owner, etc.) must be added in the future. At the moment, the only way to do this is by manipulating the region database directly.

Tasks

TODO: Need to add more tasks as necessary for operations such as changing estate manager.

Determine who is the estate manager

One option (perhaps the usual) is to login to the OpenSimulator installation with a viewer and look at the "Covenant" tab of the "About Land" box.

Alternatively, one could execute the database command

select PrincipalID, FirstName, LastName, EstateID, EstateName from UserAccounts, estate_settings as es where PrincipalID=es.EstateOwner;

to show owners of all estates referenced by the simulator.

Database tables

  • estate_groups - groups allowed on the estate.
  • estate_managers - managers of the estate.
  • estate_map - relates IDs of regions to the estate ID.
  • Estate_settings - holds all estate properties (estate owner, estate name, etc.).
  • estate_users - residents allowed in the estate.
  • estateban - residents banned from the estate.

Old notes

This is the old page contents. It may be useful for historical information.

SVN r5525 introduced estate support into OpenSimulator.

Updating to this or a later revison will create estate support in your instance. It will convert the previous settings file to a set of database tables.

The following tables are created

regionsettings (this will be dropped and recreated if it existed)
estate_settings
estate_map
estatebans
estate_users
estate_groups
estate_managers

These tables will be created in the region datastore by default.

On conversion, it will set up an environment as close as possible to what existed before.

It auto-creates one estate per region, with default estate IDs, starting from 100. All new estates will be parented by estate 100 as well. It then places the region in it, converts the old region bans to new estate bans for that estate and sets the new estate flags to defaults. All the information is saved in the database in the new tables.

Region settings are now really by region, no longer per instance.

This patch causes all regions to revert to the settings from estate_settings.xml. This will repair the loss of ground textures some people have reported with the last patch. However, per-region settings made with the last patch will revert to the settings from estate_settings.xml. This is a trade off and was done to make the most common migration case more robust.

Estate owners

Estate owners are now supported, but have to be entered in the database manually, since no support for this exists in the client. Set the EstateOwner field in estate_settings to the UUID of the user you want to be the estate owner. It will become effective in each region at the next region restart.

Fixing Estate IDs

Previous versions of OpenSimulator did automatically create estates with an EstateID equal to 1 and that ID is stored in the OpenSimulator database. Unfortunately SL based viewer do not work properly with EStateID values between 1 and 5, because these numbers are reserved for Linden Labs internal use.

In the Estate tab of the Estate Manager the estate managers and allowed and banned avatars lists are grayed out, for estates using these reserved EstateID values. To fix this problem, run the SQL statements below to adjust the EstateIDs the following way:

Old New
---------
1 --> 100
2 --> 101
3 --> 102
4 --> 103
5 --> 104

Execute the following command while OpenSimulator is not running:

mysql -u<user> -p<password> <database> < FixEstateID.sql

SQL statements in FixEstateID.sql:

UPDATE estate_groups SET EstateID=100 WHERE EstateID=1;
UPDATE estate_managers SET EstateID=100 WHERE EstateID=1;
UPDATE estate_map SET EstateID=100 WHERE EstateID=1;
UPDATE estate_settings SET EstateID=100 WHERE EstateID=1;
UPDATE estate_users SET EstateID=100 WHERE EstateID=1;
UPDATE estateban SET EstateID=100 WHERE EstateID=1;
UPDATE estate_groups SET EstateID=101 WHERE EstateID=2;
UPDATE estate_managers SET EstateID=101 WHERE EstateID=2;
UPDATE estate_map SET EstateID=101 WHERE EstateID=2;
UPDATE estate_settings SET EstateID=101 WHERE EstateID=2;
UPDATE estate_users SET EstateID=101 WHERE EstateID=2;
UPDATE estateban SET EstateID=101 WHERE EstateID=2;
UPDATE estate_groups SET EstateID=102 WHERE EstateID=3;
UPDATE estate_managers SET EstateID=102 WHERE EstateID=3;
UPDATE estate_map SET EstateID=102 WHERE EstateID=3;
UPDATE estate_settings SET EstateID=102 WHERE EstateID=3;
UPDATE estate_users SET EstateID=102 WHERE EstateID=3;
UPDATE estateban SET EstateID=102 WHERE EstateID=3;
UPDATE estate_groups SET EstateID=103 WHERE EstateID=4;
UPDATE estate_managers SET EstateID=103 WHERE EstateID=4;
UPDATE estate_map SET EstateID=103 WHERE EstateID=4;
UPDATE estate_settings SET EstateID=103 WHERE EstateID=4;
UPDATE estate_users SET EstateID=103 WHERE EstateID=4;
UPDATE estateban SET EstateID=103 WHERE EstateID=4;
UPDATE estate_groups SET EstateID=104 WHERE EstateID=5;
UPDATE estate_managers SET EstateID=104 WHERE EstateID=5;
UPDATE estate_map SET EstateID=104 WHERE EstateID=5;
UPDATE estate_settings SET EstateID=104 WHERE EstateID=5;
UPDATE estate_users SET EstateID=104 WHERE EstateID=5;
UPDATE estateban SET EstateID=104 WHERE EstateID=5;
Personal tools
General
About This Wiki