| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
with our own and add export permissions as well as a new definition for "All" as meaning "all conventional permissions" rather than "all possible permissions"
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
started.
Adds DebugLevel infrastructure to XEngine though currently commented out and unused.
|
| |
|
|
| |
the 'root' part.
|
| |
|
|
|
|
|
|
| |
permissions, not PermissionMask.All
Setting PermissionMask.All will cause next permissions to replace current permissions when the object is rezzed, since bit 4 will be set.
This is not correct behaviour for a freshly uploaded mesh. Freshly rezzed in-world prims also do not have bit 4 set (don't yet know exactly what this is).
Should resolve http://opensimulator.org/mantis/view.php?id=5651
|
| |
|
|
|
|
| |
AddInventoryItem() to accept an agent id rather than a full IClientAPI.
This stops some code having to make spurious client == null checks and reduces regression test complexity.
|
| |
|
|
|
|
|
|
| |
Viewer 2/3 will sometimes attempt to rewear attachments, even though they have already been attached during the main login process.
This change ignores those attempts.
This stops script failures during login, as the rewearing was racing with the script startup code.
It might also help with attachments being abnormally put into deleted state.
Hopefully resolves some more of http://opensimulator.org/mantis/view.php?id=5644
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
MapAndArray collection
|
| | |
|
| |
|
|
|
|
|
| |
Change the slam bit from 3 to 4. Assume the old slam bit is always set.
The new slam bit is a "changed owner" bit, correcting a bug where an item
passed from the creator to another with less than full perms, then back (sale
test) would arrive back full perm. Lots of in-code docs.
|
| |
|
|
|
|
| |
is fully rezzed and all scripts in it are instantiated. This ensures that link
messages will not be lost on rez/region crossing and makes heavily scripted
objects reliable.
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
When an object was deleted, the remove script instance call was aggregating the scripting events as normal.
This would queue a full update of the prim before the viewer was notifed of the deletion of that prim (QuitPacket)
On some occasions, the QuitPacket would be sent before the full update was dequeued and sent.
In principle, you would think that a viewer would ignore updates for deleted prims. But it appears that in the Linden viewer (1.23.5),
a prim update that arrives after the prim was deleted instead makes the deleted prim persist in the viewer. Such prims have no properties
and cannot be removed from the viewer except by a relog.
This change stops the prim event aggregation call if it's being deleted anyway, hence removing the spurious viewer-confusing update.
|
| |
|
|
|
|
|
|
|
|
| |
pass script state and assembly again properly. Reintroduce respecting tht
TrustBinaries flag. Changes the interregion protocol! No version bump
because it was broken anyway, so with a version mismatch it will simply
stay broken, but not crash. Region corssing still doesn't work because
there is still monkey business with both rezzed prims being pushed across
a border and attached prims when walking across a border. Teleport is
untested by may work.
|
| |
|
|
| |
internally
|
| |
|
|
| |
LICENSE.txt.
|
| |
|
|
|
|
|
|
|
| |
as UUIDs
* All existing functionality should be unaffected.
* Database schemas have not been changed.
|
| |
|
|
|
|
|
|
|
| |
* Added log4net dependency to physxplugin in prebuild.xml.
* Added missing m_log fields to classes.
* Replaced Console.WriteLine with appropriate m_log.Xxxx
* Tested that nant test target runs succesfully.
* Tested that local opensim sandbox starts up without errors.
|
| | |
|
| |
|
|
|
|
|
|
| |
required file system objects are not present in the test harness.
This makes the main code ignore the failure, therefore the test succeeds.
Not elegant and maybe a unit test guru has a better way. Marked as a TODO
|
| | |
|
| |
|
|
| |
fixes mantis #3126, as well as other random displacements. The problem was that the new object at the receiving region was being marked as attachment before AttachObject was called. That made its AbsolutePosition be the position of the avie, and that was what was being given to AttachObject.
|
| |
|
|
|
|
|
|
|
|
| |
LocalInterregionComms. This breaks interregion comms with older versions in what concerns prim crossing. In the process of moving the comms, a few things seem to be working better, namely this may address mantis #3011, mantis #1698. Hopefully, this doesn't break anything else. But I'm still seeing weirdnesses with attchments jumping out of place after a cross/TP.
The two most notable changes in the crossing process were:
* Object gets passed in only one message, not two as done before.
* Local object crossings do not get serialized, as done before.
|
|
|
OpenSim.Region.Environment into a "framework" part and a modules only
part. This first changeset refactors OpenSim.Region.Environment.Scenes,
OpenSim.Region.Environment.Interfaces, and OpenSim.Region.Interfaces
into OpenSim.Region.Framework.{Interfaces,Scenes} leaving only region
modules in OpenSim.Region.Environment.
The next step will be to move region modules up from
OpenSim.Region.Environment.Modules to OpenSim.Region.CoreModules and
then sort out which modules are really core modules and which should
move out to forge.
I've been very careful to NOT BREAK anything. i hope i've
succeeded. as this is the work of a whole week i hope i managed to
keep track with the applied patches of the last week --- could any of
you that did check in stuff have a look at whether it survived? thx!
|
