Viewer 2 no longer contains the default avatar assets (i.e. "Ruth") that would appear if the user had insufficient body part/clothing entries.
Instead, avatars always appear as a cloud, which is a very bad experience for out-of-the-box OpenSim.
Default is currently off. My intention is to switch it on for standalone shortly.
This is not particularly flexible as "Ruth" is hardcoded, but this can change in the future, in co-ordination with the existing RemoteAdmin capabilities.
Need to fix creation of suitable entries for users created as estate owners on standalone.
Avatars still appear with spooky empty eyes, need to see if we can address this.
This commit adds a "Default Iris" to the library (thanks to Eirynne Sieyes from http://opensimulator.org/mantis/view.php?id=1461) which can be used.
When a user logs in, the attachment item ids are pulled from persistence in the Avatars table. However,
the asset ids are not saved. When the avatar enters a simulator the attachments are set again. If
we simply perform an item check then the asset ids (which are now present) are never set, and NPC attachments
later fail unless the attachment is detached and reattached.
Hopefully resolves part of http://opensimulator.org/mantis/view.php?id=5653
This is not used for anything - appearances are always properties of objects with ids (ScenePresence, AgentCircuitData) and just has the potential to get out of sync when the appearance is cloned.
I was persuaded to do this because simulators on osgrid will persist in inserting bad values for an unknown length of time, even after the original simulator bug which was inserting bad values is out in an osgrid distro
This code can be removed at some point in the future, though I think there is an argument for having services police these values in open grids.
This is to accomodate situations where the authorization service is being used by the hypergrid, where visitors have no user account.
See http://opensimulator.org/mantis/view.php?id=5517, this code is somewhat adapted/cleaned up from Michelle's patch
I'm a little ambivalent about this since visitors could put anything in firstname/lastname so it's not much of an auth measure.
It's up to the auth service to decide which data it actually uses.
Possibly we should be passing through other info such as agent circuit ip
Users should not be given the impression that they can modify these items.
This still does not solve the issue where library items cannot be dragged into prims or user inventory any time after they are initially seen.
Curiously, manually copying and pasting still appears to work.
On the surface, this seems to have something to do with library item caching on the client, since deleting the cache allows drag to work again once
Not sure what the exact problem is.
Some items had completely wrong permissions - this is easier than correcting them all.
The ability to set permissions in xml is retained since there are use cases for this (e.g. to create no-mod library scripts)
Library items always need the same permissions, so it doesn't make sense to load them from the xml files. This just opens the door to permissions mistakes.
We compare existing and loaded asset by doing an SHA1 on both, so that a changed library asset will still update the store.
This cuts asset library load time from 10 seconds to <1 sec.
Note, a fix on the previous commit revealed a bug where a library script cannot be copied except on the first login after a cache clear.
This is unrelated to this commit and needs to be fixed at some subsequent time.
Console output is more appropriate for console commands. The log only gets one side of the conversation anyway (since it doesn't necessarily record command inputs).
Instead of performing the 4096 check when the region is linked (and subsequently removing the link), leave the link in place and perform the check in the entity transfer module
This allows us to explicitly tell the hypergridder why the teleport failed (region out of range).
It also allows people on regions that are within range (on a large source grid) to teleport.
The Check4096 config parameter in the [GridService] section is replaced by a max_distance paramter in a new [EntityTransfer] section in OpenSimDefaults.ini
Since the parameter is in OpenSimDefaults.ini no action needs to be taken unless you want to increase this limit. It could also be decreased.
The check is being made in the base entity transfer module, since I believe the viewer problem occurs both on extremely large grids and while hypergridding.
