| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
with many scripts
See http://opensimulator.org/mantis/view.php?id=4799 for more details
This is the equivalent patch that was applied to master 3.5 weeks ago, seemingly without bad consequences
Thanks Snoopy!
|
| |
|
|
|
|
| |
z co-ord instead of accidentally resetting the incorrect x co-ord
This is a one-liner. It has already been addressed in master and 0.7-post-fixes in a more extensive way
|
| |
|
|
|
|
|
|
| |
they aren't fatal to operations"
This reverts commit ae2454821628d847b0add20a4c593162baafde5b.
Reverted for now pending a fix to the underlying xengine problem instead.
|
| |
|
|
|
|
| |
aren't fatal to operations
this will hopefully stop "save oar" from failing if a script asset is corrupt
|
| | |
|
| |
|
|
|
|
| |
relevant test code has been obsoleted
this allows the tests to pass on my local system
|
| |\ |
|
| | |
| |
| |
| | |
ScenePresence.UpdatePriority() to private
|
| | |
| |
| |
| |
| |
| |
| |
| | |
If viewers (or at least, Linden Viewer 1.23.5) receive child hud object updates before the root prim, then the children are not displayed.
Updates were being queued in LLClientView in the right order (root first) but were being sent in a random order since they were all at the same prioritization
This commit prioritizes the root prim of a hud to its highest level when queued.
I'm not sure if the periodic reprioritization triggered via ScenePresence might reset this, but boosting priority appears to work so far.
Also committed is a belt and braces mechanism in LLClientView to prevent child hud prim being sent out before their root, but since this doesn't appear to be needed it is currently commented out.
|
| | |
| |
| |
| | |
crossing
|
| | |
| |
| |
| |
| |
| | |
attachments cross standalone region boundaries
lots of messy debug code here too which would need to be removed
|
| | |
| |
| |
| |
| |
| |
| |
| | |
attachments cross standalone region boundaries"
This reverts commit 5074d290e4aeb583560272cadc8ba09aa8337210.
This gets rid of the massive amount of scene object log spam - sorry about that, folks
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This chiefly brings in the new sqlite adaptor and renames the old one to SQLiteLegacy
Existing configuratios should continue to work without changes unless you are using Mac OSX and mono 2.6 or later, in which case you will need to enable SQLiteLegacy instead. Please se the instructions in OpenSim.ini.example and the relevant config/include .ini files
Conflicts:
OpenSim/Framework/Servers/VersionInfo.cs
OpenSim/Region/Framework/Scenes/Scene.Inventory.cs
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This is going to be the right behaviour in all cases, I should think.
This means that avatars in region when an oar is loaded do not lose their attachments
|
| | | |
| | |
| | |
| | |
| | |
| | | |
attachments cross standalone region boundaries
lots of messy debug code here too which would need to be removed
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
If serverside permissions are off then this works as expected. Previously, it was impossible for more than one person to edit such items even if permissions were off.
If serverside permissions are on then this works as expected if the object was created by an avatar who had the required group active.
However, if the group for the object is later set then the contained item is still not editable. This may be linked to a wider bug where the object is still not modifiable by the group anyway
Resolve conflict in LLClientView
|
| | |
| |
| |
| | |
this fix stops two full updates being sent on attachment rather than one. Sending two can stop the client displaying attachments properly
|
| | |
| |
| |
| | |
some older content
|
| | |
| |
| |
| | |
than a NullReferenceException
|
| | |
| |
| |
| |
| |
| | |
modules can use it
backport from master
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
root prim until right clicked (or otherwise updated).
The root cause of this problem was that multiple ObjectUpdates were being sent on attachment which differed enough to confuse the client.
Sometimes these would eliminate each other and sometimes not, depending on whether the scheduler looked at the queued updates.
The solution here is to only schedule the ObjectUpdate once the attachment code has done all it needs to do.
Backport from head.
|
| |
|
|
| |
Signed-off-by: Melanie <melanie@t-data.com>
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: Melanie <melanie@t-data.com>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Fixes: Undo, T-pose of others on login, modifiedBulletX works again, feet now stand on the ground instead of in the ground, adds checks to CombatModule. Adds: Redo, Land Undo, checks to agentUpdate (so one can not fall off of a region), more vehicle parts. Finishes almost all of LSL (1 function left, 2 events).
Direct flames and kudos to Revolution, please
Signed-off-by: Melanie <melanie@t-data.com>
|
| |/
|
|
| |
instead of void
|
| |
|
|
|
|
|
| |
This resolves the problem where eyes and hair would turn white on standalone configurations
When a client receives body part information, for some insane reason or other it always ends up uploading this back to the server and then immediately re-requesting it.
This should have been okay since we stored that asset in cache. However, the standalone asset service connector was not checking this cache properly, so every time the client made the request for the asset it has just loaded it would get a big fat null back in the face, causing it to make clothes and hair white.
This bug did not affect grids since they use a different service connector.
|
| |
|
|
| |
Scene.AddSceneObject since this wraps a check that is much less clear
|
| |
|
|
|
|
| |
incoming scene object
Add a read-only Attachments property to ScenePresence
|
| | |
|
| |
|
|
| |
code. No functional changes
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
when a user teleports into a region"
The behavior introduced here is not compatible with SL
This reverts commit b6bee4999c9d238a052022f105069ea4eb85f8f4.
|
| |/ |
|
| |\ |
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Melanie <melanie@t-data.com>
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
not propogate any exceptions that come back
This stops exceptions thrown by modules from disrupting the kernel and still allows other delegates to be executed normally
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
|/|
| |
| | |
user teleports into a region
|
