This patch makes llAllowInventoryDrop work with the permissions module
enabled. Changes include:
- Enabled PropagatePermissions when permissions module serverside perms
is on
- change ownership of item when item is dropped into an object.
Ownership changes to the owner of the object the item is dropped into
- propagation of permissions if the permissions module enabled (eg
next-owner mask applied)
- CHANGED_ALLOWED_DROP is now passed to the change script event if an
item was allowed to be dropped into the object only because
llAllowInventoryDrop is enabled (instead of CHANGED_INVENTORY being
passed).
- Sets object flags correctly when llAllowInventoryDrop is called so
clients are notified immediately of the change in state. Am not
sure that calling aggregateScriptEvents is the right way to do it,
but it works and seems to be the only way without making further
changes to update LocalFlags
physical center of an avatar, for display purposes. This should keep the
avatar feet above ground visually in most cases. Tweaked for both height
extremes and various leg lengths. Improvements welcome
public bool ExternalChecksCanCreateAvatarInventory(int invType, UUID userID)
public bool ExternalChecksCanCopyAvatarInventory(UUID itemID, UUID userID)
public bool ExternalChecksCanCopyAvatarInventory(UUID itemID, UUID userID)
public bool ExternalChecksCanDeleteAvatarInventory(UUID itemID, UUID userID)
to ExternalChecks to handle avatar inventory checks (as opposed to object inv checks).
* opensim-dev e-mail to follow concerning this shortly
* This may alleviate a little the freezing experienced by existing avatars when a new client logs in
* Race condition risks look minimal since one wouldn't expect another thread to start fiddling with that presence
destination user is offline/out of range. No more eternal cache is needed
for tracking IDs. Code cleanup. Removed some casts from IScene to Scene.
Decline now properly places item in trash rather than deleting it outright.
* Code Cleanliness Fixes in LLClientView
* Using field instead of local variable for handlerUpdatePrimGroupRotation (if you notice any new oddities with prim group rotation after this patch, please mantis)
* This is done by sending a 'major interface version' number on sim registration. Developers must increment this every time they make a change that would make the previous
OpenSim revision failure incompatible with the new one (non-fatal incompatibilities are fine).
* This number resides in OpenSim.Framework.Servers.VersionInfo.MajorInterfaceVersion
* This allows the grid service to stop older, incompatible regions from connecting
This patch changes a couple of methods in Scene.Inventory to virtual,
so they can be overridden in subclasses. DeleteToInventory now returns
the UUID of the newly created asset, so that further actions on it can
be pursued in subclasses. This will make my life easier for making
inventory accessible in the hypergrid.
will allow people who don't want megaprims in their sim to prevent them
from being created. Any prim rezzed or pulled across the border will be
clamped to the size specified in OpenSim.ini if this option is set.
* Implements the SendInitiateDownload method in IClientAPI
* Uses the ITerrainModule Interface to write a terrain file to disk then uses a FileStream to read the binary file from the disk and put it in a byte array. and save to the xFer list.
* It then tells the client to download the file and the client initiates an Xfer request.
* Decouple sog and sop by removing the need to pass the sog to the sop when it is created - most of the code was doing this operation (and hence duplicating it) anyway
* Remove unused constructors
This patch addresses mantis bug 2576.
http://opensimulator.org/mantis/view.php?id=2576
Briefly, if you call llDie from many scripts at the same time (say a
build is cleaning up excess objects) then OpenSim deadlocks. Avatars
are unable to move, and whilst the console is active you can't do much
without it also locking up. This only occurs with the XEngine script
engine enabled.
I have attached a patch which works, but I'm not sure its the right way
to address the problem. The fundamental problem is that a lock on a
SceneObjectGroup's m_parts is taken when the object is deleted, a
callback to the script engine occurs and a fair way down the callchain,
potentially there are locks taken on several other SceneObjectGroup's
m_parts. Deadlock then occurs if you get unlucky enough
to get in the situation where with several llDie's are called and
SceneObjectGroups
have taken a lock on their own m_parts, and end up waiting on each
other's
locks to become available.
The patch adds a lock at a high level so that that the removal of script
instances
from an object only occurs once per scene at a time. This avoids the
potential
of deadlock. Theoretically there could be some performance hit but
AFAICT
the path taken is not a common occurrence.
Would welcome any suggestions for a better solution, otherwise feel free
to apply :-)
Note this patch was built against the 0.6.0 freeze as trunk was
rather broken for me this morning (creating a script killed the client
connection).
* Items will now be locally cached for only 24 hours from last access. (Rather than until restart)
* Caveat: Implementing the new caching mechanism means statistics gathering on AssetCache is no longer functional. (Justin - you might want to take a look and see if you can somehow get that back and running if you still need it)
PRIM_TEMP_ON_REZ and PRIM_MATERIAL are not implemented in
llSetPrimitiveParams so support for these is in the patch.
Also two deprecated functions throw errors. They are changed
to behave as in SL: llSetPrimURL - Does nothing except the sleep
(currently commented out) & llRefreshPrimURL shouts
"llRefreshPrimURL - not yet supported" on the error channel
* This means the recent memory fix should now be working correctly - so the current largest memory leak should be fixed. AssetCache still needs to be addressed however.
* This patch is highly experimental and may cause clients to not be able to connect, if this is the case, it will be rolled back in approximately 5 minutes.
* Introducing IClientCore - this will be the key replacement for IClientAPI in the long run, it has a very minimal set of methods designed to allow you to access specialist API's.
* See https://lists.berlios.de/pipermail/opensim-dev/2008-September/003049.html for the early discussion on this.
* Was caused by the lack of a local id. Local ids are now given from the same sequence as prims, rather than a separate one
* I don't believe this will cause any problems, but please revert to a separate sequence if it does
Included patch fixes error: Z and W terms in the quaternion were
swapped (ZERO_ROTATION is <0,0,0,1>, it was checking for <0,0,1,0>).
There is an issue with older prims: it seems their default sit
target was not always set to ZERO_ROTATION;
potential (asset bloat, asset server DOS due to no enforced delay)
Formatting cleanup. Change default permissions on the notecard to
not include "anyone can copy" and "anyone can move", as they are
meaningless on non-prim items.
- fixes IRCBridgeModule's XmlRpc method really paying attention to
region parameter
- cleans up indentation in IRCBridge code
- fixes ConciergeModule exception on client logout
* This should (hopefully) allow TestClient and stuff built on top of it to work again
* Will probably come back later and change variable names to stop this happening again
* Really this should be 1, but I think that this would be too slow compared to a Second Life server until we improve our ability to send textures of variable quality
* This may improve one aspect of sim performance where there are many avatars. However, there are still other performance problems that are unrelated to this change
* Value may be further tuned
* Removed temporary decals since the multipler setting will stick around now
* Inserts proper animation state names into data/avataranimations.xml file so that llGetAnimation() works as one would expect.
* Thanks StrawberryFride!
* This is a partial implementation of llGetAnimation that returns the name of the animation as stored in data/avataranimations.xml but not its state name (since we don't yet
have these).
* Thanks StrawberryFride
Melanie Thielker