missing from when this is run in grid mode. But, worse, turns out that this whole feature of kicking
off the user after a crash was entirely missing from standalone mode.
* This facility allows you to save changes to an object that you've rezzed into a region back into their original inventory item without having to take a copy of the rezzed
object.
aggressive at nixing the user out of the cache. We're now relying on NeedSceneCacheClear to decide
whether to nix it or not. All other mods in other files are for better debugging messages.
We need to update all child agents whenever the root agent crosses regions. The update
now includes child agents in common neighbours. This is so that those get updated with the
seeds of the new child agents that are spawned from the receiving region.
This also fixes some timing issues. We need to close child agents from the originating region
before we update child agents in the receiving region.
* This means that UserProfileCacheService no longer needs to know about IClientAPI and can leave it to callers to do their own error logging
* This is also more consistent with the way that item inventory manipulation is handled
* I don't really think Scene.PacketHandlers.cs should be a permanent home for these handlers - this is just for convenience
For a script to successfully cross, both source and destination region must
enable the feature. WARNING: Trusting binaries from other sims allows
ARBITRARY REMOTE CODE EXECUTION for ANYONE! Please do not use except
in ultimate trust scenarios!
prevent adjacent sims from using identical Local IDs for the attachment
Thanks to Mana Janus (Hippo Viewer) for providing the crucial bit of
information, namely that, due to a bug in the viewer, adjacent sims can't
use the same local ids.
* Entities should now in theory be lock-free externally.
* Other properties may cause blocking however[?].
* ScenePresence maintains separate locks so isn't fixed by this commit.
* Important Changes: Scene.Entities is now IEnumerable directly. You do not need to use Entities.Values, you can Enumerate on .Entities directly. (So 'foreach Scene.Entities' vs 'foreach Scene.Entities.Values').
* Locks: Entities maintains it's own internal locking states. This means you do not need to lock entities anymore. I'll be going through and removing locks on it systematically.
* SceneObjectPartInventory.cs isn't a particularly good name but it's probably not got a long life
* A proper inventory interface to follow
* Parallel changes for other inventory partial classes to follow at a later date
* This renders RootPart == null checks useless - the replacement is to check SOG.IsDeleted. However, in many cases this will not be necessary since updates to deleted parts
will not be sent to the client
* This should remove any remaining race conditions where an object is deleted while another thread is yet to obtain the root part to perform some operation
* Doing this is probably a necessary prerequisite to moving to a model without a separate SOG and SOP
* Unfortunately it's not possible to eliminate all RootPart == null checks since in some contexts it is currently used to check whether an object was created successfully
the IM module and makes it into a module of it's own, which can be used by
all other modules. Removes some ugly hacks. Refer to the IM module to see
how it's used. Also fixes the persistence issue (Mantis #2598)
Objects will be persisted now MinimumTimeBeforePersistenceConsidered seconds
after the last change, but latest MaximumTimeBeforePersistenceConsidered after
the first change (both are configurable in OpenSim.ini.example and are set to
60 and 600 as default).
Contains a migration. May contain nuts.
Please back up your inventory data store. This revision changes the interface
version!! No older regions can connect to these new UGAIM, and the new regions
can't connect to the old UGAIM. Fixes a long-standing issue of permissions loss
Currently persisted on MySQL only.
* 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
* 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
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.
* 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).
* 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
on-/offline updates, calling cards for friends.
This adds methods in the DB layer and changes the MessagingServer, so a full
update (incl. UGAIM) is necessary to get it working. Older regions shouldn't
break, nor should older UGAIM break newer regions, but friends/presence will
only work with all concerned parts (UGAIM, source region and destination
region) at this revision (or later).
I added the DB code for MSSQL, too, but couldn't test that.
BEWARE: May contain bugs.
Add rezzing time to objects. Add Object return and traffic fields to land
database. Add plumbing for auto return. Implement auto return.
Contains a migration. May contain nuts.
* Implemented a proper update thread
* Removed the UpdateLock Mutex as it's no longer needed because updates can only happen one at a time now.
* This should actually improve performance significantly.. But, see the warning on the next line!
* Warning: If there are deadlocks that the threadpool timer method was hiding, this will expose them for all the nastiness they are.
* I believe this was the cause of the remaining packet_out_of_order messages in the Linden client logs
* There were race conditions where multiple clientstacks would overwrite each other's sequence numbers
* This patch aims to store look at data when an avatar logs off in grid mode
* However, in my short test it doesn't appear to be working yet - numbers are being stored but they don't look correct
* But this doesn't appear to cause any login problems
* Thanks tyre
Justin Clarke Casey