| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This was working in 0.7.2 but was accidentally removed from 0.7.3.
The --publish option for "save oar" will now save oars stripped of parcel owner information as well as scene object info.
Please use the --publish option if you want to publish oars that may be later loaded by others to the same grid from which they were saved.
|
| |
|
|
|
|
| |
last commit 205f2326
|
|
|
|
| |
VectorRenderModule inside its own context, rather than disposing of the old font before using it as a prototype for the new.
|
|
|
|
| |
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
|
|
|
|
|
|
| |
timed-out
The bug manifested as follows: a large world was saved. All the assets were found. But for some unknown reason, the timeout timer was restarted. So after 1 minute it closed the Archive Writer, because it didn't receive any more assets during that minute. That caused the OAR to become corrupted because ArchiveWriteRequestExecution.Save() was still running.
|
| |
|
|
|
|
|
|
|
| |
textures.
The convention is that if an object implements IDiposable() the code must explicitly call Dispose() or call it via the using statement.
This may be particularly important for GDI+ objects since they encapsulate native code entities.
|
| |
|
|
|
|
|
|
| |
would base its gain calculation on the previous avatar's gain, instead of the original input gain.
This was making sound attenuate oddly when there were NPCs in the region, though it could also happen with ordinary avatars.
|
|
|
|
|
|
|
|
| |
description field.
If we copy the asset description then we will only ever replicate the very first description, if there was one, not any subsequent changes.
Thanks to Oren Hurvitz of Kitely for this patch from http://opensimulator.org/mantis/view.php?id=6107
I have adapted it slightly to change the order of arguments (name before description rather than vice-versa) and slightly improve some method doc.
|
|
|
|
| |
with other monitoring code from OpenSim.Framework
|
|
|
|
| |
This better reflects the long-term purpose of that project and matches Monitoring modules.
|
|
|
|
|
| |
This is fired when all regions are ready or when at least one region becomes not ready.
Recently added EventManager.OnRegionReady becomes OnRegionReadyStatusChange to match OnLoginsEnabledStatusChange
|
|
|
|
| |
It seems that the mono 2.10.8.1 doesn't choke on this but for some reason 2.4.3 fails.
|
|
|
|
| |
start of script rather than just the script status reported by SOG.ContainsScripts()
|
|
|
|
| |
correct running status on a re-rezzed attachment
|
|
|
|
|
|
| |
justincc's original work. Sample scripts before doing so. Also refactor some
crucial common code and eliminate parameters that were only ever used with
the same constant value.
|
|
|
|
| |
attempting to fix a mono compile error.
|
|
|
|
| |
simple, high performance logger for high frequency logging (physics sub-operations, for instance).
|
|
|
|
|
| |
while still in the scene to avoid losing important script state.
DeleteSceneObject can not be called before doing this!
|
|
|
|
| |
GroupsModule, since these led to a private blank method
|
|
|
|
|
|
|
| |
enabled or disabled at any point, not just during initial startup.
This replaces EventManager.OnLoginsEnabled which only fired when logins were first enabled
and was affected by a bug where it would never fire if the region started with logins disabled.
|
|
|
|
|
|
| |
once when the region is ready.
Switch MapImageServiceModule to use this.
|
|
|
|
|
|
| |
region name.
This saves listeners from having to re-retrieve the scene from their own lists, which won't work anyway if multiple regions with the same name have been allowed
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
update the name if this has been changed whilst attached.
Note, this behaviour appears to be at variance with the ll grid as of Tues 17 July 2012, testing with viewer 3.2.1.
The item name in inventory does not change either at the point of detach or after a relog.
|
|
|
|
|
|
|
| |
item is updated.
This doesn't seem to make any sense and probably stems from a period when this code was directly involved in attaching objects directly from the scene.
This message is already being sent by InventoryAccessModule code instead.
|
|
|
|
|
|
|
|
| |
resize from the JPEG2000 original rather than only saving it to disk.
This appears to be the cause of the warp 3d exception seen when starting a new region for the first time.
Subsequent starts were okay because resized saved bitmap was correctly retrieved from disk.
Should fix http://opensimulator.org/mantis/view.php?id=5204 and http://opensimulator.org/mantis/view.php?id=5272
|
| |
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
| |
the module code still sets up even if we're using one directly instantiated from the RemoteGridServiceConnector.
Also improves log messages to indicate which regions are sending/receiving various neighbour protocol messages.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This currently only does a relatively crude check for a ScriptState node in the serialized xml
|
|
|
|
| |
currently only checks for the presence of script items, not for started scripts
|
|
|
|
|
|
| |
the known item with script state still in the script engine and then remove the scripts.
This is to fix a regression starting from 5301648 where attachments had to start being deleted before persistence in order to avoid race conditions with hud update threads.
|
|
|
|
|
|
| |
This prevents a stack overflow where a get position on the avatar will refer to the attachment which will in turn refer back to the avatar.
This required recording of all sitting avatars on a prim which is done separately from recording the sit target avatar.
Recording HashSet is null if there are no sitting avatars in order to save memory.
|
|
|
|
|
| |
This was causing 2 copies of the module to be created for each scene.
Probably no bad consequences other than a small waste of memory (both for the module and for the warp3D renderer it loaded)
|
| |
|
| |
|
|
|
|
| |
the scene graph
|
|
|
|
| |
AttachObject() for better code comprehension
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
It appears this was never actually used since attachments were rezzed in other code.
This was never available on remote simulator comms, only local.
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
matches out fromItemID on detach, go through the agent's attachment sog list instead.
|
|
|
|
|
|
|
| |
RezSingleAttachmentFromInventoryInternal() returned null.
null would only ever be returned if the item couldn't be located within inventory and this would happen immediately.
In this case, derezzing wouldn't work anyway since there is no item to derez.
|
|
|
|
| |
OpenSimTestCase.SetUp()
|