This changeset add the RegionReady module code. The module sends a
message on a configurable channel when an oar file has finished
loading or if the script engine has emptied its queue for the first
time (eg server startup). Config is something like this:
[RegionReady]
enabled = true
channel_notify = -800
The module also knows if there was an error with startup.
* This adds more explanation for the new proxy settings in OpenSim.ini.example
* Also does some formatting correction
* I did some additional reformatting on top of that
* This option makes OpenSim use the usual db based asset service in standalone, and the grid based one in grid mode
* The other options can (local, grid, etc) can still be used explicitly as before
* Also change OpenSim.ini.example and the surrounding explanative text
* Adding an option to use the tree module to manage the trees in the simulator (grow/reproduce/die)
* Setting it to off by default in an effort to reduce the number of threads in use by default
* You can also turn it on in a 'one off' way with 'tree active true' on the console. To 'one off' turn it off, it's 'tree active false'. The permanent way to do that, however is in the opensim.ini.
* This allows configuration of the assetset and library control file paths to be other than ./inventory/Libraries.xml and ./assets/AssetSets.xml
* This is controlled via the LibrariesXMLFile and AssetSetsXMLFile configuration settings in [StandAlone] in OpenSim.ini (in standalone)
and via the user and asset config xml files for grid mode
* Thanks to SirKimba for the patch
The attached patch ads an OpenSim.ini option (AutomaticLinkPermission)
which when enabled makes PERMISSION_CHANGE_LINKS to be granted to
scripts by default. When enabled llGetPermissions will always return it
as granted and llCreateLink//llBreakLink will succeed without
doing llRequestPermissions. ONLY ENABLE THIS IN TRUSTED ENVIRONMENTS.
The patch also fixes a minor bug in llCreateLink
related to a potential dereference of a null client object.
* Disabled by default (see OpenSim.ini.example for how to enable)
* Saves exceptions to a folder on disk (default "crashes") when enabled.
* These reports can then be uploaded or posted to help debug an error.
* This allows one to override normal OpenSim permissions and prevent non-gods from editing any scripts. This allows edit ability
to be rescinded after it has been given, and prevents the security hole where a single script with liberal perms would allow code changes.
* The default setting remains the existing one of never overruling normal edit permissions.
* These two settings may be enough to stop non-gods entering artbirary script code in a closed grid/standalone configuration.
causes defautlt behavior. "true" now means usable unconditionally, "false"
means disabled, and a list of UUIDs restricts it.
This changes SECURITY! If you used "true" here before, you shoudl review
your setup!
Objects will be persisted now MinimumTimeBeforePersistenceConsidered seconds
after the last change, but latest MaximumTimeBeforePersistenceConsidered after
the first change (both are configurable in OpenSim.ini.example and are set to
60 and 600 as default).
* This doesn't allow complete script lockdown of a sim, many avenues (copying, editing) are still uncloseable at the moment
* Default remains to allow all users to create scripts (subject to existing permissions if enabled)
* Switch default for serverside_object_permissions from false to true - it seems more natural that we enforce permissions by default rather than not!
* Add some explanation in OpenSim.ini.example for serverside_object_permissions
will allow people who don't want megaprims in their sim to prevent them
from being created. Any prim rezzed or pulled across the border will be
clamped to the size specified in OpenSim.ini if this option is set.
regions that XmlRpcCreateRegion will create: if region_limit is != 0
then XmlRpcCreateRegion will only create a new region if the number of
regions already existing is below region_limit.
* Really this should be 1, but I think that this would be too slow compared to a Second Life server until we improve our ability to send textures of variable quality
* This may improve one aspect of sim performance where there are many avatars. However, there are still other performance problems that are unrelated to this change
* Value may be further tuned
* Removed temporary decals since the multipler setting will stick around now
* This should probably be 1, but currently by default it is 8, to reflect what was being eon3 in OpenSim before this revision. So if the client requested a maximum throttle
of 1500 kilobits per second, we would actually send out 1500 kilobytes per second
* Adjusting this multiplier down towards 1 may improve your OpenSim experience, though in other situations it may degrade (e.g. if you're using a standalone over high bandwidth
links)
* This is currently a user setting because adjusting it down may currently reveal other OpenSim bugs.
on-/offline updates, calling cards for friends.
This adds methods in the DB layer and changes the MessagingServer, so a full
update (incl. UGAIM) is necessary to get it working. Older regions shouldn't
break, nor should older UGAIM break newer regions, but friends/presence will
only work with all concerned parts (UGAIM, source region and destination
region) at this revision (or later).
I added the DB code for MSSQL, too, but couldn't test that.
BEWARE: May contain bugs.
logic to ConciergeModule. adding XmlRpc method to allow update of
welcome template for a region. documenting [Concierge] "password"
option in OpenSim.ini.example.
chat relaying via private channels, and old IRCBridgeModule
behaviour. also cleaning up IRCBridgeModule's OpenSim.ini
configuration variable names (still supporting "old" variable
names). refactored IRCChatModule into IRCConnector and incorporating
watchdog from IRCBridgeModule into IRCConnector.
enabling ChatModule to be used as a super-class and utilizing it in
ConciergeModule.
* This allows multiple user profile providers to be specified in OpenSim.ini separated by commas
* If multiple providers are specified then a request for a user profile will query each in turn until the profile is either found or all have been queried
* Unfortunately I don't believe this order can currently be specified, which if true is something that will need to be fixed.
* Thanks to smeans for the original patch.
Dr Scofield