If an avatar is sitting when the client disconnects, the avatar
is not disassociated from the SOG on which (s)he was sat. This
produces any, and varied, effects.
I have updated RemoveCLient in Scene, to check, and stand the
client up immediately prior to disconnect. This seems like the
most robust way to handle the situation. Though in this case
it might be worth factoring out the animations from other
standup processing. It does no harm, but in this case it is
entirely redundant.
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.
llSetPrimitiveParams in a large linkset can disrupt the
entire region. However, when the script is in a large
linkset, it appears to totally lag out the scene and
stops updates from being sent.
The attached patch fixes a few problems that people were
having with the Messaging provided by the XmlRpcGroups
optional module, namely:
* Fixes 2x echo in group messaging
* Fixes problems with cross instance, non-neighbor, messaging
* current core
* past core
* additional contributors
Also fix all the IBM entries, and make sure all IBM folks that gave me
patches get listed individually in here.
the number of times we are going to take this lock in a row (which is
just wasted resource), and to keep us from attempting to array access a
list which might be changing right now. Extremely curious if this helps
prevent some of our mono segfaults.
Some other IRC timing wrinkles showed up:
[1] If connect processing blocked in socket activation, then
the watch dog saw the session as connected, and eventually
tried to ping, but because the socket create was still
blocked, it barfed on a null reference. This then drove
reconnect. Changed the watchdog handler so that it only
tries to ping connections that are connected and not pending.
[2] If the socket creation actually fails, then the connect and
pending flags were reset. This resulted in the connection
being retried at the earliest possible opportunity. The
longer login-timeout is preferrable, so the status flags
are not reset, and the failed login is eventually timed
out.
[3] The Inter-connection interval is primed so that the first
session can connect without delay.
Dr Scofield