Using MyISAM proves vastly faster for persisting scene objects.
For instance, a scene object that took 9 seconds to persist before now takes 1. This also improves the experience of loading large OARs.
We don't use any of the transactional features of InnoDB.
The only thing that may have an impact is that InnoDB does row locking on inserts while MyISAM does table locking.
However, field reports say there is no noticeable difference.
Revert "Changed Friends table to have 165-sized varchars on PrincipalID and FriendID. The reason for this number is the following: there is a combined key of these 2 fields; apparently MySql can't handle keys larger than 1000 bytes; when the table is created with utf8 encoding, this combined key is bigger than 1000 bytes, and the migration fails. WARNING: this is not a new migration! People who have gone through this migration and failed should update the sizes of these fields manually."
This reverts commit 3fa54a156a.
If these links are not deleted, then they will build up in the player's inventory until they can no longer log in.
Accidental deletion of links due to bugs or other causes is potentially inconvenient but on a par with items being
accidentally moved. When a link is deleted, the target of the link is never touched.
This is a general solution that accounts for the use of links anywhere in the user's inventory.
If these links are not deleted, then they will build up in the player's inventory until they can no longer log in.
Accidental deletion of links due to bugs or other causes is potentially inconvenient but on a par with items being
accidentally moved. When a link is deleted, the target of the link is never touched.
This is a general solution that accounts for the use of links anywhere in the user's inventory.
This applies to adding/removing estate users, groups, managers and bans.
This is the application of the AllEstates_0.5.patch from http://opensimulator.org/mantis/view.php?id=5420
Thanks very much, Snoopy!
set in the target's UserFlags and the impersonator must have UserLevel 200
or above. The user can then log in using the target's name and their own
password.
New option added to save oar -profile=url. Migration on RegionStore making CreatorID be 255 chars.
Moved Handling of user UUID -> name requests to a new module UserManagement/UserManagementModule.
midday defaults when no specific LightShare profile is set.
This prevents LightShare info being send out when the region has no LightShare
profile, allowing normal day/night cycles to happen.
This will cause visual params to be persisted along with worn items. With
this, alpha and tattoo laters will be saved. Multiple layers MAY work, but
not tested because I don't use Viewer 2.
