[Opensim-dev] Estates Estates everywhere and nowhere to save

[Stefan Andersson]

Teravus,
 
good of you to start working on this. But, I'm a bit confused as over what of these functions are part of the protocol, and what are 'percieved functionality' as in how things are organized on the server.
 
I definitively think that the 'estate settings' packets will have to be assembled and disassembled from an array of sources, which implies that the client stack should have an EstateManager (or similar) that acts as an facade for the whole system, that is, it splits up get/sets requests and forwards them into separate backend services; permission manager, scenemanager, regionmanager, clientmanager et.c.
 
This allows us to subclass and extend the EstateManager base so that we can support a variety of resolution schemes and data sources. One of them could be an true-to-SL implementation with hierarchy resolution, another read from an ini, yet a third from db, but for me, I'd like something that just says the same thing for all regions all the time.
 
Best,
/Stefan


Date: Tue, 18 Dec 2007 11:12:09 -0500From: teravus at gmail.comTo: opensim-dev at lists.berlios.deSubject: [Opensim-dev] Estates Estates everywhere and nowhere to save
Hey all
 
Going through and looking at the estate/region stuff we've currently got in place..  there's a fundimental difference from the client orgainization of 'estate and region'.  Because of that there's also a severe lack of functionality. 
 
Currently, we've got one EstateSettings.xml file with 'set' values for all regions in our instance.
In addition, a few options are configurable per region in their respective region.xml files.
 
Estates are logical organizational units that have a one to many relationship with regions.
There are many regions to one estate and every region is in an estate.
 
Organizing it this way allows for a simple way to make configuration changes on all of the simulators you run (including regions on separate OpenSimulator Instances)
 
It also allows you to section off certain portions of your map. (ParentEstate)
 
Currently there's some real Old Crusty code surrounding the EstateSettings.xml file.  You *can* save to EstateSettings.xml, but it's really ugly..    and you currently 'can't' save to your RegionInfo.xml files(so nothing persists).
 
It's been proposed to put this information in a database and/or have it be asked when the sim loads for the first time.
 
As far as Region vs Estate responsibility/relationship, what's the community concensus?
 
If you change an estate setting, should it override a region level setting?  (LLGrid does, do we want to?)
 
Bear in mind that we've got cross over occasionally on the values.
 
Some of the Nouns involved are;
BillableFactorEstateIDMaxAgentsObjectBonusFactorParentEstateIDPricePerMeter
RedirectGridXRedirectGridYRegionFlags
SimAccessSunHourTerrainLowerLimitTerrainRaiseLimitUseEstateSunWaterHeightSimName
TerrainTextures (base1,base2,base3,base4)
Maturity
Maximum agents
Covenants
Estate managers
Estate Owners
UsedFixedSun
when to use the various terrain base textures
Estate level Banlists
Estate level allow lists
EstateID
ParentEstateID
BlockFly
AllowDamage
Restrict Pushing
AllowLandResell
AllowParcelJoin/Divide
Telehub settings
Disable scripts/Collisions/Physics
Sandbox Region
 
Public Access
AllowDirect Teleport
 
Eventually, Allowed Groups
(<Add more nouns here>)
 
If we're using the LL grid as an example, then the following examples exist;
http://wiki.secondlife.com/wiki/Estate_Visibility_Functional_Spec
http://wiki.secondlife.com/wiki/Estate_Land_Sales_Functional_Spec
http://wiki.secondlife.com/wiki/Estate_Manager
https://wiki.secondlife.com/wiki/Estate_Menu
 
I look forward to your response.
 
Best Regards
Tera
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071220/8c762ff3/attachment-0001.html>