| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |\ |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GetInventoryItem() method rather than iterate through TaskInventory itself.""
This reverts commit 59a29f5f221a1ffe4e22c63ef9da82270442b213.
The original revert was committed by mistake - it turns out this was not the cause of Mantis 6089
Conflicts:
OpenSim/Region/ScriptEngine/Shared/Api/Implementation/LSL_Api.cs
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
receivers to accept/decline.
This appears to be a regression from back in commit db91044 (Mon Aug 22 2011) where we started to send TaskInventoryOffered msg dialog rather than InventoryOffered dialog.
This is probably correct, but failed because the bucket was too large and because we wouldn't have handled the TaskInventoryDeclined option anyway.
This patch handles both of these and make llGiveInventoryList() use TaskInventoryOffered as well
Fixes http://opensimulator.org/mantis/view.php?id=6089
|
|/
|
|
|
|
| |
method rather than iterate through TaskInventory itself."
This reverts commit 58b13d51a7eddb442e38e6dc6790a9e7cf68bad7.
|
|
|
|
|
|
| |
A better solution using the already present flags must be found.
This reverts commit 6d3ee8bb39d47ed7b32e8905fa0b2fc31c5a9f80.
|
|
|
|
|
|
| |
the thrown exceptions.
Signed-off-by: Melanie <melanie@t-data.com>
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: SignpostMarv <github@signpostmarv.name>
|
|
|
|
|
|
| |
region, implementing parcel prim count check.
Signed-off-by: SignpostMarv <github@signpostmarv.name>
|
|
|
|
|
|
| |
entry/prim limit/access restrictions.
Signed-off-by: SignpostMarv <github@signpostmarv.name>
|
|
|
|
|
|
| |
the BOM, use a single Util.UTF8NoBomEncoding.
This class is thread-safe (as evidenced by the provision of the system-wide Encoding.UTF8 which does not suppress BOM on output).
|
|
|
|
| |
IClientAPI.RemoteEndpoint.
|
|
|
|
|
|
|
| |
constructing fresh copies.
The encodings are thread-safe and already used in such a manner in other places.
This isn't done where Byte Order Mark output is suppressed, since Encoding.UTF8 is constructed to output the BOM.
|
|
|
|
|
| |
This is only currently meant for use by regression tests that don't have any issues if XEngine is started up quickly, since no other operations will be occuring simultaneously.
Therefore, this is not yet documented externally.
|
|
|
|
| |
since the infrastructure no longer fails if this module isn't present, at least on the tested codepaths
|
|
|
|
| |
This currently only does a relatively crude check for a ScriptState node in the serialized xml
|
| |
|
|
|
|
|
|
|
| |
second to finish normally before forcibly aborting.
This is to avoid the worst of the problems in mono 2.6, 2.10 where an aborted thread does not always release all its locks.
This very short grace period is identical to the existing behaviour when a script is removed from the scene.
|
|
|
|
|
|
|
| |
another avatar in the scene.
Very useful in serious game/environment scenarios where its only allowed for trusted creators.
Threat level Severe
|
| |
|
|
|
|
|
| |
This is always done later on in SceneGraph.AddSceneObject() if the call hasn't failed due to sanity checks.
There's no other purpose for this method to exist and it's dangerous/pointless to call in other conditions.
|
|
|
|
| |
Allow NPCS to touch obects.
|
|
|
|
| |
I can't see that these present any real hazard to sim functioning.
|
|
|
|
|
|
|
| |
This works like osForceAttachToAvatar() but allows an object to be directly specified from the script object's inventory rather than forcing it to be rezzed in the scene first.
Still only attaches objects to the owner of the script.
This allows one to bypass the complicated co-ordination of first rezzing objects in the scene before attaching them.
Threat level high.
|
|
|
|
| |
dictionary
|
|
|
|
| |
inspecting a clone of the TaskInventory dictionary that was not cloned thread-safe
|
|
|
|
| |
rather than inspecting a clone of the TaskInventory dictionary that was not cloned thread-safe
|
|
|
|
| |
renamed from ScriptByName()
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
GetInventoryItem()
|
| |
|
|
|
|
|
|
| |
TaskInventory directory
GetInventoryItems() returns a new list and so is equivalent, and creates this list under lock whereas Clone() is not thread-safe
|
|
|
|
|
|
| |
TaskInventory directory
GetInventoryItems() returns a new list and so is equivalent, and creates this list under lock whereas Clone() is not thread-safe
|
|
|
|
| |
rather than have it iterate through TaskInventory itself.
|
|
|
|
| |
rather than have it iterate through TaskInventory itself.
|
|
|
|
| |
rather than iterate through TaskInventory itself.
|
| |
|
|
|
|
|
|
|
| |
directly instead of an item ID to then shuffle through attachments, saving CPU busywork.
Almost all callers already had the sog to hand.
Still checking that it's really an attachment, but now by inspecting SOG.AttachedAvatar
|
|
|
|
|
|
|
| |
XEngine if engine specified does not exist.
This is to take account of situations where the user was intending to specify a script engine using colon using its default language.
This probably generates few false positive as scripts are less likely to end a first line colon with a comment for other purposes.
|
|
|
|
|
|
|
|
|
| |
line of a script where the user was not trying to select a different script engine.
This works by only posting the "Selected engine unavailable" message if we're falling back on XEngine and the language is one handled by XEngine.
In cases where the language is not handled or not allowed, the user will still be notified by the later compiler error.
This avoids the overwhelming majority of false positives where the first line contains a : for other reasons (e.g. source control systems, vim settings, etc.)
Ultimately, I think it would be better to detect script language/engine with a mechanism that didn't just rely on : detection (e.g like #! in unix scripts).
|
|
|
|
| |
colon is found on the first line will always be the same as for the whole script.
|
| |
|
|
|
|
| |
Unchecking "Running" box in script editor now persists. This fixes http://opensimulator.org/mantis/view.php?id=6057
|