This takes the AsyncCommandHandler.staticLock.
However, AsyncCommandHandler.DoOneCmdHandlerPass() already holds staticLock and may attempt to take the EventQueue lock via ScriptInstance.PostEvent() in XEngine.CheckListeners()
This is a regression from faaf47a (Fri Jan 16 2015) but not simply reverting that commit since it will reintroduce a race between script removal, backup and event queue manipulating code.
This is to see if this helps with the problem in http://opensimulator.org/mantis/view.php?id=7278 where some DLLs are not allowing this.
Since OpenSim created the file it should always be allowed to delete it.
This eliminates pointless work and exceptions when an appdomain is unloaded whilst an attachment script state is persisted.
Adds test for this case.
Relates to http://opensimulator.org/mantis/view.php?id=7407
This was beause the code was finding the script DLL compiled for the source region as everything is in the same appdomain and using this as the location for the destination script state, etc.
This resolves the regression by passing the proper destination separately from the DLL retrieved.
Probably a regression since commit d7b92604 (11 July 2014).
Added regression test for this case.
At least partly addresses http://opensimulator.org/mantis/view.php?id=7278
This is to achieve a clean separation of concerns - the watchdog is an inappropriate place for work management.
Also adds a WorkManager.RunInThreadPool() class which feeds through to Util.FireAndForget.
Also switches around the name and obj arguments to the new RunInThread() and RunJob() methods so that the callback obj comes after the callback as seen in the SDK and elsewhere
This is somewhat more in keeping with something like osForceAttachToOtherAvatarFromInventory()
and potentially allows a separate osForceSit() command with High threat rather than VeryHigh that only sits the owner and can be enabled without enabling sit of other avatars.
Allows a script IN the target prim to force an avatar to sit on it using normal methods as if called by the client.
Overload method of osForceSit() to allow a script NOT in the target prim to force an avatar to sit on the target prim using normal methods as if called by the client.
This patch is based on previous work from
http://opensimulator.org/mantis/view.php?id=4492
and also includes the suggestions from justincc including change of threat level
Thank you Christos Lightling.
This is cinderblocks' transaction_result.diff from http://opensimulator.org/mantis/view.php?id=7329 but I have used lsl.parser.cs and lsl.lexer.cs files generated directly from opensim-libs rather than those supplied in the patch.
I also added scriptEvents.transaction_reuslt.
The required parser/lexer generation file changes were made in commit d564f28 in the opensim-libs repo.
Thanks!
Other parts of OpenSimulator are relying on SP.Velocity == 0 for vehicles.
So add and use SP.GetWorldVelocity() instead when we need vehicle velocity, along the same lines as existing SP.GetWorldRotation()
As per http://wiki.secondlife.com/wiki/LlSetStatus
Setting STATUS_BLOCK_GRAB_OBJECT prevents or allows move of a physical linkset by grab on any prim.
Setting STATUS_BLOCK_GRAB prevents or allows move of a physical linkset by grab on a particular prim.
Previously, setting STATUS_BLOCK_GRAB would prevent drag via all prims of the linkset.
As per http://msdn.microsoft.com/en-us/library/system.random%28v=vs.100%29.aspx, the .NET Random class is not thread-safe.
If called by multiple threads at once, methods may return 0.
Except for llRand(), other OpenSimulator code did not lock before calling a shared Random instance.
This commit adds a ThreadSafeRandom class that extends Random but does internal locking so that it is thread-safe.
This change is invisible to existing callers and the explicit locking in the llFrand() implementation is now redundant.
We have to do this since we can't unload existing DLLs if they're all in the same AppDomain.
But we can still update the underlying DLL which will be used in the next simulator session.
Code was identical apart from error logging, but if there are failures creating these directories then you'll be
seeing lots of errors anyway, and these will be more informative
If the C# column can't be found in the positionMap (but the line can),
use the map immediately after it while correcting for the offset,
unless that results in an LSL position before the previous LSL position
in the positionMap.
The idea behind this heuristic is that in most, if not all cases C#
consumes more characters than LSL (for example LSL_Types.LSLInteger
instead of just 'integer').
Thus if the distance between the columns of two markers differ in
the C# and LSL file, the distance in the C# file will be larger.
Moreover, we can assume that every time this happens we will have
a marker at the beginning of the longer 'keyword', because those
keywords were generated by us in the first place.
For example:
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
1 2
will always have markers at the beginning of the long keywords
'LSL_Types.LSLInteger' and 'LSL_Types.LSLString'.
If an error is generated in between (for example at the beginning
of the function name 'f2') then the correct position is found
by using an offset relative to 2 rather than 1.
Note that a case where this isn't working correctly is
when the user adds extra spaces. For example:
LSL: integer f2( string s)
would still use the start of 'string' as reference and
then go backwards 3 characters only because the corresponding
C# still looks like
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
only 3 chars difference
and the reported error at 'f2' would be here:
LSL: integer f2( string s)
^
This can only be fixed by generating a mapping for 'f2' itself, or
generating a mapping whenever the amount of spaces is changed.
When a compile error reports a colum/error that is not an exact
match in the positionMap dictionary, the last position in the
map with a line number and position before the reported error
should be returned.
The old code had the following problems:
1) It returns l,c - which are line and column of the C# file, not LSL.
2) It doesn't set l to 'line' when the map has an entry with 'line'.
3) It sorts the map without taking columns into account, which may
result in a random order of the columns. With my mono implementation
the columns were reversed in order.
For example, if the map contains the following lines:
99,5,49,10
100,30,50,10
100,40,1,0
101,5,51,10
and a translation of 100,35 was requested,
then the old code would compare '100' with the keys in
the first column - setting l to that key while it is
smaller. Hence, l is set to 99.
Then it finds the key 100 and doesn't update l.
Because of the reversed sort order, it first compares
the column 35 with 40, finding that it is smaller
and therefore it stops; returning 99,1 instead of finding
the correct 100,30 entry and returning 50,10.
This patch causes 50,10 to be returned.
The remaining problems after this patch are:
1) The sorting might not be necessary at all.
2) The is code duplication (I fixed both instances,
but really there should be no code duplication
imho).
This is because jump statement generation was mistakenly inserting its own line without updating the csharp positions in CSCodeGenerator.
This is Aleric Inglewood's patch in http://opensimulator.org/mantis/view.php?id=7195 but applied to opensim itself rather than the defunct code generation in opensim-libs. Thanks!
This patch also adds a regression test for this case from myself.
