Despite the comments in the code, it appears that the issue where the .NET performance counter was wrongly idle time time on Mono was fixed in 2009.
https://bugzilla.novell.com/show_bug.cgi?id=468625
Which means that the workaround is no longer necessary and produces bad results instead.
Another manifestation of this bug is that after a Hypergrid teleport, when you click on one of the avatar's attachments the object doesn't show its name. This means that the viewer knows the attachment is there, but the simulator does not.
The problem was caused by treating Hypergrid teleports as if they're Logins (because the teleport flag ViaLogin is enabled).
This may fix: http://opensimulator.org/mantis/view.php?id=7238
This may fix: http://opensimulator.org/mantis/view.php?id=7220
This caused the client to stop responding, and even the simulators to have problems. The solution is to disallow crossing before the previous cross has completed.
The "Sculpt" field in prims is used for both Sculpties (where the assets are Textures), and real meshes. Meshes require a different download URL than textures.
When sending an ImprovedInstantMessage to a group, the IM's binary bucket is supposed to contain the group's name (this is what SL does). Singularity uses this to show the group name when it shows the message at the bottom of the viewer for a few seconds: "[Group Name] From User: Message". Before this update, the group name was empty ("[]").
This update doesn't have any visible effect in Firestorm, because it doesn't use the group name sent in the IM.
This, by default, enables terrain patches being sent to each avatar
from the avatar away (rather than the old outside-in pattern), only
sending terrain patches within the avatars view distance (making
view loading quicker), and sending multiple terrain patches per
protocol packet (making terrain loading and editing quicker).
when registering a new region.
Adds parameter "[GridService]SuppressVarRegionOverlapCheckOnRegistration=false"
that can be turned on to suppress the error check if a simulator's database
has old regions that overlap.
co-op should be more stable as it doesn't abort threads, which can trigger virtual machine instability
This change will be invisible to users as script DLLs are recompiled automatically where necessary, though the change won't take affect until the next simulator restart.
This change has no effect on existing script state.
If you want to continue using abort, set ScriptStopStrategy = abort in the [XEngine] section of OpenSim.ini
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
In commit e6080a38 (Wed Mar 19 00:29:36 2014) I renamed this from "debug stats record start|stop"
Unfortunately, I didn't do this fully so before this commit "stats record start|stop" will report a usage failure with the old debug text.
Unfortunately this is in the 0.8 release. The workaround is to repeat the last command twice (e.g. "stats record start start")
This will show an approximate grid size that doesn't count regions that are hyperlinks
Not particularly trustworthy since it will still count regions that are not active but were not deregistered (deliberately or due to simulator crash or similar)
"show regions" drops the owner id column but is till present in "show region"
"show regions" name column expanded to allow for longer hg regions (probably still too short, may eventually have to truncate rather than taking up huge screen space)
I think it's still useful to know this to show up any errors early, but it's reasonable to still carry on rather than throw an exception.
Follow on from Diva's commit 9643792
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).
AvatarFlyingGroundMargin and AvatarFlyingGroundUpForce set to 5.0 and
2.0 respectively which seems to give about the same action as in SL.
Also moved force addition to before the velocity to force computation
so the upward velocity is properly applied to the avatar mass.
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.
This should get around the exception reported in Mantis 7191 and 7204
by checking for the unbuilt child and rebuilding the linkset the next tick.
A warning message is output when this rebuild happens and this message is
clamped to 10 times in case there is a problem with a loop.
region creation thread. For varregions or simulators with many regions,
this will speed up simulator startup and elimiate some thread timeout
warnings.
For some reason as yet unidentified (feedback?) a threshold above 0.4 here causes the RawVelocity to move between a lower and upper bound rather than remaining constant.
The RawVelocity increased until it triggered the threshold update, at which point it started to decrease until it again triggered the threshhold update.
This delta-v was enough to exceed the checks in ScenePresence.SendTerseUpdateToAllClients() and produce jittery avatar flight because of the fluctuating velocity.
With a threshold of 0.4 (or 0, as with ODE), the RawVelocity remains constant in BulletSim and so avatar flight becomes mostly smooth - remaining occasional glitches appear to be a result of errors in distance extraploation.
There are no obvious problems with commenting out the threshold.
Misterblue, if this is wrong or I've missed some subtlety here, please feel free to revert and/or correct.
The same considerations may or may not apply to object velocity updates.
This is probably due to changes in the layout of the generated script preamble (using statements etc, ) in c8afc852 (Jan 17 2013).
Re-enabled existing regression test that exercises at least one case of this.
This is based on heavily mikemig's original patch in http://opensimulator.org/mantis/view.php?id=7149
but instead of exiting after the first IM delivery failure to presence information retrieved from the presence service
it will retry the lookup until the result matches the previous lookup.
This is to deal with the case where the agent is sent an IM whilst they are teleporting.
For non-root prim, eye offsets now need to be made relative to root prim if either camera-at or camera-eye are set.
Probably a regression since November 2013 when all sits were made relative to root prim to match viewer expections (and fix other bugs).
Addresses http://opensimulator.org/mantis/view.php?id=7176
These characters are used as placeholders for other characters: ": /". But we should search first for the exact string the user entered, and only if that fails then replace the characters and search again.
This was due to a silent uint overflow in ScenePresence.UpdateChildAgent() corrupting child agent positions
when the child agent was in a region with a greater x or y map co-ord than the root agent region
Probably introduced in beeec1c.
This still will not function properly with very high region map co-ords (in the millions) but other parts of the code don't handle this properly anyway.
Looks to address http://opensimulator.org/mantis/view.php?id=7163
This is to allow us to get useful information on messaging without being overwhelmed by the rest of groups debug.
Enabled with [Groups] DebugMessagingEnabled = true in config (default false)
Or "debug groups messaging verbose true|false on the console" (similar to existing groups setting).
Done for both xmlrpc and V2 groups.
This was because the "session ID" when the message template was copied was always replaced with the group ID, whereas a notice requires this to be the notice ID.
Instead just copy the "session ID" as is - other callers already have this set properly so replacing with group ID was redundant anyway.
Relates to http://opensimulator.org/mantis/view.php?id=7037
Previously we used a heuristic of checking if the entry position is 0 to differentiate between Teleport and Cross, but that doesn't work anymore since we've started providing the precise entry position for cross, too. That's required in order to ensure that the user is allowed to enter the parcel that he's walking into.
For a long time, possibly forever, the m_maxAssetRequestConcurrency was mistakenly passed in as a 30 ms timeout rather than as a concurrent connection limiter.
This didn't come to light until the timeout was actually used in recent commit faf9ba53
Since this hasn't been operational for a long time and in release candidate phase, commenting it out for now though will need to revisit this.
Relates to http://opensimulator.org/mantis/view.php?id=7165
Offline notices can still be controlled with the [Messaging] ForwardOfflineGroupMessages setting.
Looks to address more of http://opensimulator.org/mantis/view.php?id=7037
Only for Flotsam now for testing, but if approach works should be possible with core offline notices as well.
Justin Clark-Casey (justincc)