| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
5035).
Using the RemoteAdmin API to close then recreate a region would fail if the estate name had not changed. If the estate name /was/ changed then the existing estate would be renamed rather than a new one being created. The problem really arose from a lack of distinction in the data storage layer between creating new estates and loading existing ones.
|
| |\ \
| | |/ |
|
| | | |
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
clothes necessary to display a viewer 2 avatar, as implemented in c4efb97d
This is controlled by the CreateDefaultAvatarEntries switch in the [UserAccountService] section of config-include/Stnadalone.ini
This is left as false in grid mode
|
| |\ \
| | |/ |
|
| | | |
|
| |\ \
| | |/
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/CoreModules/ServiceConnectorsOut/UserAccounts/LocalUserAccountServiceConnector.cs
|
| | |
| | |
| | |
| | | |
entries on standalone if applicable.
|
| |\ \
| | |/ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
entries to make a newly created user appear as a non-cloud on viewer 2
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.
|
| |\ \
| | |/
| | |
| | |
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/Scene.Inventory.cs
OpenSim/Region/Framework/Scenes/SceneObjectPart.cs
OpenSim/Region/Framework/Scenes/SceneObjectPartInventory.cs
|
| | |
| | |
| | |
| | |
| | |
| | | |
reflect what it actually does
This also makes it consistent with some other methods that send data to the client.
|
| |\ \
| | |/
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneObjectPartInventory.cs
|
| | |
| | |
| | |
| | | |
prim inventory
|
| |\ \
| | |/
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneObjectPartInventory.cs
|
| | |
| | |
| | |
| | | |
avoid a possible race condition
|
| |\ \
| | |/
| | |
| | |
| | | |
Conflicts:
OpenSim/Region/Framework/Scenes/SceneObjectPartInventory.cs
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
name rather than one that references a metadata file containing only the folder object.
If we do this, then viewer 3 crashes when we try and rez a script directly in an attachment's prim inventory.
Sending an empty file name was already being done if the prim's inventory had never been touched.
Now we always do that if there are no items in that inventory.
Hopefully addresses the remaining point in http://opensimulator.org/mantis/view.php?id=5644
|
|\ \ \
| |/ /
|/| | |
|
| | | |
|
| | |
| | |
| | |
| | | |
depending on the first two digits of the asset id.
|
| | |
| | |
| | |
| | | |
it's an eyesore)
|
| | |
| | |
| | |
| | | |
checked mode" - doesn't make much sense to me, but for some reason it doesn't like 256 - 6 when 256 is a constant...
|
|\ \ \
| | |/
| |/| |
|
| | | |
|
| | |
| | |
| | |
| | | |
all parts, now that we're performing this check in UpdateKnownItem() for other purposes
|
| | |
| | |
| | |
| | | |
itemID is always taken taken from the group's stored item id, and agentID is never used.
|
| | |
| | |
| | |
| | | |
It's not appropriate for code outside the attachments module to call this.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Viewer 2/3 will sometimes attempt to rewear attachments, even though they have already been attached during the main login process.
This change ignores those attempts.
This stops script failures during login, as the rewearing was racing with the script startup code.
It might also help with attachments being abnormally put into deleted state.
Hopefully resolves some more of http://opensimulator.org/mantis/view.php?id=5644
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
itemID) for now
As far as I can see, this is only invoked by a PUT request to ObjectHandlers, which is not being used anyway.
Invoking attachments code at this point is probably inappropriate since it would still be invoked when the client entered the scene.
Being commented to simplify analysis of attachments issues. Can be uncommented when in use.
Also, small tweak to lock and log removal of a SOG from the SceneObjectGroupsByLocalPartID collection in SceneGraph.GetGroupByPrim() if an inconsistency is found.
|
| | |
| | |
| | |
| | |
| | |
| | | |
part indexes in SG.DeleteSceneObject()
this is unnecessary because the parts array iterated through contains the root part as well as the non-root parts
|
| | |
| | |
| | |
| | | |
deletion
|
| | |
| | |
| | |
| | |
| | |
| | | |
indexes sepearately from the other parts.
The SOG.Parts property contains the root part as well as the non-root parts
|
| | |
| | |
| | |
| | | |
the local id of one of its parts
|
| | |
| | |
| | |
| | | |
single-part
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
bucket to prevent a viewer 3 crash.
This is the message sent to the client when the object is returned.
We were sending byte[0] in the binary bucket. This didn't kill viewer 1 but did terminate viewer 3 (don't know about viewer 2).
So sending "\0" instead.
This is to address http://opensimulator.org/mantis/view.php?id=5683
|
| | |
| | |
| | |
| | | |
We were already referencing through the scene in some places.
|
| | | |
|
| | |
| | |
| | |
| | | |
is always passed in at the same time.
|
| | |
| | |
| | |
| | | |
out that prim's local id in the error message.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
IScenePresence.AttachmentsSyncLock object
Attach and detach packets are processed asynchronously when received from a viewer.
Bugs like http://opensimulator.org/mantis/view.php?id=5644 indicate that in some situations (such as attaching/detaching entire folders of objects at once), there are race conditions between these threads.
Since multiple data structures need to be updated on attach/detach, it's not enough to lock the individual collections.
Therefore, this commit introduces a new IScenePresence.AttachmentsSyncLock which add/remove operations lock on.
|
| | |
| | |
| | |
| | | |
This is partly to address http://opensimulator.org/mantis/view.php?id=5644, though something more thorough is needed.
|
| | |
| | |
| | |
| | |
| | | |
This is to make my life easier when creating releases.
I think that it also gives a better story for anybody newly compiling from source.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
May have some effect on http://opensimulator.org/mantis/view.php?id=5644
|