(XmlRpc boolean encoding) to return boolean values --- sometimes both
variants in the SAME XmlRpc method! As XmlRpc DOES have a proper
encoding for boolean, i think we should use that --- having a mixture
of both is a bad thing in any case.
this patch changes all "true"/"false" boolean "encodings" to just
true/false which will be properly encoded by XmlRpc.
BIG FAT NOTE: this might/will break existing customers of
RemoteAdminPlugin --- make sure your scripts, apps, etc get updated
accordingly (unless you have already been dealing with this mess
before)
This update implements support for creation of one or more
default avatars from information contained in a file
default_appearance.xml. Each avatar may have any number of
"outfits" with each outfit representing a different ensemble.
The default avatars get created the first time the RemoteAdmin
interface is used to define a user.
I've tested this quite a bit, but it will benefit from lost of
attention, I'm sure.
Move json stats to non-published resource name
Remove well-known resource name for json stats,
creating dynamic uris with private keys and add
a user configurable resource name for region owner usage.
Added two new (optional) attributes to create_user and update_user
requests.
<gender> - can be 'm' or 'f'. 'm' is default if not specified.
<model> - specifies another, existing, avatar that should be used
as an appearance prototype for this user.
If <model> is specified, then <gender> is ignored. If <model> is not
specified, then 'm' implies a model avatar of "Default Male", and 'f'
implies a default of "Default Female".
At the moment the inventory is not copied. This change means that an
avatar will only look like ruth if none of the possible models exist
in the user database.
- Adds an admin_modify_region call to allow changing of parcel voice
settings and changing of public/private status
- add boolean "public" and boolean "enable_voice" to
admin_create_region XmlRpc call to allow specifying of
public/private status and to allow enabling voice for all parcels;
also added config variables to allow setting of defaults for those
- fixing cut-and-paste artefacts
Added support for access control lists.
Scene: Added test to AddNewClient for an entry in the access
list when connecting to a region with limited access.
EstateSettings: Added an HasAccess(UUID) property to test for
an entry in the estate's access list.
RemoteAdmin: Add RPC calls for admin_acl_list, clear, add,
and remove.
* Make OGS1UserServices inherit from UserManagerBase
* This allows grid mode regions to use the same user data plugin infrastructure as grid servers and standalone OpenSims
comprehensive list of all regions in one go (in contrast to the
/admin/regions/ REST call).
Example:
% curl http://127.0.0.1:9000/admin/regioninfo/
<regions max="10" number="1">
<region avatars="0"
external_hostname="127.0.0.1" ip="0.0.0.0:9000"
master_name="Mr X" master_uuid="b757d5f9-7b36-4dda-8388-6e03dd59b326"
name="London" objects="6" uuid="49253666-a42e-4f44-9026-d23f93af31d7" x="1000" y="1000"/>
</regions>
- Change several classes to use the new plugin for handling of region-modules
(NOTE: No regionmodule is using this yet)
- Add necessary prebuild parts (don't forget to runprebuild)
Attention: Work in progress. This shouldn't break anything, but you never know...
Fixed problem with REST services caused by changes to the OpenSim
core code base - the comms manager had been 'modularized'.
Also added additional debugging to RemoteAdmin interface.
optional about_virtual_world and about_real_world parameters to
XmlRpcUpdateUserAccountMethod to allow setting of "About" and "First
Life" tab in avatar profile.
* In most cases, the setting in OpenSim.ini.example is taken as the canonical one since this is the file virtually everyone ends up using
* OpenSim will start up with a blank OpenSim.ini, in which case sqlite is the default database (as before)
Changed OpenSim.Framework.Communications.Tests.LoginServiceTests to use the LLStandaloneLoginService (from the LLStandaloneLoginModule) rather than LocalLoginService. Really these login tests should most likely be somewhere else as they are testing specific implementations of login services.
Commented out the old LocalLoginService as its no longer used, but want to check there are no problems before it gets deleted.
Dr Scofield