View Issue Details
8649 [opensim] [REGION] Script Functions minor always 2020-01-19 16:38 2020-01-20 19:33
Jeff Hall Windows  
Windows 10 - 64 bits  
normal Win 10-64 v1909  
Standalone (Multiple Regions)
.NET / Windows64
Firestorm 6.0.2 (56680)
LSL scripting - llForceMouselook not working properly
The lsl llForceMouselook function enables to set user's view into mouselook when needed for specific purposes when sitting on an object. The default behavior is to keep normal view if not specified but if we do use [llForceMouselook(TRUE);]on [state_entry] then user should enter into mouse look and after standing then sitting on another object it should be normal view since its default view.

It actually doesn't work properly anymore since user will only get into mouse look after a second sitting and once he stands and sits on another object without any mouselook forcing specification he will still be into mouse look until he stands and sits again.

Expected behavior with llForceMouselook(TRUE): user gets into mouselook view and gets back into normal default view after standing (when he will sit somewhere else after)

Actuel behavior with llForceMouselook(TRUE): user doesnt get into mouselook view when sitting on first time unless he sits a second time. After standing and sitting again on another object without mouselook forcing he will still be into mouselook until he sits and stands again.
1-Add llForceMouselook(TRUE) in state_entry section in one prim for sitting and no llForceMouselook in another prim (default). I include in current mantis ticket a zip file containing the 2 scripts that can be added into prims to see.

2-Sit on normal prim with no llForceMouselook: user will sit normally with default view and same after standing and sitting back on prim

3-Sit on other prim with llForceMouselook(TRUE): user will sit normally instead getting into expected mouse look. If you stand and sit again then you will get into mouse look while we should had been at first time. If we stand and sit on another sitting prim without any mouse look forcing then we will get into mouse look while it is supposed to be default view, not matter if prim is scripted or not. We need to stand and sit again to reset view to default one, which isn't expected behhavior.
Changes seem to have occured somewhere from to but i unfortunately cannot tell precisely when.

llForceMouselook Test

OpenSim versions:

OpenSim Yeti Dev OSgrid Yeti Dev 066a6fbaa1: 2019-12-18 23:26:13 +0000 (Win/.NET): NOT WORKING
OpenSim Dev OSgrid (Dev) 59afeb6: 2017-10-06 (Win/.NET): WORKING WELL

OpenSim Fest
Tachyon Sim Revsion_500b27_164321_011820 (Unix/Mono): NOT WORKING

OpenSim Snail Metropolis Edition: WORKING WELL


Firestorm 6.0.2 (56680) Feb 9 2019 10:23:10 (64bit) (Firestorm-Releasex64) with OpenSimulator support [^] [^] (1,648) 2020-01-19 16:38
2020-01-20 01:19   
Please test against master code rather than some third party binaries.
Jeff Hall   
2020-01-20 05:37   
(edited on: 2020-01-20 05:37)
@tampa: i did test different versions including two built for OSGrid which is considered to be the official opensim test grid (read notes above). I also suspect, as i said, the changes to have occured somewhere from to but i im not sure exactly when.

2020-01-20 05:58   
osgrid is a repackage, it is not master code. It is not the "official test grid" and has not been for quite a while now. We ask to test against master code, because what goes into third party distributions is not always clear and only something actually broken in the official version of OpenSim can be fixed.

Going between those two version numbers are months worth of commits numbering in the thousands, a bit more narrowing down is needed if there is any hope in figuring out what's wrong.

You can build older commits via a specific checkout or you can fetch older binaries from here: [^] however they only go back to 03.19
Jeff Hall   
2020-01-20 06:14   
I can always try looking at those versions you are refering though i'm not an opensim dev. Once that said though i detailled how the reproduce bug and it is obviously a bug no matter where it comes from, when considering that function usage with its explanation in wiki. To be investigated.
2020-01-20 06:19   
i do notice that also to true or to false
no idea.. that code had not changed, we i see the correct information sent to viewer.. it (FS) just doesn't do it
need to dig a bit more...
2020-01-20 07:18   
fwiw: OSgrid binaries are built directly from git and no patches are applied.
2020-01-20 08:19   
only dif i could see was a increased chance of out of order udp packets.
changed some code to reduce that.

physics sits where telling viewer to autopilot to object position.
Did disable that, so we have just a ugly unrealist jump

but needed for now. Viewer autopilot adds more chances for avatar state desync, still not handled.
2020-01-20 08:28   
and yes, before you ask, i know the camera orientation is still not good
Jeff Hall   
2020-01-20 19:33   
I am sure you are doing your best and ty for looking at Ubit.

View Issue Details
8503 [opensim] [REGION] OpenSim Core minor always 2019-03-21 14:50 2020-01-20 08:23
Data Rossini Linux  
Grid (Multiple Regions per Sim)
Firestorm 6.0.2
When Avi gets up after sitting he makes an unnatural air jump
When the Avi stands up after sitting, he jumps in the air and eventually gets stuck in the room ceiling in a closed room. The air jump is done under BulletSim as well as under the ODE Physics Engine. At the BulletSim it is striking that the Avi gets stuck. The problem came with OpenSim version 0.9. In version 0.8, the movement was still natural when the Avis stand up.
I have changed the relevant line of the file ScenePresence.cs version 0.9, as it was realized in version 0.8 and recompiled and the problem was gone. I will leave it that way for me.
Have testet with an old 0.8 version on my home grid and on Sandbox Plaza on OSGrid.
Mono 4.6, BulletSim, OpenSim 2018-06-29
Look at Gif movies/anims and the possible patch.


--- ScenePresence.cs.ori 2019-03-17 15:41:37.294160558 +0100
+++ ScenePresence.cs 2019-03-17 15:41:37.294160558 +0100
@@ -3211,7 +3211,8 @@ namespace OpenSim.Region.Framework.Scene
                     standRotationZ.Z = 0f;
- Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;
+ //Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;
+ Vector3 adjustmentForSitPose = new Vector3(0.74f, 0f, 0f) * standRotationZ;
                 Vector3 standPos = sitPartWorldPosition + adjustmentForSitPose;
                 m_pos = standPos; (2,803,104) 2019-03-21 14:50
calmerstandup.patch (1,119) 2019-03-21 21:51
2019-03-21 17:09   
If you don't push the avatar up it has the potential to get stuck inside the thing it was sitting on, ideally we would place the avatar outside of the bounding box of a what it has sat on, but maybe not above it.

HOWEVER, adding detection for bounding boxes or potential other prims nearby to keep away from adds massive overhead to the system. I would honestly file this under "won't fix", because to me the current behavior seems the least problematic option.
2019-03-21 18:25   
(edited on: 2019-03-21 18:27)
You could try making the object to be sat upon phantom; that way the avatar is more likely to fall through the object as they stand up rather than be ejected/pushed up by it. I've had to do this for a few objects on my grid but for the most part it's a non-issue aside from the oddness of seeing people blast off from their seats when they stand ;)

If you don't prefer the object to be phantom all the time you could have it go phantom via script upon sitting on the object and then after standing up have it go back to non-phantom (perhaps after a wait time of a second or two).

2019-03-21 19:03   
I wrote a small poseball script to automate the set/unset phantom process. Try it and see if that helps work around the issue:

vector MyOffset = <0.0, 0.0, -0.2>;

string MyTitle = "Sit On Me"; //Set text for pose ball
integer ShowPoseballOnStand = TRUE;

float PhantomTimer = 1.0; //How long to wait until script unsets phantom

string MyAnimation = "";

key SitterKey = NULL_KEY;

//Keeps track of whether object was already phantom before sitting.
//If the object was already phantom then the script won't bother
//to set and unset phantom status since it is already set by default.
integer WasPhantom = FALSE;

    if(MyAnimation == "" || llGetInventoryType(MyAnimation) == -1)
        MyAnimation = llGetInventoryName(INVENTORY_ANIMATION, 0);
    llSitTarget(MyOffset, ZERO_ROTATION);

DoAnimation(string anim, integer toggle)
    if(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)

        else if(!toggle)

    if(SitterKey != NULL_KEY)
        list anims_playing = llGetAnimationList(SitterKey);
        integer i = 0;
        for(i; i < llGetListLength(anims_playing); i++)
            DoAnimation(llList2String(anims_playing, i), FALSE);
        DoAnimation("stand", TRUE);
        DoAnimation("stand", FALSE);

ToggleVisible(integer toggle)
            llSetText(MyTitle, <1,1,1>, 1.0);
            llSetAlpha(1.0, ALL_SIDES);
            llSetText(" ", <1,1,1>, 1.0);
            llSetAlpha(0.0, ALL_SIDES);
        llSetText(" ", <1,1,1>, 1.0);
        llSetAlpha(0.0, ALL_SIDES);

TogglePhantom(integer toggle)
    llSetStatus(STATUS_PHANTOM, toggle);
    //llSay(0, "Phantom = " + (string)toggle);

    on_rez(integer params)

    changed(integer change)
        if(change & CHANGED_LINK)
            if(llAvatarOnSitTarget() != NULL_KEY)
                SitterKey = llAvatarOnSitTarget();
                WasPhantom = llGetStatus(STATUS_PHANTOM);
                llRequestPermissions(SitterKey, PERMISSION_TRIGGER_ANIMATION);
            else if(llAvatarOnSitTarget() == NULL_KEY)
                SitterKey = NULL_KEY;
                    if(PhantomTimer > 0.0)
    run_time_permissions(integer permissions)
        if (permissions & PERMISSION_TRIGGER_ANIMATION)
            if(SitterKey != NULL_KEY)
                DoAnimation(MyAnimation, TRUE);
2019-03-21 21:49   
(edited on: 2019-03-21 21:50)
The reason this was done, because in many case when the avatar stands up they could end up half in the ground, and end up being launched due to the physics overlap.

If you want to try it I made a much calmer version that still accomplishes the same thing ..

- Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;
+ Vector3 adjustmentForSitPose = new Vector3(0.74f, 0, m_sitAvatarHeight /2 + .1f) * standRotationZ;

2019-03-26 10:00   
yes there is a little jump by default.
reason it that we do not probe the potential stand position to check if the avatar will fit there, because that is a expensive operation.
physics engines react very badly if we tell them to rez a avatar overlapping another object. Most times you are sling shot to the moon, on the best cases you get stuck.
that little jump reduces the chances of that happening on normal situations.

ubOde is now more gentle on those overlap cases, but still has is moods.
old ode and bullet aren't.
Data Rossini   
2019-12-12 12:29   
(edited on: 2019-12-12 13:38)
I have it configurable for me in OpenSim.ini with the following few lines in ScenePresence.cs (OpenSim OpenSim Snail Dev from 20191028):

From line 3280:
                Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;

                IConfig sconfig = m_scene.Config.Configs["AviStandUp"];
                if (sconfig != null)
                        string mtd = sconfig.GetString("Method", "new");
                        if (mtd == "old")
                                adjustmentForSitPose = new Vector3(0.74f, 0f, 0f) * standRotationZ;

                Vector3 standPos = sitPartWorldPosition + adjustmentForSitPose;
                m_pos = standPos;

PS: Otherwise the OpenSim runs great.
My respect for the developers and thanks to all contributors.
Time for version 1.0.
Regards Data

2020-01-20 08:23   
did reduce the jump a bit. Let us know if avatar gets stuck or sent to moon using bullet

View Issue Details
8634 [opensim] [REGION] Script Functions feature N/A 2019-12-08 07:56 2020-01-20 08:23
Kayaker Magic Linux Mono  
OpenSim 0.9.1  
low 0.9.1  
Grid (1 Region per Sim)
Mono / Linux64
Request a method to set the position of an avatar when standing
When an avatar "stands up" while sitting on an object, several undesirable things can happen. Depending on the physics engine the avatar can get tossed up in the air, stuck inside or on top of nearby objects. It is common to mark furniture as phantom to prevent this, but problems still occur.

There used to be an undocumented feature where an avatar moved back to the sit target position when standing up. A script could set the sit target behind the chair, for example, and then move the avatar to the sitting position while animating her. Then when the avatar stood up she would find herself behind the chair. This no longer works, and hasn't worked since OpenSim 0.7 or so.

Experimentation seems to indicate that now when an avatar stands up they are moved one meter forward from where they are currently located. In the case of an avatar sitting on a stool in front of a bar, when they stand up they find themselves inside the bar, standing on top of it, or getting shoved around by the physics engine.

It would be nice to have a way to control what happens to an avatar when they stand up.
1) One solution would be to put back in the undocumented feature of moving the avatar to the sit target on standing.
2) Another would be to add an OSSL function that allows setting the location to move the avatar to on standing. (osStandTarget(key,vector)?)
3) Another would be to add an event (perhaps in changed?) that warns the script that the avatar is about to stand up. Then the script could move the avatar like a child prim to the desired stand up position. The current changed event is called AFTER the avatar is already unlinked from the object and it is too late to move them.
Data Rossini   
2019-12-11 01:56   
I also had problems with "stand up" Avis from prims since 0.9.
After standig up, the Avis stuck at in the ceiling above it (at usual room height).
Since a patch to 0.8 solution, it works better.
However, I only use the BulletSim physics engine.

v0.9.x line: 3280: Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;
v0.8: Vector3 adjustmentForSitPose = new Vector3(0.74f, 0f, 0f) * standRotation;

Also problematic are objects that lie in front of the seat, which I then either switch "phantom" or teleport the avi to a suitable position (in a confined environment) after standig up.

Example script snipplet after stand up:

   vector tppos = llGetPos();
   tppos.x = tppos.x + standup_offset.x;
   tppos.y = tppos.y + standup_offset.y;
   tppos.z = tppos.z + standup_offset.z;
   osTeleportAgent(user, tppos, <1,1,1>);

2019-12-11 06:37   
Just teleport them or make the object phantom for a bit after the avatar stands up.
Kayaker Magic   
2019-12-12 00:41   
OH! Great idea! Use a function that has THREAT LEVEL SEVERE just to land an avatar a meter or two away. Well it sometimes works, but usually SPAMs everyone in the region with error messages. Too bad there is no way to find out first if you have permission to call osTeleportAgent. Oh wait! I wrote a patch to add that! (Mantis 8634) But Ubit refuses to consider adding this to Master because "BAH! You don't need to know that!"

Making the chair phantom for a bit after the avatar stands up is problematical. Most people make all their furniture phantom to try and fix this. Then if you are lucky you end up standing in the middle of your phantom furniture. And then if you make it non-phantom after "a bit" that just puts off the problem "for a bit".

Curiously, it looks like someone is adding a new function osLocalTeleportAgent that currently has threat level NONE! This may solve the problem.
2019-12-12 02:19   
I mean I was taught not to stand on furniture anyways because that's kind of rude and non-sensical so I don't understand why anyone would want those things to be solid in the first place. Nevermind that I have not actually seen or heard anyone complain about this, it seems to me an accepted fact that there are limitations to the engine and that there are ways to deal with them in a reasonable manner that seems to satisfy most people.

Things that are "nice to have" are just that, non-critical stuff that really does not need to be over-engineered like that with its own ossl function or whatnot. Besides, if you are talking chairs, just fire a changed and move the chair back, you know, like normal people do when they get up.
Ferd Frederix   
2020-01-04 13:56   
I use llPushObject(llAvatarOnSitTarget,<0,0,100>, <0,0,100>, TRUE) and adjust the X and Y accordingly. Works in getting out of boats onto a dock, for one example I use. Can get fancier by adding in the rotation of the root prim.

Be nice if the Avi could be rotated, though. TP would be a good way to handle it - I wish I had thunk of it.
2020-01-04 14:56   
I also use push and teleport and I am not fully satisfied because the push lacks precision and the teleport reset the camera position when we get up.
Data Rossini   
2020-01-04 19:39   
This problem has been noticed since the change from version 0.8 to 0.9.
I have recently been using a patch for version Snail Dev from 2019-10-28, which I am using to alleviate the problem.
Here I can set in OpenSim.ini whether I prefer the old - or the new method of "standig up" the avi from a seat.

Example solution for new section in OpenSim.ini:
;; Activate section and set Method to "old" if avis stand up moderate with old method.
;; If you deactivate section or set Method to "new" then avis standup with actual method
Method = "old"

--- ScenePresence.cs.ori 2019-12-11 16:26:19.261352408 +0100
+++ ScenePresence.cs 2019-12-11 16:26:19.261352408 +0100
@@ -3277,7 +3277,15 @@
                     standRotationZ.Z = 0f;
- Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;
+ Vector3 adjustmentForSitPose = new Vector3(0.75f, 0, m_sitAvatarHeight + .3f) * standRotationZ;
+ IConfig sconfig = m_scene.Config.Configs["AviStandUp"];
+ if (sconfig != null)
+ {
+ string mtd = sconfig.GetString("Method", "new");
+ if (mtd == "old")
+ adjustmentForSitPose = new Vector3(0.74f, 0f, 0f) * standRotationZ;
+ }
                 Vector3 standPos = sitPartWorldPosition + adjustmentForSitPose;
                 m_pos = standPos;

But be careful! If you patch yourself, you have to know what you are doing and be aware that you may be able to destroy your OpenSim.

I also hope that the developers will offer a solution.

- Sorry for my bad english speaking
2020-01-14 02:56   
0.8 just used a offset identical to SL
but unlike current havok, our physics engines like so send you to the moon, if the avatar gets physical inside terrain or a prim.
since because of cameras, ceilings are usually very high, it is safer to set the position higher.
with current code, any value we use will have bad cases
adding a standing target could help, but scripter has no idea where the object will actually be placed.
on top of that we do have unscripted sits
2020-01-20 08:23   
did reduce the jump a bit. Let us know if avatar gets stuck or sent to moon using bullet

View Issue Details
8646 [opensim] [REGION] OpenSim Core feature always 2020-01-18 09:08 2020-01-20 07:31
patch included  
Grid (1 Region per Sim)
Mono / Linux64
The row "Expire" is still not implemted in "landaccesslist" on SqLite
The row "Expire" is still not implemted in "landaccesslist" on SqLite. (See PGSQL implementation)
Should be become implemented for sqlite to support the expire feature for banned avatars.
0001-Implementation-of-the-row-Expires-for-landaccesslist.patch (6,031) 2020-01-20 07:25
2020-01-18 10:08   
PGSQL implementation is not the best reference, because it is less tested than MySQL one
2020-01-20 05:59   
Sorry, I wrote this as example because I thought PGSQL Syntax/Interface is closer to SQLite than MySQL and I have seen "Expires" is already implemented there :-)
2020-01-20 07:31   
My try to implement this for SQLite. Seem to work. Please check/revisit it before commit to master. Thanks.

View Issue Details
8650 [opensim] [REGION] OpenSim Core major always 2020-01-20 05:13 2020-01-20 06:12
vladimir Djannovic windows  
windows server 2012  
Grid (Multiple Regions per Sim)
.NET / Windows64
restart simulator
when I run the restart command in the console, it cuts the simulator but does not restart.
Same way if I restart inworld.
2020-01-20 05:43   
Because that is not what the command does. Restart reloads the region from the simulator and that's it. How do you suppose a process that has shutdown can just restart itself without external help? If you want to properly restart your simulator simply type the shutdown command and create an external system to start the simulator when it is detected as being shut off. How you do that is up to you.
2020-01-20 05:49   
Do not use that comand. Never worked fine :(
specialy with more than one region per instance.
Even when we do sort it all, the .net framework will still be bad, not doing a full cleanup
2020-01-20 06:12   
(edited on: 2020-01-20 06:13)
This seems to be related to Windows Server.
With Windows 10 the "restart" command works.
The console does not close, and the log indicates activity.
With Remote Admin admin_console_command > restart this also works.
I have not tested with admin_restart > region_uuid, but I hope it works too.

View Issue Details
8562 [opensim] [REGION] OpenSim Core major always 2019-07-13 02:32 2020-01-20 05:13
Ar Eebus Windows 10  
aiaustin Dreamgrid 3.0  
normal 3.0 and 3.1  
no clue
Grid (Multiple Regions per Sim)
.NET / Windows64
Firestorm 6.0.2 & Singula
On Windows 10 1903 Cannot Set Landing Point and Cannot Set OpenSim Region Picture Cannot Activate Group
Cannot Set Landing Point and Cannot Set OpenSim Region Picture on Dreamgrid 3.0 and 3.1 on Windows 10 version 1903 OS build 18362.10000
When setting a landing point, trying to activate a group, trying to update a sim picture (in about land -> options -> Snapshot)
Go to About Land > Options and try to set landing point or Snapshot, it will not save.

in Comm --> Groups -> try to activate a different group, it will not work
Tried Firestorm 6.0.2 and sSngularity 64 bit
2019-07-13 14:25   
Check the work around here .. [^]
2020-01-20 05:13   
Fixed as described in [^]

View Issue Details
8282 [opensim] [REGION] Script Functions minor always 2018-01-22 00:53 2020-01-19 15:16
new 0.9.0  
Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Mono / Linux64
Firestorm x64
The PRIM_NORMAL, PRIM_SPECULAR and PRIM_ALPHA_MODE rules have getters for llGetLinkPrimitiveParams() (and related functions), but they don't have their counterpart for setting via llSetLinkPrimitiveParams(), although it's possible to set those properties via the viewer in Edit Window.
Create a script with the content:

default {
  state_entry() {
    llSetPrimitiveParams([PRIM_NORMAL, 0, "", <1.0, 1.0, 1.0>, ZERO_VECTOR, 0.0]);
In parallel, PRIM_ALPHA_MODE_* constants are not recognized by the script engine. A script calling llGetPrimitiveParams() to query the alpha mode of a face does not compile.

Missing values:
2018-01-22 12:15   
Yes, Set is a bit more complex to add that Get on our materials code.

so still on TODO :(
2018-02-05 06:37   
(edited on: 2018-02-05 06:40)
Some work on the Ruth 2.0 mesh body and nail attachment specularity is related to this.... [^]

I wonder if the OpenSim side could support the functions and constants and, for now, have no effect... in order that scripts compile without error and without needing special OpenSim variants.

2018-02-05 07:14   
Think is all there, but Set will report error parsing those parameters
i could make it silence ignore them, but that could make things very confusing for any other scripter not following this discussions.
2018-02-05 07:57   
(edited on: 2018-03-13 02:35)
Point taken @Ubit ... I was just trying to get things so that as Ruth 2.0 parts appear in OpenSim the scripts are ready to go if or when the SET functions are made to work, rather than such parts needing to have their embedded scripts changed.

2018-03-13 02:35   
(edited on: 2018-03-19 06:58)
I note some scripts for Ruth 2.0 have to have temporary workarounds to avoid this error... its a pity to start to get lots of new content out there that will need fixing later...

// Currently, llSetLinkPrimitiveParams(0,[ PRIM_SPECULAR...] has a bug. It will trigger
// an error in the script if it tries to execute the function.

2018-03-31 18:54   
(edited on: 2018-04-05 04:07)
I did make some changes to materials and add support for PRIM_NORMAL, PRIM_SPECULAR, PRIM_ALPHA_MODE on Set functions.

Note this was done on branch httptests, not master, and this needs .net4.6 (or mono 5x)

This code needs more changes, and may still have issues.

Avoid changing materials in diferent llSet* commands. Viewers may get informed of changes on each line, and may ask for materials that where meanwhile removed by the next command’s changes, but should work, just wasted bandwith and a possible warning on log about unknown material.

Note also that a change waits some 2 minutes before sending new materials to grid assets DBs. If region crashes or has a problem meanwhile, they are lost. But well, a region crash is already a problem :)

Also, as before, material IDs are not really unique, there is a small but not null chance of different materials getting same ID, and so assumed to be equal, this is a issue to try to fix later.

2020-01-19 13:05   
I get back on this ticket :)

If I understood well, each time a script modifies material properties, a new rendered material asset is created on the server? If yes, I understand the reticense on applying them.

I have notice that in SL, when changing material properties, the render is not *always* immediate, and not related to sim load. So that gave me an idea for an implementation:

When the viewer sends the new settings, it's put in a worklist of data (without render computation) associated to each asset it's applied on.

When the first request is sent to the simulator, a timer is set (something like 1 or 2 seconds, configurable in .ini). No stored asset creation is made in the database, only sent back to the viewer. When the timer gets over, the last loaded settings are used to create the asset.

Could this work?

If I get more info on what you have done (I am not sure to understand how you did it and what it implies), I will make a test if the current httptests branch contains your modifications.
2020-01-19 15:16   
(edited on: 2020-01-19 15:17)
If you see Ubit's post above yours, this was implemented(over nine months ago) ... and is in the latest release

View Issue Details
8647 [opensim] [REGION] OpenSim Core major always 2020-01-18 14:27 2020-01-19 05:10
patch included  
Standalone (1 Region)
.NET / Windows64
Material asset not being created if object is taken within 60 seconds
If an object is taken into inventory within 60 seconds of a material being set, the material asset is never created.

This is because the ObjectDelete event clears the queued persistance.

Attached patch ensures that the asset is not created on events like scripted kill, at which point the object no longer exists.

NOTE: Unfortunately this patch touches a lot of files due to an event change. It was a choice between this and creating a new event for DerezToInventory, i thought this was the better option. Opinions may vary :)
Rez an object
Set materials
Take to inventory
(Clear viewer cache and relog)
Rez object
0001-If-an-object-is-taken-into-inventory-within-60-secon.patch (25,962) 2020-01-18 14:27
0002-If-an-object-is-taken-into-inventory-within-60-secon.patch (6,567) 2020-01-19 05:09
2020-01-18 16:33   
but tried another way..
needs some checking..
2020-01-19 03:53   
Is your asset server and simulator so hopelessly overloaded or what's going on here? I cannot reproduce this at all.
2020-01-19 04:05   
(edited on: 2020-01-19 05:06)
You can't *not* reproduce it if you take the object within 60 seconds of setting a material (note you do need to clear your viewer cache). If you look at the code it's pretty obvious what happens, m_changed gets cleared before MakeAsset is able to run. Unless you've already made changes in that area.

@Ubit: Your fix is not good. It will persist materials if changed via script and then killed, allowing an easy DDoS vector to fill up the assets database with self-replicating objects.

A compromise may be to add an onDeleteToInventory event which will reduce the number of files which need to get touched.

2020-01-19 05:10   
I've added an improved patch which limits the number of files touched, without opening up the asset database to abuse.

I still think that my original approach was better, because providing information on why an action is taking place could be very useful in the future. But I guess your preference is form over function, fair enough.

View Issue Details
8645 [opensim] [REGION] OpenSim Core minor always 2020-01-18 08:47 2020-01-19 04:56
none master (dev code)  
Grid (1 Region per Sim)
Mono / Linux64
Singularity 64 bit
Many duplicates in the table "landaccesslist"
I found a bug with AccessList on using SQlite3. On each Start or Stop of a region will generate unnecessary duplicates in the table "landaccesslist".
Second problem is: you can never remove the entries via the viewer anymore (tested with the singularty-viewer).
You have to purge the data directly in the "landaccesslist" table with a sqlite-database-tool.
1) Set one or more Avatars in "About Land" -> "Acess" dialogue as Allowed and/or Banned.

Simply restart the region serveral times. 2 x should be enough for this test.

2) check the table "landaccesslist" with a sqlite3-tool:
select * from landaccesslist;

You see now some duplicates now.
0001-Fix-avoid-generating-of-many-duplicates-in-table-lan.patch (1,325) 2020-01-18 08:59
2020-01-18 08:59   
I found a simple fix to avoid this duplicates.
Sure, there are still more potential to improve more things around this, but this patch should be working for the first step to fix the above issue.

See attached patch...
2020-01-18 10:06   
just changed sqlite on that, not exactly using you patch.
It should work.. plz let us know
2020-01-18 12:09   
I have tested your modified commit:
No sorry, this does not work.
I can explain why:
You have left the wrong command:
is wrong in 2 cases:
1) The method Remove for the List of DataRow does delete the element from the list and do not mark the DataRow itself as deleted.
2) Removing elements from a list inside an iteratrion-loop is evil and a cause of many bugs.
You have "Peter", "Mary" and "Joe" in a list. So in an iter=0 you get "Peter". Do you remove it form the list and iter next to iter=1 you will get "Joe" as next and not "Mary" as expected, because "Mary" is now on iter=0.
I hope I explained it right :-)
That was the bug I seen on this. Removing the element from the list is not necessary in this case and produce the main problem here.
Only rowsToDelete[iter].Delete(); is the right case to do here :-)

I have used "foreach" instead of "for" iter, because I think that's nicer. But that is a personal preference of an developer. Both does the same :-)

for (int iter = 0; iter < rowsToDelete.Count; iter++)

does work.

for (int iter = 0; iter < rowsToDelete.Count; iter++)

does not work.

for (DataRow row in rowsToDelete)

does work.
2020-01-18 12:14   
did you run it and tested?
2020-01-18 12:43   
(edited on: 2020-01-18 12:54)

Mhhh ok, litte correction to my last notice: the explaining example above is not 100% correct to this issue. But similar.
Short: The Problem here was to change the delete-mark in reference on delete (marks only for delete and deletes not immediate. This is only done on commit) the row first and try to remove it from the list. That is not a good idea ;-)

Only removing the row from the list has no effect on the db. (Does not remove the row from the db)

2020-01-18 13:10   
(edited on: 2020-01-18 13:35)
ok changed to just "flag" delete
( the foreach is a lot heavier )

2020-01-19 04:54   
Yes, its working now.
thanks :-)

View Issue Details
8642 [opensim] [REGION] OpenSim Core major always 2020-01-16 02:33 2020-01-18 09:29
aiaustin PC  
normal 10  
new master (dev code)  
  master (dev code)
Grid (Multiple Regions per Sim)
.NET / Windows64
Viewers using default Linden Lab Bakes on Mesh (BoM) code are causing continuous repeated avatar bake cycles on servers
This issue is provided on the OpenSim Mantis to note issues that may require viewer changes and to help coordinate necessary viewer changes.

Now that people are using viewers which include fairly recent Linden Lab code for Bakes on Mesh (BoM), more hypergrid visitors for grids and OSGrid regions are causing repeating, never ending, baking cycles. The OpenSim.exe console will likely show the warnings.

This is a known issue and likely to be seen with any viewer based on recent LL code. The issue has been under investigation in testing updates to Firestorm to address the issue and to add code protective of older grids not based on the latest stable version of OpenSim.

Can people with connections to the various viewer developers please ask them to look at the fixes identified for Firestorm 6.3.6 as at r58523:c93fac05beb5 (11-Jan-2020) to consider whether change sin their own BoM handling code is required. [^]

Notes on specific viewers and versions :

Singularity Beta (repeated baking observed)
Singularity Beta (okay?)
2020-01-16-Repeating-Rebakes-OpenSim.log.txt (11,836) 2020-01-17 01:19
2020-01-16 02:41   
This rebake spam has been around a decade now with various causes, bad mesh, bad textures, faulty imports etc we finally need something that will blacklist the item/avatar from receiving new bakes when they do so 10 times a second or something. At least temporarily and not just because of this latest faux pas
2020-01-16 03:01   
(edited on: 2020-01-16 03:05)
I have to agree with tampa on this one, I don't think it is the BOM code per-say , but it may be triggering an old mesh baking issue ..

The baking issue can usually be tracked to piece of bad mesh, and yes it can be one that worked for ages, that has now gotten cached badly ..

I have personally not seen the bake spam for ages ..

2020-01-16 06:04   
(edited on: 2020-01-16 06:09)
Could be the cause. I was just seeing multiple, never ending bakes warnings on a dev master region and made the assumption it was related to the same issue observed until the Firestorm 6.3.6 (in preparation) fixes were made by Beq Janus.

Here are two instances of the repeating entries of a user on Singularity Beta visiting a dev master (latest) OSGrid region...

09:51:55 - [AVFACTORY]: Received texture update for randa agrawal 95aef5c3-3564-4440-bc83-538ea7e90623
09:51:55 - [UpdateBakedCache]: cache hits: 0 changed entries: 0 rebakes 5
09:51:55 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture 66a10f60-9fdb-4f08-b296-99d953014e7b
09:51:55 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture 5775437e-0644-4306-9110-e958c3b3a0b7
09:51:55 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture bdf230aa-7c93-46bf-9107-cb62abaace4f
09:51:55 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture 4348070f-8afa-4e87-8c13-e31dce2ac7b4
09:51:55 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture f0fc12ff-ddff-48a5-ab66-329a0a654e12
09:51:55 - [AVFACTORY]: Received texture update for randa agrawal 95aef5c3-3564-4440-bc83-538ea7e90623
09:51:55 - [UpdateBakedCache]: cache hits: 0 changed entries: 0 rebakes 5
09:51:56 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture 229cfa99-e9d5-4a37-a857-5e30de3ab65e
09:51:56 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture 360cb3f5-0534-4f91-8d1d-60ae95be3c79
09:51:56 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture a4235be8-606b-4ac8-82e6-2b733d686e61
09:51:56 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture 52286476-faf1-418e-bc61-6d51355269fa
09:51:56 - [UPLOAD BAKED TEXTURE HANDLER]: Received baked texture aaa0169f-655a-4d80-8329-d65f5fac0cba

Then LOTS and LOTS of exactly the same blocks of repeating messages each with cache hits: 0 changed entries: 0 rebakes 5 and differente bakes texture UUID in each block. Repeated until user moved off the region.

2020-01-16 10:04   
I would think a simple piece of code to check whether the same bake for the same uuid has been run more than X times in the last 30 seconds should be enough to at least prevent the spam. Going along with a red warning that potentially bad mesh or object is causing bake failures, that would be more helpful to the user compared to just console spam.
2020-01-16 11:16   
we can not change old opensim versions.
some viewers may decide to not suport those older opensim versions..
cool vl tries to work around that issue
Next Firestorm for opensim will also.

after this, old versions of opensim may need to use old versions of viewers.
2020-01-16 11:52   
Ubit, I observed this on server code latest dev master 2020-01-12 21:29.
2020-01-16 11:55   
Sorry, then the conditions that do trigger the issue, are not clear
2020-01-16 12:05   
(edited on: 2020-01-16 12:06)
I will report what I can.

Visitor to region OSGrid region RuthAndRoth2 and was using Singularity Beta I will see if I can track down the visitor and ask what they might have on as an outfit.

Region running on Windows 10 using OSGrid 18-Dec-2019 release overwritten by dev master code as at 2020-01-12 21:29.

2020-01-16 12:11   
if you have the logs, or next time, the rebake message does tell the layer(s) and uuids
2020-01-16 13:03   
(edited on: 2020-01-17 01:18)
That does seem an old Singularity. Tried to install a recent one, but installer failed to verify the package integrity on the last 2 versions.

2020-01-16 14:00   
(edited on: 2020-01-17 01:57)
Does this longer log help? Log of user coming in to dev master grid using Singularity Beta Singularity Beta - attached as 2020-01-16-Repeating-Rebakes-OpenSim.log.txt

Avatar involved was an OSGrid avatar and they told me that they only used a standard starter avatar on OSGrid (Elle).

2020-01-18 04:18   
What can sometimes help with worn mesh, rez it out in the region, let the textures load and then attach it to avatar rather than inventory. Also helps to clear region and viewer caches and then do that. There really is no single way to solve it from what I experienced.

The bigger issue is still the spamming, because that not only obfuscates other issues, but also ends up filling logs and memory. The console output should try to detect repeats or limit output when too much is being sent in X amount of time instead of the spam.
2020-01-18 08:11   
But the underlying cause is repeated baking multiple times per second, with different UUIDs generated for the bakes each time as far as I can see.. and this with a simple default OSGrid avatar the user told me. However crazy a viewer goes we don’t really want the sever just taking what comes maybe.

However, recall the real purpose of this mantis issue is to note which viewers we see such issue on so those in touch with the viewer dev community can request or coordinate with viewer developers to fix things.
2020-01-18 09:29   
To fix the BoM issue you need more data, while in there might as well write code to suppress the log spam and gather the info needed. Whatever fix you apply, given this whole thing can be a total can of worms, may not solve all issues and more may arise. Having, then, a clear indication and readable log rather than spam is going to put down the groundwork to get future issues solved more effectively. That's really all I am after, while we are in the rabbit hole, might as well dig deeper you know.

View Issue Details
8643 [opensim] [REGION] OpenSim Core block always 2020-01-16 09:59 2020-01-18 04:15
none master (dev code)  
Grid (1 Region per Sim)
Mono / Linux64
Parcel Settings Access is not longer working!
I can not longer change Access-Parmeter in About Land. Why is this disabled? I don't understand this neccesary of this?

This issue occures since commit
disable parcels access control if disabled at estate ( not that estate flag is still named TAXFREE)

What is TAXFREE? I can't see this option in Singularity?

2020-01-16 10:49   
TAXFREE is just a internal opensim name for a flag bit
the same bit is now resused, to control parcel owner right to override parcel access. It will be renamed one day.
And if parcel owner right is disable at estate, parcel access tab is disabled.
estate access will be the only active.

you can see that option on up to date viewers on region/estate, estate tab. with the label "parcel owners can be more restrictive"
2020-01-16 11:02   
viewer devs should know it as
2020-01-17 00:35   
OK, I understand it a litle bit more now.
But Singularrity (latest test-beta) does still not support this ACCESS_OVERIDE?

Is there a way to set this FLAG per default to true on first install or migration of an region?
I have over hundreds of regions to migrate. Doing this all with an Viewer is a little heavy to me ;-)

2.) I found another Bug with AccessList on using SQlite3. On each Start or Stop of an Region will generate unnecessary duplicates in the Table "landaccesslist"

3.) The row "Expire" is still not implemted in "landaccesslist" on SqLite? (See PGSQL implementation)
2020-01-17 00:56   
unfortunatly defualt value of that flag is false.

i can negate the meaning of the flag, that way the default will automaticly be to allow parcel owner access control.

of course regions that did fix it, will have issues now :)
but that should solve this issue

this setting was introduced ages ago on some viewers like FS or cool VL
and i did add some partial suport for it also, last changes where actually enforce it, region side, didn't notice some still did not had it ( or don't have it for opensim only ??)
2020-01-17 01:38   
ok i did inverted the meaning of the internal flag temporary named TAXFREE, so the default value of false will mean allow parcel owner access control.

this should reduce the impact of this feature on older regions

Please let me know what i did broke in the process ;)
2020-01-17 06:45   
Ty, that will help me a lot.
But I can't currently test that because I have currently a compile-problem:
[csc] /opt/opensim/DeepImpact/OpenSim/Region/Framework/Scenes/Scene.cs(6031,56): error CS0103: The name `GCLargeObjectHeapCompactionMode' does not exist in the current context
[csc] /opt/opensim/DeepImpact/OpenSim/Region/Framework/Scenes/Scene.cs(6035,56): error CS0103: The name `GCLargeObjectHeapCompactionMode' does not exist in the current context
[csc] /opt/opensim/DeepImpact/OpenSim/Region/Framework/Scenes/Scene.cs(6035,24): error CS0117: `System.Runtime.GCSettings' does not contain a definition for `LargeObjectHeapCompactionMode'

nant clean
and && nant -t:mono-4.5 does not work.
I use Ubuntu 19.04 and mono currently.

Do anybody have any idea how to fix this in a quick way?

2020-01-17 07:06   
Use msbuild and upgrade to stable mono and it will compile properly
2020-01-17 07:20   
nant -t:mono-4.5 ??
we are a bit outdated no?
use msbuid. xbuild still works also
ms/xbuilt /p:Configuration=Release
2020-01-17 10:08   
Mhhh i tried this:
> xbuild /p:Configuration=Release

>>>> xbuild tool is deprecated and will be removed in future updates, use msbuild instead <<<<

XBuild Engine Version 14.0
Mono, Version
Copyright (C) 2005-2013 Various Mono authors

Build started 1/17/2020 7:02:22 PM.
Project "/opt/opensim/DeepImpact/OpenSim.sln" (default target(s)):
        Target ValidateSolutionConfiguration:
                Building solution configuration "Release|Any CPU".
        Target Build:
                Project "/opt/opensim/DeepImpact/ThirdParty/SmartThreadPool/SmartThreadPool.csproj" (default target(s)):
                        Target PrepareForBuild:
                                Configuration: Release Platform: AnyCPU
                                Created directory "obj/Release/"
                        Target GenerateSatelliteAssemblies:
                        No input files were specified for target GenerateSatelliteAssemblies, skipping.
                        Target CoreCompile:
                                Tool /usr/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /delaysign- /debug- /optimize+ /out:obj/Release/SmartThreadPool.dll CallerThreadContext.cs CanceledWorkItemsGroup.cs EventWaitHandle.cs EventWaitHandleFactory.cs Exceptions.cs Interfaces.cs InternalInterfaces.cs PriorityQueue.cs SLExt.cs STPEventWaitHandle.cs STPPerformanceCounter.cs STPStartInfo.cs SmartThreadPool.ThreadEntry.cs SmartThreadPool.cs SynchronizedDictionary.cs WIGStartInfo.cs WorkItem.WorkItemResult.cs WorkItem.cs WorkItemFactory.cs WorkItemInfo.cs WorkItemResultTWrapper.cs WorkItemsGroup.cs WorkItemsGroupBase.cs WorkItemsQueue.cs Properties/AssemblyInfo.cs obj/Release/.NETFramework,Version=v4.0.AssemblyAttribute.cs /target:library /warnaserror- /unsafe+ /checked- /define:TRACE /nostdlib /platform:AnyCPU /reference:/usr/lib/mono/4.0-api/System.dll /reference:/usr/lib/mono/4.0-api/System.Data.dll /reference:/usr/lib/mono/4.0-api/System.Web.dll /reference:/usr/lib/mono/4.0-api/System.Xml.dll /reference:/usr/lib/mono/4.0-api/System.Core.dll /reference:/usr/lib/mono/4.0-api//mscorlib.dll /warn:4
CallerThreadContext.cs(31,31): warning CS0414: The private field `Amib.Threading.Internal.CallerThreadContext.HttpContextSlotName' is assigned but its value is never used
SmartThreadPool.ThreadEntry.cs(17,39): warning CS0414: The private field `Amib.Threading.SmartThreadPool.ThreadEntry._creationTime' is assigned but its value is never used
SmartThreadPool.ThreadEntry.cs(24,30): warning CS0414: The private field `Amib.Threading.SmartThreadPool.ThreadEntry._lastAliveTime' is assigned but its value is never used
                        Target DeployOutputFiles:
                                Copying file from '/opt/opensim/DeepImpact/ThirdParty/SmartThreadPool/obj/Release/SmartThreadPool.dll' to '/opt/opensim/DeepImpact/bin/SmartThreadPool.dll'
                Done building project "/opt/opensim/DeepImpact/ThirdParty/SmartThreadPool/SmartThreadPool.csproj".
                Project "/opt/opensim/DeepImpact/OpenSim/Framework/OpenSim.Framework.csproj" (default target(s)):
                        Target PrepareForBuild:
                                Configuration: Release Platform: AnyCPU
                                Created directory "obj/Release/"
                        Target GenerateSatelliteAssemblies:
                        No input files were specified for target GenerateSatelliteAssemblies, skipping.
                        Target CoreCompile:
                                Tool /usr/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /delaysign- /debug- /optimize+ /out:obj/Release/OpenSim.Framework.dll AgentCircuitData.cs AgentCircuitManager.cs AgentUpdateArgs.cs Animation.cs AnimationSet.cs AssemblyInfo.cs AssetBase.cs AssetLandmark.cs AssetPermissions.cs AssetRequestToClient.cs AuthenticateResponse.cs AvatarAppearance.cs AvatarAttachment.cs AvatarPickerAvatar.cs AvatarPickerReplyAgentDataArgs.cs AvatarPickerReplyDataArgs.cs AvatarWearable.cs AvatarWearingArgs.cs BasicDOSProtector.cs BlockingQueue.cs Cache.cs CachedTextureEventArg.cs CapsUtil.cs ChatTypeEnum.cs ChildAgentDataUpdate.cs CircularBuffer.cs ClientInfo.cs ClientManager.cs CnmMemoryCache.cs CnmSynchronizedCache.cs ColliderData.cs ConfigSettings.cs ConfigurationMember.cs ConfigurationOption.cs Constants.cs Culture.cs CustomTypes.cs DAMap.cs DOMap.cs DoubleDictionaryThreadAbortSafe.cs EntityTransferContext.cs EstateBan.cs EstateSettings.cs EventData.cs ExtraPhysicsData.cs FriendListItem.cs GcNotify.cs GridInstantMessage.cs GroupData.cs IAssetLoader.cs IClientAPI.cs ICnmCache.cs ICommandConsole.cs IConsole.cs IGenericConfig.cs IImprovedAssetCache.cs ILandChannel.cs ILandObject.cs IMoneyModule.cs IPeople.cs IPlugin.cs IPrimCounts.cs IRegionCreator.cs IRegistryCore.cs IScene.cs ISceneAgent.cs ISceneEntity.cs ISceneObject.cs InventoryCollection.cs InventoryFolderBase.cs InventoryFolderImpl.cs InventoryItemBase.cs InventoryNodeBase.cs LandData.cs LandStatReportItem.cs LandUpdateArgs.cs Lazy.cs Location.cs LocklessQueue.cs LogWriter.cs Login.cs MainConsole.cs MapAndArray.cs MapBlockData.cs MapItemReplyStruct.cs MetricsCollector.cs MinHeap.cs MultipartForm.cs NetworkServersInfo.cs NetworkUtil.cs OSChatMessage.cs ObjectChangeData.cs OutboundUrlFilter.cs ParcelMediaCommandEnum.cs PermissionsUtil.cs PluginLoader.cs PluginManager.cs Pool.cs PresenceType.cs PrimeNumberHelper.cs PrimitiveBaseShape.cs PriorityQueue.cs RegionFlags.cs RegionHandshakeArgs.cs RegionInfo.cs RegionInfoForEstateMenuArgs.cs RegionSettings.cs RegistryCore.cs RequestAssetArgs.cs RestClient.cs SLUtil.cs SimStats.cs SurfaceTouchEventArgs.cs TaskInventoryDictionary.cs TaskInventoryItem.cs TerrainData.cs TextureRequestArgs.cs ThreadSafeRandom.cs ThrottleOutPacketType.cs UpdateShapeArgs.cs UserAgentData.cs UserProfileData.cs UserProfiles.cs Util.cs VersionInfo.cs ViewerEffectEventHandlerArg.cs WearableCacheItem.cs WebUtil.cs Client/IClientChat.cs Client/IClientCore.cs Client/IClientIM.cs Client/IClientIPEndpoint.cs Client/IClientInventory.cs ServiceAuth/BasicHttpAuthentication.cs ServiceAuth/CompoundAuthentication.cs ServiceAuth/DisallowLlHttpRequest.cs ServiceAuth/IServiceAuth.cs ServiceAuth/ServiceAuth.cs obj/Release/.NETFramework,Version=v4.0.AssemblyAttribute.cs /target:library /warnaserror- /unsafe+ /checked- /define:TRACE /nostdlib /platform:AnyCPU /reference:/opt/opensim/DeepImpact/bin/log4net.dll /reference:/opt/opensim/DeepImpact/bin/LukeSkywalker.IPNetwork.dll /reference:/opt/opensim/DeepImpact/bin/Mono.Addins.dll /reference:/opt/opensim/DeepImpact/bin/Mono.Addins.Setup.dll /reference:/opt/opensim/DeepImpact/bin/Nini.dll /reference:/opt/opensim/DeepImpact/bin/OpenMetaverse.dll /reference:/opt/opensim/DeepImpact/bin/OpenMetaverse.StructuredData.dll /reference:/opt/opensim/DeepImpact/bin/OpenMetaverseTypes.dll /reference:/usr/lib/mono/4.0-api/System.dll /reference:/usr/lib/mono/4.0-api/System.Data.dll /reference:/usr/lib/mono/4.0-api/System.Drawing.dll /reference:/usr/lib/mono/4.0-api/System.Web.dll /reference:/usr/lib/mono/4.0-api/System.Xml.dll /reference:/usr/lib/mono/4.0-api/System.Xml.Linq.dll /reference:/opt/opensim/DeepImpact/bin/XMLRPC.dll /reference:/usr/lib/mono/4.0-api/System.Core.dll /reference:/opt/opensim/DeepImpact/bin//SmartThreadPool.dll /reference:/usr/lib/mono/4.0-api//mscorlib.dll /warn:4
CSC: error CS2001: Source file `GcNotify.cs' could not be found
CSC: error CS2001: Source file `IImprovedAssetCache.cs' could not be found
                        Task "Csc" execution -- FAILED
                        Done building target "CoreCompile" in project "/opt/opensim/DeepImpact/OpenSim/Framework/OpenSim.Framework.csproj".-- FAILED
                Done building project "/opt/opensim/DeepImpact/OpenSim/Framework/OpenSim.Framework.csproj".-- FAILED
        Task "MSBuild" execution -- FAILED
        Done building target "Build" in project "/opt/opensim/DeepImpact/OpenSim.sln".-- FAILED
Done building project "/opt/opensim/DeepImpact/OpenSim.sln".-- FAILED



/opt/opensim/DeepImpact/OpenSim.sln (default targets) ->
(Build target) ->
/opt/opensim/DeepImpact/ThirdParty/SmartThreadPool/SmartThreadPool.csproj (default targets) ->
/usr/lib/mono/xbuild/14.0/bin/Microsoft.CSharp.targets (CoreCompile target) ->

        CallerThreadContext.cs(31,31): warning CS0414: The private field `Amib.Threading.Internal.CallerThreadContext.HttpContextSlotName' is assigned but its value is never used
        SmartThreadPool.ThreadEntry.cs(17,39): warning CS0414: The private field `Amib.Threading.SmartThreadPool.ThreadEntry._creationTime' is assigned but its value is never used
        SmartThreadPool.ThreadEntry.cs(24,30): warning CS0414: The private field `Amib.Threading.SmartThreadPool.ThreadEntry._lastAliveTime' is assigned but its value is never used


/opt/opensim/DeepImpact/OpenSim.sln (default targets) ->
(Build target) ->
/opt/opensim/DeepImpact/OpenSim/Framework/OpenSim.Framework.csproj (default targets) ->
/usr/lib/mono/xbuild/14.0/bin/Microsoft.CSharp.targets (CoreCompile target) ->

        CSC: error CS2001: Source file `GcNotify.cs' could not be found
        CSC: error CS2001: Source file `IImprovedAssetCache.cs' could not be found

         3 Warning(s)
         2 Error(s)

Time Elapsed 00:00:04.3469830

And I tried msbuild:
> msbuild
-bash: msbuild: command not found

Any ideas?
2020-01-17 10:13   

Update mono via [^]

Clear your working directory and do a git checkout of git:// [^]

Then ./

msbuild -maxcpucount:4 -m:4 -nr:false

That will build, if not your systems is missing dependencies that should be installed on any common linux setup so you broke something else
2020-01-17 10:55   
ok thank you, I will try that. mono 4 was my friend for years ;-) I Hope Mono 6 works stable :-)
2020-01-17 11:22   
I have updatet now:
> ./ -> OK
> msbuild -maxcpucount:4 -m:4 -nr:false
Microsoft (R) Build Engine version 16.5.0-ci for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

Parallel builds (/m: or /maxcpucount:) are not yet supported on Mono/Unix. Defaulting to /m:1
Build started 1/17/2020 8:16:40 PM.
Project "/opt/opensim/DeepImpact/OpenSim.sln" (default targets):

Target ValidateSolutionConfiguration:
  Building solution configuration "Debug|Any CPU".
Target Build:
  Project "/opt/opensim/DeepImpact/OpenSim.sln" is building "/opt/opensim/DeepImpact/OpenSim/Region/Application/OpenSim.csproj" (default targets):

  /opt/opensim/DeepImpact/OpenSim/Region/Application/OpenSim.csproj(230,2): error MSB4019: The imported project "/usr/lib/mono/msbuild/Current/bin/Microsoft.CSHARP.Targets" was not found. Confirm that the expression in the Import declaration "/usr/lib/mono/msbuild/Current/bin/Microsoft.CSHARP.Targets" is correct, and that the file exists on disk.

  Done building project "OpenSim.csproj" -- FAILED.
... many truncated lines with similar errors ...
    0 Warning(s)
    89 Error(s)

Mhhh the File does exist:
but not

Can this be an issue with case sensitive?
2020-01-17 11:30   
I have renamed this File and retry:
Final Error now:

CSC : error CS2001: Source file '/opt/opensim/DeepImpact/OpenSim/Framework/GcNotify.cs' could not be found. [/opt/opensim/DeepImpact/OpenSim/Framework/OpenSim.Framework.csproj]
CSC : error CS2001: Source file '/opt/opensim/DeepImpact/OpenSim/Framework/IImprovedAssetCache.cs' could not be found. [/opt/opensim/DeepImpact/OpenSim/Framework/OpenSim.Framework.csproj]
    0 Warning(s)
    2 Error(s)
2020-01-17 11:34   
(edited on: 2020-01-17 11:38)
This seems not in master git?:
git checkout master OpenSim/Framework/GcNotify.cs
error: pathspec 'OpenSim/Framework/GcNotify.cs' did not match any file(s) known to git
git checkout master OpenSim/Framework/IImprovedAssetCache.cs
error: pathspec 'OpenSim/Framework/IImprovedAssetCache.cs' did not match any file(s) known to git

2020-01-17 12:00   
Like I said, clear your working directory and do a clean checkout of the git master instead of merging things, then it will build.

Else you can grab binaries both from the wiki [^] and previous builds from here: [^]
2020-01-17 14:02   
No, merging some things are neccesary in my case. ;-)
But that was not the problem. After some investigations I think the Problem was the File OpenSim/Framework/OpenSim.Framework.csproj
it differs to clean checkout in a new Folder. I don't understand why, because I have definitely cleared it with nant clean and ./ before I compile with msbuild -maxcpucount:4 -m:4 -nr:false
I should write a script to delete all this *.csproj files or the whole OpenSim-directory before checkout and run
I think I have some issues with
I will make some further tests tomorrow...

Sorry for spamming this mantis on my fault, but I don't be happy while I have not solved this problem ;-)
2020-01-17 14:59   
my scrubit script for cleaning the build dir ..

echo "Scrubbing Directories"
find . -name "*.csproj" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.csproj.user" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.build" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*Temporary*" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.cache" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.rej" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.orig" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.pdb" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*.mdb" -type f -print0 | xargs -0 /bin/rm -f
find . -name "*obj" -type f -print0 | xargs -0 /bin/rm -rf
find . -name "obj" -type d -print0 | xargs -0 /bin/rm -rf
find . -name "*.swp" -type f -print0 | xargs -0 /bin/rm -f
2020-01-18 01:16   
sounds like you are even runing a old version of prebuild
use the one we do provide on bin folder
2020-01-18 02:30   
(edited on: 2020-01-18 02:38)
Meanwhile I can compile now successful with msbuild.
The problem was on my side. I had commented out the vs2015 target in, because it was not found on my older mono installation und was only using 'nant -t:mono-4.5' to compile (not xbuild or msbuild)
So I have never noticed the outaged *.csproj files all the time in my environment.
Sorry for bother you with this.

Back to topic now:
I could testing sucessfull your last commit für negating the TAXFREE-flag.
You can close this mantis now as resolved, if no one other found an another bug or problem relating to this. :-)
For the further issues (2. and 3. see above) with the sqlite-implementation of the landaccesslist whe should open an extra mantis-ticket for this? I can try to fix this by myself, because I have some knowledge with the sqlite-interface and have already an idea how to fix this... or do you want to fix this, if you are faster than me? Then I will wait for the fix by you or other core-developer... :-)


2020-01-18 03:42   
better open a new mantisn on that sqlite issue

View Issue Details
8644 [opensim] [REGION] Specific OpenSim Module minor always 2020-01-17 13:03 2020-01-17 13:03
djphil PC  
normal 10  
Grid (Multiple Regions per Sim)
.NET / Windows64
[DataSnapshot] data_exposure setting no difference in the data
There is no difference in the data between using "minimum" or "all" for the data_exposure setting in OpenSim.ini
See Step's to issue#8 repported on github @ [^]
See issue#8 repported on github @ [^]
There are no notes attached to this issue.

View Issue Details
8641 [opensim] [GRID] Robust Server minor always 2020-01-15 12:18 2020-01-16 04:37
sebastian neverworld  
Windows 10 1903 x64  
Standalone (1 Region)
console loads like normal
server loads and everything seems normal all ports have been checked and our presence in the world is established my elf and a few others have tried tping to the sim and we get this error...

13:52:38 - [SCENE COMMUNICATION SERVICE]: Informing 0 neighbours that region minimadman is up
13:53:49 - [LAND HANDLER]: Got request for land data at 128, 128 for region 10973126047766272
13:53:49 - [LAND IN CONNECTOR]: GetLandData for 10973126047766272. Count = 1
13:53:49 - [LAND IN CONNECTOR]: Found region to GetLandData from
13:53:49 - [SCENE]: returning land for 128,128
13:53:52 - [BASE HTTP SERVER]: HandleRequest() threw exception System.FormatException: Input string was not in a correct format.
   at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
   at OpenMetaverse.Vector3.Parse(String val)
   at OpenSim.Server.Handlers.Simulation.AgentHandler.DoQueryAccess(Hashtable request, Hashtable responsedata, UUID agentID, UUID regionID)
   at OpenSim.Server.Handlers.Simulation.AgentHandler.Handler(Hashtable request)
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleContentVerbs(OSHttpRequest request, OSHttpResponse response)
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleHTTPRequest(OSHttpRequest request, OSHttpResponse response)
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleRequest(OSHttpRequest request, OSHttpResponse response)

13:53:52 - [LAND HANDLER]: Got request for land data at 136, 128 for region 10973126047766272
13:53:53 - [LAND IN CONNECTOR]: GetLandData for 10973126047766272. Count = 1
13:53:53 - [LAND IN CONNECTOR]: Found region to GetLandData from
13:53:53 - [SCENE]: returning land for 136,128
Region (minimadman) #

tried using different routers and different configurations using as opposed to internal ip and even used fix listed for similar situation was getting the code before any tps were attempted but after implementing fix it only happens during tp now
can log into sim and cant to tp it but can log in to other sims and other locations. working with static ip and port is set to 9000 had provider do port forwarding in accordance to console configuration

please forgive me if I posted this wrong and I am not asking in a manner in which it makes more sense than the way I am describing it's my first time using this and asking for help thanking you all in advance
2020-01-15 12:25   
Internal IP is used for NAT routing, for example, if you do not have the simulator behind NAT it should be

For the external IP you can use either the real WAN address of your network/system or if there is no NAT or other routing the SYSTEMIP variable works too.

Other causes for this include bad region names with special characters in it, bad configuration of service connectors etc

With "presence in the world" what do exactly do you mean? Is this a region connected to a grid or a standalone?

Have you tried logging in directly to the region from the viewer login rather than teleport? Does the error occur there as well?
2020-01-15 12:48   
its a region connected to a grid
2020-01-15 12:50   
and yes I have tried logging in that way that when the error occurs haven't tried tping there from another sim once I am able to log in
2020-01-15 12:55   
when I try the and setting external to system it says teleport failed and service request failed unable to connect to the remote server
2020-01-15 13:50   
you need to make sure you have the correct ports forwarded in your router, and any software firewall on the PC ..

External IP should be your real world IP , the external address of your router.
2020-01-16 04:37   
that seems to be a Culture issue, somehow still present on you setup
( this means use of comma as decimal separator instead of dot)

View Issue Details
8640 [opensim] [REGION] OpenSim Core minor always 2020-01-14 02:17 2020-01-14 13:44
aiaustin PC  
normal 10  
new master (dev code)  
  master (dev code) 2020-01-12 21:29
Grid (Multiple Regions per Sim)
.NET / Windows64
Firestorm 6.0.2
Clicking on a chat location URL either does not retrieve the region details or show on map is using a HG URL on home grid
I am having recent trouble with the clickable URLs inserted in local chat for the region you teleported away from. This report is for a simple test where all regions involved on one grid (OSGrid). I am using Firestorm, and this replicates on the old stable 6.0.2, as well as later experimental versions I am using. I am moving to an fro between a home region "Vue-Port" and another region "RuthAndRoth". The region details, region profile style image, etc is retrieved in the case of both links shown in nearby chat:

hop:// [^]
hop:// [^]

Except that the region name being looked up is the full hypergrid address

See attached image 2020-01-14-OSGrid-Firestorm-Mix-Up-of-Region-Names-in-Show-On-Map-Clicks.jpg

The links when clicked do work, and the map details change to drop the grid URI element if the map is used when actually on the destination region.

BUT... when I have another region running with a similar but not identical name "RuthAndRoth2"... things appear to get mixed up. Clicking on the RuthAndRoth link then fails to bring up the region details, and the profile image remains a "?". The show on map button fails to complete the Map tool information. See image Firestorm-Click-on-Chat-Hop-Link-Fails-if-Exists-Region-Names-Similar.jpg

BUT... if I restart the similarly named image with just the region name changed (to "R2-Backup" in this experiment) then click on link details show and the button to show on map works correctly again.

I have done the obvious things of checking do not have the same UUID for the regions (I don't) and the two OpenSim.exe instances for the RuthAndRoth and RuthAndRoth2 regions are on different servers and ports. Nothing I can find in the .ini configurations indicate any overlap.

Starting RuthAndRoth and RuthndRoth2 in either order appears to have no effect. Its always RuthAndRoth hat when clicked in nearby chat fails to retrieve its region information or show on map.

2020-01-14-OSGrid-Firestorm-Mix-Up-of-Region-Names-in-Show-On-Map-Clicks.jpg (355,153) 2020-01-14 02:17
2020-01-14-OSGrid-Firestorm-Click-on-Chat-Hop-Link-Fails-if-Exists-Region-Names-Similar.jpg (270,278) 2020-01-14 02:17
2020-01-14 02:31   
This is a viewer side issue
2020-01-14 03:13   
(edited on: 2020-01-14 03:16)
That looks to be the case Ubit... it works fine in Singularity but not Firestorm 6.0.2 or later versions I tested.

Maybe some sort of partial region name matching is taking place.

On OSGrid a region named "Marineville" existed I had a region named "Outer Space". Clicking on the links in chat for both works fine. I then renamed the "Outer Space" region to "Marineville2" and after restarting and then clicking on the link in chat to Marineville it fails, clicking on Marineville2 works.

I replicated this on another grid (AiLand) too, just to check it was not a special setup thing on OSGrid.

I will start a Firestorm JIRA on this.

2020-01-14 04:01   
Come to think of it I don't think I have ever seen that work, especially not in FS. The top navigation bar is supposed to also work by inputting the region name you want to go to, but last I tried I ended up just being teleported to the default region or nothing happened at all. It's a bit odd this doesn't work "well" as the protocol is the same and whether HG or not the destination is too.
2020-01-14 04:44   
I have started an FS JIRA as its clearly been an issue that has been around a while. I can see the same on OSGrid where I have regions named Castle, Castle Spring, Castle Autumn and Castle Winter as region names. The clickable link for Castle fails, the others work. [^]
2020-01-14 13:44   
I cannot reproduce the behaviour using slurls in SL, so I am going to look at the specifics around hop:: url processing. an over eager regex perhaps

View Issue Details
8639 [opensim] [REGION] OpenSim Core minor sometimes 2020-01-08 01:40 2020-01-14 02:42
CasperWarden N/A  
UbitUmarov N/A  
normal N/A  
Standalone (1 Region)
.NET / Windows64
[PATCH] CreateSelected gets lost when ObjectUpdate packet overflows
The CreateSelected flag is intended to be sent ONCE, so the flag is cleared the first time CreatePrimUpdateBlock is called.

However, if the ObjectUpdate overflows into a second packet, CreatePrimUpdateBlock is then called a second time which loses the CreateSelected flag.

This disrupts viewer import of objects as well as some other tools.
0001-Fix-CreateSelected-flag-getting-lost-when-an-ObjectU.patch (2,481) 2020-01-08 01:40
2020-01-08 02:13   
Thanks for your report and patch
Applied your changes directly (by hand) to my work copy, extending them to compress updates also.
i will commit when im ready to commit other changes i already had on same file.
2020-01-08 02:27   
nevermind, commited to master repo

View Issue Details
8550 [opensim] [REGION] Specific OpenSim Module minor always 2019-06-19 10:03 2020-01-13 00:28
Kubwa Computer  
high 10  
Grid (1 Region per Sim)
.NET / Windows64
Copying Object inworld and Timeout handling
When copying an object inworld (holding shift-key and moving the object), the new object does not show up immediately when the objects creator comes from a grid which no longer exists.
Even the edit menu stays unavailable for a longer time.

The simulator is trying to contact that grid several times which results in timeouts.
If you dont see that the object is not reproducesd immediately and you move the "new object" into its new place, the copy rezzes at the new objects location. That results in having that one object two times in the new location and no object where it should stay at.
- Restart an simulator to make sure the grid cache is empty.
- Grab an item with an creator, coming from a grid which does not exist anymore.
- Hold the shift-key and move the object with build tools.
- The copy now does not rez and the regions console shouts timeout errors.
- After the region tried several times, the objects copy rezzes at the new location, not the old (which is wrong)
Console output of region:

18:48:42 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.
18:48:42 - [USER MANAGEMENT MODULE]: GetServerURLs call failed Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.
18:48:44 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.
18:48:44 - [USER MANAGEMENT MODULE]: GetServerURLs call failed Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.
18:49:27 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Timeout für Vorgang überschritten
18:49:27 - [USER MANAGEMENT MODULE]: GetServerURLs call failed Timeout für Vorgang überschritten
18:49:37 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Timeout für Vorgang überschritten
18:49:37 - [USER MANAGEMENT MODULE]: GetServerURLs call failed Timeout für Vorgang überschritten
18:52:00 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Timeout für Vorgang überschritten
18:52:00 - [USER MANAGEMENT MODULE]: GetServerURLs call failed Timeout für Vorgang überschritten
18:56:05 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Timeout für Vorgang überschritten
18:56:05 - [USER MANAGEMENT MODULE]: GetServerURLs call failed Timeout für Vorgang überschritten
18:56:15 - [USER AGENT CONNECTOR]: get_server_urls call to [^] failed: Timeout für Vorgang überschritten
2019-06-19 10:10   
I would guess this is not a opensim problem considering the host is unreachable ..


Pinging [] with 32 bytes of data:
Reply from Destination host unreachable.
Reply from Destination host unreachable.
Request timed out.
Request timed out.

Ping statistics for
    Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
2019-06-19 10:12   
yep, as i said, the grid no longer exists :)
OpenSim could start rez the new object before it tries to contact that grid. The problem here is, that it takes a few seconds until it rezzes due to the not existing hostname.
2019-06-19 10:13   
lpgrid is gone, BTW, it no longer exists ..

I do believe that the owner passed away ...
2019-06-19 10:14   
(edited on: 2019-06-19 10:16)
If you are copying an object that was gathered from the HG, there is no way around this as it contacts the grid for creator information ..

Can't have that timeout too quick because of slower grids and home based grids, danger of not preserving creator info for existing creators and items ..

2019-06-19 10:17   
Well, the problem will get bigger the more grids will close. One day, people will have most of their inventoryobjects made by users from grids, they no longer exist.
Cant we lower the timeout for creator information requests and make opensim stop trying to fetch them multiple times?


adding a cache to the region which remembers, that requests to that grid were broken in the past and not trying it again?
2019-06-20 05:29   
A cache would be subject to stale entries and not attempting to fetch them over time would mean temporary grids would be lost in the loop. There simply is no way around this that would not also open up more holes in the process and not preserving or doing our level best to preserve the creator information just does not look good given that OpenSim already has a certain reputation.

Remember, OpenSim is database driven, so there are ways around most such data issues.
2020-01-11 23:18   
(edited on: 2020-01-11 23:24)
The problem gets bigger and bigger with every grid goinf offline. Me and friends of mine are experiencing the problem described above with every 10th object. It makes building hard and nearly impossible.
This problem IS a bug!

It can't be the solution to manipulate the database to resolve this issue. It's a problem the simulator has to handle. Grids have to stay online 24/7. If someone shuts down his grid, it cannot be the problem of all other grids. And these other grids are getting more trouble the more grids are shutting down.

2020-01-11 23:27   
(edited on: 2020-01-11 23:29)
This is one of the issues, of supporting, user home based grids, run on home ISPs and home routers ...

If you make these timeouts too short, and the retries too few, then a lot of hypergrid items are going to break ...

It is a the nature of the beast pretty much ...

And as far as having a cache .. That again would be hit and miss, and items that could be update, don't get updated because the cache forever is set as it is down ..

2020-01-11 23:31   
And just on a side note, I can hear the creators screaming now, because someplace . "temporarily" could not retrieve creator info, and so now someone has a bunch of items rezzed with the wrong or no creator info .. I think also a mechanism like this would be a copybotters dream, as it could make spoofing creators even easier ..
2020-01-11 23:37   
(edited on: 2020-01-12 00:02)
First of all, objects would not break if the creators info cannot be retrieved. The objects xml structure is untouched when the simulator gets a timeout.

It also has nothing to do with copybotters. Copybotters arent copying the creator data at all. So i dont see why there is argumented with copybotters. Its the creators fault (or his grid admins) when creator data cannot be retrieved (which still is temporary).

As i said... Look into the future of opensim... It will become heavily unusable if this issue is not being fixed.

BTW: Hosting OpenSim on a home server is not the issue (iam doing it myself for now over 6 years, and my grid was online all the time and will stay online as long as iam active in opensim)... Even the bandwidth isnt an argument when you have 100mbit in both directions :)

2020-01-12 00:04   
yes but everyone running around the HG with things like Dreamgrid, are not always running on the best systems, but whatever ...
2020-01-12 00:06   
I hope we both can come together with the fact, that this issue is getting bigger and bigger and has to be resolved somewhere and somehow... otherwise opensims build tools getting unusable over time.
2020-01-13 00:28   
(edited on: 2020-01-13 00:30)
Kubwa is not suggesting altering the creator data... just having a mechanism for looking up data from other grids that is tolerant to that data becoming unavailable, which surely will be a very common occurrence as many grids come and go or may be run on demand. Similar issues could arise with long friends lists that include many hypergrid friends I would think.

View Issue Details
8630 [opensim] [REGION] Scripting Engine major always 2019-11-21 04:35 2020-01-11 04:11
Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Mono / Linux64
Memory Leak on YEngine
I believe this to be caused by dynamic textures not clearing as well, to a smaller part, http requests data sticking around.

Been monitoring a small test region with just a few scripts on them, over a day it has accumulated over 3gb of memory, initially started with 200mb: [^]

On other regions with more dynamic textures and http requests over time the leak is much more pronounced so much so I found a simulator consuming 32gb of memory up top its normal 4gb.

Spin up a simulator under YEngine
Create a script with periodic dynamic textures drawing and http requests
Watch memory usage go up and up and up
I first noticed this after switching from XEngine to YEngine without doing any other changes to the simulator and region, got a monitoring alert because the whole server was out of memory.

There was an old bug with XEngine not clearing dynamic textures very well, that has since been resolved though.
2019-11-21 05:01   
(edited on: 2019-11-21 05:01)
dynamic texture code is the same on X and Y. Engines only see UUIDs and not the bulk data, so one can leak if the other doesnt

2019-11-21 06:10   
As tampa and i seen, one of is test scripts shown no leaks on mono 6.0.??

He is using last stable 6.4 also with a new libgdi...
2019-11-21 06:14   
I will test with mono 6.0 as well after reverting back to snapshot and building new binaries. If that fixes it then we know it is probably related to changes in 6.4 release which is current stable for mono. This however means regardless it needs looking at because naturally mono website redirects to latest stable release so people will install that.

Assuming either changes to gc or libgdiplus are the culprits, but as Ubit said figuring that out might be very hard :S

Will report back with what I find on mono 6.0, for now I guess a careful warning not to use 6.4 in the meantime(add to wiki perhaps?)
2019-11-21 06:52   
So the issue can be traced to libgdiplus. After installing the distro version from ubuntu mirrors the problem went away.

apt purge libgdiplus
apt install libgdiplus=4.2-1ubuntu1

This means whatever changed in libgdiplus 6.0.4 is the cause of the leak under YEngine, meaning then either sticking to old version of libgdiplus or fixing what's broken :/
2019-11-21 08:37   
I created 4 cubes with the scripts tampa posted in a link on #opensim-dev@freenode yesterday on a simulator running XEngine and a simulator running YEngine.

In a first run over night (roughly 9 hours) I started only one of the four scripts on the simulator with XEngine, but I've seen a systemwide increase of 7 GB.

Next I started a second run where I started all four scripts on both engines and monitored each simulator separately. After 6 hours it summed up to an identical increase of roughly 2.5 GB on each simulator.

I tested on Ubuntu 18.04 with Mono with libgdiplus 6.0.4.

P.S. Currently there is an open pull request related to resource leaks on [^] Not sure this will resolve the issue in the furture.
2019-11-22 02:49   
It looks ok after testing 14 hours on Ubuntu 18.04 running Mono with libgdiplus 4.2-2. The problem definitely seems to be in libgdiplus.
2019-11-22 05:23   
Confirming this for now, though whether this warrants changes or just some time to wait for updates on libgdiplus is in the stars
2019-11-28 05:39   
Apparently there were some updates to libgdiplus recently that may help resolve this issue, however no new release has been made yet so these changes only apply if built from their master. Since it then also depends on mono to update to that latest version, seeing as distros are unlikely to do so, it may be even longer until an update resolves this.

I propose we resolve this temporarily by shipping our own libgdiplus along with either bin or libomv and only load a different version if the version on the system is newer than our own, that way we can either ship an older working version or the latest from their master to hopefully solve this before every other simulator starts choking on textures.

Else I feel the only way is a big red warning on the wiki regarding the install of mono requiring the use of older versions of libgdiplus :/

View Issue Details
7868 [opensim] [GRID] Hypergrid major always 2016-04-01 08:36 2020-01-04 13:49
Kayaker Magic linux/mono  
OpenSim dev OSgrid  
resolved master (dev code)  
won't fix  
Grid (1 Region per Sim)
"My Suitcase" folder missing in OSgrid. (unavailabe) objects are available
When I log into OpenSim with my Osgrid avatar, I do not have a “My Suitcase” folder. If I hypergid jump to another grid, like Kitely running OpenSim, everything in all my folders is marked (unavailable). HOWEVER, I am still allowed to rez or wear any of these unavailable objects!
While there in another grid, if anyone gives me an object, it lands in my (unavailable) Objects folder, it is marked (unavailable) but it is actually available. The same thing happens if I am given objects by a script, such as a vending machine.
Login to OSGrid.
Hypergrid jump to another grid.
Note that you do not have a My Suitcase folder
Rez some object marked (unavailable) from your inventory. You will be able to, even though it should not be allowed.
Wear some object marked (unavailable) from your inventory. You will be able to, even though it should not be allowed.
Have someone give you an object, buy an object from a vending machine, take a copy of a copyable object. Note that they arrive marked as (unavailable) in your (unavailable) Objects folder. They are supposed to arrive available in your "My Suitcase" folder.
Mandarinka Tasty   
2016-04-02 09:02   
hello. Personally i consider that it is not absolutely bug=issue in refer to OSGrid.

There are many grids, like Kitely mentioned by You, including mine as well,

where HGInventoryService is based on HG 2.0 protocol, then

InventoryServiceInConnector is based on LocalServiceModule = "OpenSim.Services.HypergridService.dll:HGSuitcaseInventoryService"

but there are also grids, that work on other versions of HG, like osgrid works.

And all of them have absolute rights to use it too.

I only remind those other ones:

HG1.5, more permissive based on:LocalServiceModule = "OpenSim.Services.HypergridService.dll:HGInventoryService"

and HG1.0 based on LocalServiceModule = "OpenSim.Services.InventoryService.dll:XInventoryService"

It is nothing wrong that osgrid does not use My Suitcase folder in their robust configuration.

In my grid i use HG 2.0 and each of my residents uses My suitcase folder when hypergriding.

But when resiednt arrives to osgrid, then inventory of him/her can't show My suitase fodler since osgrid works in different way. and that's why items are available for wearing or rezzing etc.

So I can't see any issue with it for osgrid, that is by design in their config, but that is my individual opinion.
Kayaker Magic   
2016-04-04 22:20   
There is a mode you can select that displays all of your inventory as (unavailable) when it is actually available? And you can choose to use that mode? And you would do so on purpose? Seems to me if that is a useful mode it should not display (unavailable) for available objects.
I was told that the Suitcase mode was an important security feature, it protects your inventory from becoming available to the servers of the regions that you pass through when hypergridding. Why would OSgrid use a less secure inventory system? Was this done on purpose or by accident?
Mandarinka Tasty   
2016-04-05 03:16   
(edited on: 2016-04-05 03:37)
Hello Kayaker.

The protocol that My Suitcase folder is based on, can be set in the grid only by admins. So i can choose and set it only in grids that i administrate and to be exact and precise that does not mean administration in-world, but such external administration = access to editing RobustHG.ini file. Only there, appropriate person can apply such settings for entire grid.

In my grids, i have deliberately chosen this more secured protocol: HG.2.0,
in this way i have enabled, in my grids, functionality of My suitcase folder.

That indeed gives more security for resident being in hypergrid travel.

But once again, that is optional setting ! No one should force administrators

of other grid like OSGrid, to change their settings referrign existing or not existing functionality of My Suitcase folder in their configuration.

The entire Metaverse, whole OpenSim where OSGrid is just one part of it, gives everyone = who manages administration of grid free choice to set whatever administrator wants to set etc.

That is not Second Life, never forget it.

So OSGrid administrators have decided to use such protocol for HGInventoryService, where My Suitcase folder works in different way.

When You create account in OSGrid, you notice at once, that your inventory has not such folder at all.

Because OpenSim gives us freedom of choice, all settings are always made on purpose, aware purpose, nothing wrong with it.

As resident you also have choice what grid you want to visit. durign hypergrid travels.

Kitely or any other grids , also mine, cant force OSGrid and are not allowed to force any grid to apply the same settings in their confgurations.

So everyone with appropriate knowledge can create grid and choose any settings he.she wants to use. That is always approvable.

In my opinion such advanced with big experience admin team of OSGrid has chosen
HGInventoryService on a very aware purpose, not by accident.

There is also certain variable called: RestrictInventoryAccessAbroad.

The purpose is: Send visual reminder to local users that their inventories are unavailable while they are hg_traveling and available when they return. True by default.

In my grids, it has always value TRUE, I set it in GridCommon.ini file of each my instance, where region is running. but this variable has meaning only whe appropriate hg protocol referrign to HGInventoryService has been set.

For example in OSGrid, this file: GridCommon.ini does not contain such variable at all. In my opinion, it is by design, because OSGrid does not use My Suitcase folder at all, so for what to show availabilty or unavailability of inventories in hg_travels.

Anyway, this variable does not decide if My Suitcase folder is active or not.
That is just info. The most important for functionality of My Suitcase folder is choosing and setting ( in RobustHG.ini ) appropriate HgInventoryService,
but that has been described by me above.

That is my opinion. Regards !

Mandarinka Tasty   
2016-04-05 03:48   
Even my friend, you have written following steps to reproduce:

Login to OSGrid. Note that you do not have a My Suitcase folder.

and now it should end history, lack of My Suitcase folder in yoru osgrid avatar's inventory also tells us, you that your entire inventory will be available during yoru hg travels with this avatar to another grids.

When You arrive to grid ( like Kitely, or mines ) where RestrictInventoryAccessAbroad = True, then indeed you can see in your inventory folers' names, word ( Unavailable), but that is not important for yoru osgrid avatar=account because your osgrid avatar has not My Suitcase folder at all.

If your avatar would have such folder in your inventory, then information about unavailability of your inventory folders, would tell you: use My suitcase folder now. But because your osgrid account does not have this My Suitcase folder, then you can feel free to use your entire inventory during hg travels.

Ferd Frederix   
2020-01-04 13:39   
This is a viewer issue, and not an Opensim issue.

I am closing this old Mantis as Opensim and OsGrid may have no suitcase, by design. The viewer still shows Inventory Not Available when travelling from there, though it is available. But that is a viewer issue.

If Suitcase()
    LocalServiceModule= OpenSim.Services.HypergridService.dll:HGSuitcaseInventoryService

   LocalServiceModule= OpenSim.Services.HypergridService.dll:HGInventoryService

View Issue Details
8516 [opensim] [REGION] OpenSim Core major sometimes 2019-04-09 03:31 2020-01-02 04:07
aiaustin PC  
UbitUmarov Windows  
normal 10  
assigned master (dev code)  
  master (dev code)  
Grid (Multiple Regions per Sim)
.NET / Windows64
dev master (2019-04-09)
Missing Objects and/or Terrain Parts on Teleport between Grids
This is a Mantis issue to act as a place to note observations as the recent code changes related to SupportViewerObjectsCache are tried out more.

With recent dev master code on teleport there can be loss of objects and/or terrain chunks. They cannot be made visible by clicking in the area where the lost objects or terrain is known to be (which can occur already with some objects in viewers). So we are not able to get them back without moving away and back or relogging.

Sending a "force update" from the Server console also has no effect.

The recent commits suggest turning down the viewer bandwidth if this sort of loss occurs. I turned the viewer bandwidth down to 750KBps and that did seem to improve things a lot... but I still do see some items go AWOL occasionally even at 750Kbps. I have yet to identify the specifics of such a situation as its not all the time now.

I have also seen a couple of viewer crashes on teleport even at 750KBps bandwidth but again cannot be specific yet.

I do note a blip in packet loss in the stats tool (ctrl+shift+1) when the issues arises... Packet loss is on zero but as the loss occurs there is a sudden spoke a few seconds after arriving on a region where object/terrain loss can be observed.
Teleport back and forth between grids running latest dev master code and observe if any objects or terrain patches are missing. Try viewer bandwidths such as 1500KBps (default for Firestorm on my setup) and 750KBps.
UbitUmarov and myself have discussed this quite a bit and done some cross grid hypergrid testing with a range of viewer bandwidths rather than my usual (the default I think) 1500Kbps I use on Firestorm (on a 100Mbps link at home and gigabit networking at work).

This occurred with both with SupportViewerObjectsCache set to false and true (true now being the default in master code). Ubit indicated the mechanism changed even if the parameter was set to false.

Ubit indicates that we should be resilient to reasonable packet loss. I have seen moderate packet loss on Second Life and on earlier OSGrid releases without any problems of such object loss. But here the visual loss of objects does seem to be associated with an observation in the stats console of a sudden spoke in packet loss as it occurs.
2019-04-09-Terrain-Loss-1.jpg (89,528) 2019-04-09 08:10
2019-04-09-Prim-Loss-1.jpg (182,032) 2019-04-09 08:22
2019-04-09 08:07   
The way the stats for ping loss show it is as if the cause of the packet loss is occurring just after the arrival of the avatar at the destination region. Not that packet loss that just happens to occur causes the loss if the objects or terrain.

Packet loss can be registering zero, and seems to stay at zero whenever a successful TP takes place and no object or terrain is lost. But I think it is the case that each time I see packet loss if I look round I find there are missing prims or missing chunks of the terrain that are around 16m X 16m.
2019-04-09 08:21   
(edited on: 2019-04-09 08:23)
Now I am observing something I find weird... note I am TPing between AILand grid Ailand region (avatar logged in natively there) and Openvue grid Openvue region (across Hypergrid). These are the two main regions on each grid. I am on latest dev master on each (2019-04-09 12:05). I am going slow on TP rate, leaving 20 seconds between TPs.

Once I get the prims missing (in this case three ground level 10x10 prims in the cobblestone area on Openvue as shown in attached image 2019-04-09-Prim-Loss-1.jpg), I can TP back home and return to Openvue and the SAME prims are missing. I can even relog, do the same and they can be missing.

BUT, and this is the odd thing... but might hold a clue to where the prims are getting lost... if when on the foreign grid Openvue region I TP via the map to an adjacent region (Sandbox) and the n return via the map to Openvue all on the same grid, the prims show.

BUT, then I go home to AiLand and TP back to Openvue again (all leaving 20 seconds between jumps) and the SAME prims have gone again. Its as if a totally different mechanism is being used to refresh the contents for inter-grid to inter-region jumps. I told you it was weird.

2019-04-09 08:45   
been there via HG with 1500kbps fs and had no issues
2019-04-09 08:47   
(edited on: 2019-04-09 08:53)
Good :-) I am watching the logs as you hop about Ubit.

All looks normal. This showed once...

16:53:03 - [LLUDPSERVER]: Received a resend of already processed packet 0000047, type RegionHandshakeReply from Ubit.Umarov

2019-04-09 22:03   
I see this issue still on master with grid set up as not HG. Have to constantly issue 'force update' command in the console to get the missing pieces to show.
2019-04-10 02:04   
(edited on: 2019-04-10 02:13)
I updated to (2019-04-09 23:27) for both grids and observe essentially the same issues. At 750Kbps it works most of the time, but at 1500Kbps it fails most of the time. And after I have prims and terrain missing even if I wait 20 seconds between a TP out and back the same bits are still missing.

As before a small packet loss just once was associated with the first appearance of the missing prims/terrain chunks and after that it sticks even with nno further reported pin loss. It looks like once lost its.

BUT.. and I still find this peculiar and perhaps a hint as to what might be happening... a TP to an adjacent region (Sandbox) on the second grid and back to the region on that grid with missing prims/terrain (Openvue) makes everything show fine, but TP back to home grid (AiLand) and back to Openvue and the same bits are missing again.

I have double checked, and "force update" has no effect on the missing prims or terrain chunks for me on Openvue/AiLand grid testing. I think MeMewToo0641 may have a separate issue as in all my testing I have never been able to make any prim or terrain chunk that goes missing reappear.

2019-04-10 02:16   
(edited on: 2019-04-10 02:19)
Ohoh… now the missing chunks and prims are persisting across relogs. I logged out and back in and after all settled did a jump to Openvue grid and the same bits are missing there.

In two separate relogs, I logged in to AiLand and let everything settle down. then I did my first jump to Openvue grid.. and the parts missing on previous logins were still missing. Same parts.

2019-04-10 09:09   
(edited on: 2019-04-10 09:10)
I still have the same prims missing on FIRST teleport from AiLand grid to Openvue grid after updating from yesterday's git master (966 - 2019-04-09 23:27) to today's (967 - 2019-04-10 13:01) and hence restarting the servers.

Is this possible? I thought the object cache got refreshed after server restart?

2019-04-10 09:19   
(edited on: 2019-04-11 09:41)
no direct relation to objects cache.
as I told several times, viewer just does not rez things it did received.
most likely because it did overload, leaving things in memory in broken state.
the effect ranges from totally missing, just invisible that show up on touch and even just a face or two visible.
What prims, depends just on order they did arrive to viewer and how the issue was triggered.

similar for terrain.

viewer bandwidth is not only about network, is also about viewer capability to process things.

2019-04-10 10:03   
If it is in memory Ubit, why does it persist over relogs/viewer restarts, and even after server clean upgrades and restarts?

Also, how come the objects show when moving off to an adjacent region and back on the destination grid, yet the same missing parts are still missing after return to home grid and back. Is there a different mechanism for updates in these two cases?

Clearly something serious has gone wrong.. we have not seen issues like this before have we? Its a very different issue to the occasional non-rez of objects that show when the area they are in is clicked on.
2019-04-10 10:19   
@aiaustin, the same could be said, for WHY am I and others on my grid, on osgrid, and on 2 test grids unable to replicate your issue ..

Stomping your foot and saying it's broken does not help the issue.

I can give you 4 cases where it is not broken.

Not trying to say it is not an issue somewhere but two people having an issue does not point to a systemic issue.
2019-04-10 11:03   
Bill.. I am not “stomping my foot”. I am reporting a clear change in behaviour on my test grids. I am delighted that you don’t see any issue on your specific test environments. This Mantis Issue is here to collect information as and when or if anyone else starts to see the issues, so we can pin down the problem.
2019-04-13 01:00   
(edited on: 2019-04-13 01:01)
Updated Openvue and AiLand grids to (2019-04-11 23:19) and set SupportViewerObjectsCache = false explicitly in OpenSim.ini (default now being true from openSimDefaults.ini).

Testing over the last 2 days in two viewer environments one of which is on a fast link on the same subnet as the servers and the other is over a home ISP accessing the servers remotely. using Firestorm (Windows 10 Pro), default bandwidth of 1500Kbps.

I do not see any missing prims or terrain chunks on teleports between these grids with SupportViewerObjectsCache = false. I even tested TPs back and forth 5 or 6 times at under 5 seconds delay. All looks fine. No packet loss blip occurs when using the stats console.

I then restarted the two grids with SupportViewerObjectsCache = true on both and then see a few missing prims when doing TPs. The prims this time differed a little on each TP, but most were apparently sub-parts of a linked object.

I did these tests after seeing the commit (2019-04-10 20:28) which may have fixed the problem with the issue occurring even when SupportViewerObjectsCache = false as reported earlier.

2019-04-13 06:25   
Just for information purposes, FS default bandwidth is 500Kbps not 1500.
2019-04-13 09:57   
(edited on: 2019-04-13 10:08)
Ah, that’s good to know Bill. I was just concerned to make sure we work well with defaults, as many users will never change such settings. I guess I set mine to “cable” speed a long time ago and did not realise that continued to be set.

2019-06-05 11:19   
This issue now seems to be fixed.

Openvue and AiLand grids now use SupportViewerObjectsCache = true (the default as set in openSimDefaults.ini).

Issue is addressed on latest dev master - sometime between 24th March 2019 and 14th May 2019. So OSgrid version as of 14th May 2019 is good too.
2019-06-11 01:55   
(edited on: 2019-06-11 02:00)
As at OSGrid 2019-05-14 I do see missing prims at initial login. Not TP or HG related. Simple cubes missing. Different ones in same linkset for example none after several logins. As before, right clicking or trying to operate on the affected object does not make the missing piece rez. A relog is needed.

2019-06-11 22:31   
(edited on: 2019-06-12 00:32)
let me remark that viewer capability to handle prims may depend on fps
try to keep the viewer maximized and selected during all login/tps

2019-07-31 01:45   
Still see this issue on master and have had reports of it from people who use the grid. Setting SupportViewerObjectsCache = false doesn't seem to make a difference. I have suggested to the people reporting it to me to try the old zoom out and ESC zoom in trick; sometimes that works and sometimes it doesn't. Toggling Render > Volume in the Advanced menu (CTRL + ALT + SHIFT + 9) off and then back on again sometimes helps too, but typically I have to resort to sending the 'force update' command in the OpenSim console when they tell me that nothing is working on their end to fix it.
2019-08-20 06:46   
We're also seeing this issue on fairly current master. Turning bandwidth down does appear to help but not eliminate the problem. It affects both mesh and regular prims.

I understand that people feel this might be a viewer capacity issue. However the issue DOESN'T happen on SL so I'm not convinced "bandwidth" is the fix. My viewer is rendering 100fps and with network lowered to 750 I still get dropouts sometime. Originally I thought kills were being sent but the prims are "there" (a physics shape often exists) but they aren't rendering.
2019-08-23 06:48   
Interesting to note. If I enable the GetAssets cap handler this problem seems to essentially go away. Of course that means less data being shoved over UDP so that makes some sense. The ViewerAssets cap has been in place in the viewers for some time and UDP asset fetching is totally off in SL so its very possible the viewers don't expect to get this data over UDP and because of that stuff breaks.
2019-08-23 12:06   
Thanks for the information.
Meshes and Textures should already be out of udp, and those should be the bulk of assets data at arrival.
Never the less i did add the ViewerAssets cap, not only because it makes sense to send all assets via tcp(http) but also to prevent potencial future issues in viewers side code merging.
But it the problem is related to bandwidth. If got worse after a few changes i made improving lludp i had to reduce the effciency of udp packet usage (not using all MTU bytes) to mitigate it
Now im using a suicidal 3000Kbps (not recomended) and see no problems either on my test grid or osgrid. (in fact most regions i visit are on master with that cap active)
2019-08-23 12:10   
(edited on: 2019-08-24 04:08)
It may happen it is the extra latency of http that gives viewers a little more breathing time..

2019-08-23 13:21   
(edited on: 2019-08-23 13:25)
On the assumption that users are directed to use Firestorm 6.0.2 can I check what we should set then? Do we just uncomment this OpenSimDefaults.ini line ...

    ; Cap_GetAsset = "localhost" DO not ucoment this line. Some popular viewers still dont do it right for opensim. Here to easy testing

Is the capability you mention for ViewerAssets just in your test code at present Ubit and not in dev master?

2019-08-24 02:17   
Yes think fs 6.0.2 has it broken
It only asks it on first region, then keeps using the same url
that of course may fail.
2019-08-24 04:08   
(edited on: 2019-08-24 08:10)
Oh, that is quite serious. Does "localhost" map to whichever server the OpenSim.exe region(s) are running on, or does it resolve to ONE specific server on first use and then stick to that?

If its the latter, then that means it should really not be used except for grids that use a single server for everything.

I see it is indeed reported in the Firestorm JIRA and was corrected by Beq Janus back on 28 Feb 2019 in the Firestorm code... the problem being of course that this is after the current Firestorm 6.0.2 release for OpenSim. [^]

2019-08-24 08:06   
Is the OpenSim server side Cap_GetAsset capability the very same as the “ViewerAssets” capability or are they different?
2019-08-24 13:36   
It is the same
Total Sorbet   
2019-08-24 13:43   
(edited on: 2019-08-24 13:52)
On login to OSG i have 25% of prims missing.. If i then jump to an alternate region viewer will show nearly all prims (100% on a good day :p) I have tried various bandwidth settings and although i would say this definitely has an effect im unable to find a setting that fixes this.

My default login procedure recently is to login to somewhere i don't want to be then jump to somewhere I do! That way I get to see most prims :)

2019-08-24 15:04   
Total forgot to mention she uses Linux Firestorm
2019-08-24 15:58   
(edited on: 2019-08-24 16:04)
Think i still had a silly bug on object cache support
Can you pls test master?
Clear viewer cache!!
Issues related to that bug should happen on second relog after that (or returning to a region already in viewer cache)

2019-08-24 16:37   
About the ViewerAsset fs problem. That is still not that relevant, old LLUDP( and http getTexture nd getMesh*) methods are still there, and used by most viewers, some not having that cap.

i did add it, because it does make sense to use http on those, and since reference viewers code had lludp methods removed, less viewers code merging issues to worry about.
2019-08-24 17:34   
Had a quick chat with Beq who confirmed there was a bug fixed around ViewerAssets and the behaviour (cap not getting refreshed on a transfer) in FS. It's in 6.2 but not yet released for OpenSim.
2019-08-25 09:56   
I updated Openvue and AiLand grids to latest dev master, cleared my viewer(s) cache(s) and will now watch for any issue,
2019-08-27 03:53   
(edited on: 2019-08-27 03:57)
Just to report back... As well as Openvue and AiLand grids, I updated my OSGrid addon regions to the latest dev master also for testing. To date after the update to the latest dev master at 2019-08-25 and revisiting already visited (cached) regions, moving between the three grids, and relogs I have not yet seen any missing prims or mesh (or indeed terrain holes). I will continue to monitor carefully and report if I do see anything after this update.

It might be useful to encourage the OSGrid folks to update their distribution for add on regions so we better test this. I know people can compile the latest dev master and add the bin folder from that over the OSGrid version to update (as I have done), but possibly not many will do that.

2019-08-27 10:53   
Yes, code is just in "burnin" on some plazas before Dan makes a release
Thanks again for your testing and feedback
Total Sorbet   
2019-08-28 08:38   
I updated and happy to report no missing prims past 2 days :)
2019-08-31 05:04   
Just a quick update. I've rolled out to a few troublesome regions a build based on master with the suggested changes. I can report that for the updated regions this issue seems mostly addressed. I did have an issue with one region with a large mesh build (linkset) and a number of adjacent regions. When camming well back from the object when I zoomed back to my current position the building I was standing on was invisible. Edit, touching, etc, didn't bring it back. I don't think this was a case of the server sending a kill because the object was still physically there. Maybe something with interest lists. But the phenomenon was the same as the missing prims before this fix which I thought was interesting.
2019-08-31 06:37   
Server side culling does not suport camera position, only avatar position.
SO it may cause what you report.
maybe you have it active? (don't remember def as i type)

camera position support would be insane heavy...
2019-09-01 05:43   
ObjectsCullingByDistance is false in the code and no default is set in the config or defaults files. But yes its acting that way. It's especially prevalent with Mesh and in some cases you get the invisible polygon that happens when a shape isn't loaded. In those cases edit with cause it to pop in. In others it's just gone. and there's no shape there to edit. So yeah these might be viewer generated kills because something is outside DD. I'll do some more experimenting. Overall better but performance is slow and this camera issue is a real hit for perceived reliability.
2019-09-01 06:58   
Maybe that mesh just has bad LODs?
2019-09-02 18:52   
Have been testing master for past week; the issue seems to be much improved although I still see it on occasion and have to issue the 'force update' command to fix it. I am still testing with SupportViewerObjectsCache = false though. Should I be testing with it set to true, or does it matter?
2019-09-03 02:29   
(edited on: 2019-09-03 02:30)
As others have said, I think we are seeing a range of issues when objects don't show.

For the original problem reported in this mantis "force update" had no effect, and there were no outline (physics style wireframes), or ability to touch any area and make the object, prim, terrain piece or mesh appear. I have not see that problem since Ubit made the latest changes. Running with 1500kbps and SupportViewerObjectsCache = true.

2019-09-07 18:32   
(edited on: 2019-09-07 18:32)
@aiaustin - That is possible, I have been seeing a high number of log messages that look like this: "[LLUDPSERVER]: Received a resend of already processed packet (Number), type (Type) from (Avatar Name)" upon login of an account. The types vary from General, RegionHandleRequest, GenericMessage, AgentHeightWidth, AgentUpdate, AgentAnimation, EconomyDataRequest, and probably more. I've always seen these messages from time to time but they have never been this frequent or numerous as they have been in the past couple weeks of testing master and the high frequency of them seems to coincide with seeing missing objects upon login or it could just be anecdotal. It may also be entirely unrelated to this issue and/or the issue I described in my previous post. I am just unsure at this point in time.

2019-12-03 10:33   
I notice the same difficulty in getting prim or terrain to show up completely.

Testing 091 official release 091 in gimisaOS grid under linux ubuntu 16.04 with mono version .

I use viewer singularity alpha issue 6994 dating 2018-04-9 . I have been using this viewer since release. I also tried cool viewer, 1.26.4 this week release reading above that the issue was possibly with firestorm.

It is interesting to note that I have one computer that I could not update cause too old. That computer runs ubuntu 12.04 with mono version 3.2.8 and gimisa3 region simulator version 0901 official release. The rendering there is without issue.

Let me know if I can provide more data that could be usefull to solve that issue.
Ferd Frederix   
2019-12-03 11:06   
What advice is there for this now, under 0.9.1 or dev master?
I still have run at 500 mb to see things reliably in Firestorm viewer, and even then there are times it does not show half the land and a lot of mesh is missing. TP away and come back and there will be more. 0% packet loss at any speed.

I currently have set the following in Opensim.exe.config:

 <useLegacyJit enabled="1" />

And in Opensim.ini have

Any advice? There are over 2000 Windows grids that use these same settings, so I would appreciate any advice on this before my next release.
2019-12-03 11:08   
<useLegacyJit enabled="1" /> should no longer be necessary

sure you meant 500kbps :p
2019-12-03 11:18   
(edited on: 2019-12-03 14:20)
Ferd... if you still have these lines in... remove <useLegacyJit enabled="1" /> in files OpenSim.exe.config, OpenSim32.exe.config and Robust.exe.config in section RunTime in each. They are no longer needed in or the latest dev master.

The extra line was added into those config files temporarily, and if anyone left those in they should now be removed.

2019-12-03 12:45   
in opensim 091 useLegacyJit is not present in any of the above three files. OpenSim.exe.config, OpenSim32.exe.config and Robust.exe.config

In Opensim 091 release the the default setting presented in configuration file OpenSimDefaults.ini is the following :

    ; Support viewers object cache, default true
    ; users may need to reduce viewer bandwitdh if some prims or terrain parts fail to rez.
    ; change to false if you need to use old viewers that do not support this feature
    ; SupportViewerObjectsCache = trueSupportViewerObjectsCache = true in line

The setting above did not exist in 0901 OpenSimDefaults.ini which is probably an effort to cure the situation withness with prim lost .

Again as state by others changing bandwitdh of viewer does not seem to cure the situation I withness.
2019-12-03 12:47   
Support of Viewer Objects Cache is new on 0.9.1
Viewers had it for years, and we made no usage of it
2019-12-03 23:04 [^] Logging in directly to the region, cached from previous login [^] After 2 minutes of being unable to move around [^] After 2 minutes after objects began to load, can move now

I sent this to Ubit already, think it is related to this maybe.

I have been getting mails about this for some time now, in total 6 different grids including two of my own. Stuff not rezzing, taking a long time after login for world to load etc. Just my two cents, is problem pls fix :)
2019-12-04 04:38   
(edited on: 2019-12-04 04:43)
seem to work supportViewerObjectsCache = true for me.

Please note that Even if OpenSimDefaults.ini is the following :

    ; Support viewers object cache, default true
    ; users may need to reduce viewer bandwitdh if some prims or terrain parts fail to rez.
    ; change to false if you need to use old viewers that do not support this feature
    ; SupportViewerObjectsCache = true

Which would normaly provide for ClientStack.LindenUDP option SupportViewerObjectsCache = true but a config show request at consol level report nothing for ClientStack.LindenUDP,
One have to add it to gridCommun.ini or to opensim.ini as follow:


Region (root) # config show ClientStack.LindenUDP command in console does now report the setting proposed as follow :

  SupportViewerObjectsCache = True

and that WORK for me hope it helped you too.

2019-12-04 04:54   
config show only lists uncomented entries on ini files, not the full simulator settings/options.

The region code does define default values for all settings. no point on overloadind ini files( worse internal in memory structures created from them) setting the same again, as that command seemed to had assumed.
2019-12-04 12:02   
(edited on: 2019-12-04 12:03)
Thanks for the clarification Ubit. As I see now the problem reappearing in same region with this setting on.

So that confirm your statement contrary to what I have said earlier in my enthusiasm about the setting change. I falsely reported that the problem was corrected for me where now I observe it again . In all probability the only thing that had help me seeing all the prims was likely cause I relog in the same region a second time around even with clear cache.

I appreciate your attention to this issue of 091 release.

2019-12-04 12:08   
I can't repo this issue. Been at tampa region.. no issues even with suicidal 3000kbps viewer bandwidth and 1024m view range, Either first time there, or returning
2019-12-05 03:27   
(edited on: 2019-12-05 03:30)
Testing with cool and singularity viewers. Setting bandwidth to 500kbps and viewer reach to 128. Clear cache and logging in gimisa4 of for three consecutive trials. Stats show 45ms ping time and no pocket lost. Result is all object appears properly after a loading time of about 3 minutes.

Repeating above procedure with maximum bandwidth (10,000 kbps ) three times .I got no pocket lost and same ping time as above. I got success of both viewer on first trial. Success of singularity on second and third trial with loading time of all objects within 1 minute. and failure to load all objects with cool viewer for the two other trials within 3 minutes of waiting time.

Firestorm is recommending 500kbps when using a wireless connextion ( my case ) . Ref: [^]

Thank you ubit for you help and attention .

2019-12-05 05:40   
Thx for you testing
2019-12-06 15:49   
(edited on: 2019-12-07 10:10)
All of this has happened with a Firestorm Bandwith setting of 500 Kbps. (And Draw Distance of 600m)

Missing Terrain and objects (and AV Clothing grey) EVERY time I log in on 2x2 region

Except every time its different terrain , objects. But every time I login without previously deleting cache there inevitably is missing terrain.

Only fixed by deleting cache every time I'm on. ( then no terrain is missing next time I log in)

Only started after implementing OS 9.1.1

TPing to another region and back and the terrain and objects were restored.
I thot I had done that before and terrain had been still missing.
So I tried logging out and in 3 times ( without deleting cache) and TPing to another region and back – the terrain gets restored.

But all this time some clothing on my AV is grey ( and invariably remains grey ) but this ALWAYS gets fixed by deleting cache.

Firestorm 6.0.2 (56680) F (64bit)
 Welcome located at ( SLURL: hop:// [^] (global coordinates 256,132.0, 256,160.0, 34.9)
 OpenSim Yeti Dev (Win/.NET) Release Notes CPU: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz (2660.01 MHz)
Memory: 8175 MB OS
Version: Microsoft Windows 7 SP1 64-bit (Build 7601)
Graphics Card Vendor: ATI Technologies Inc. Graphics Card: AMD Mobility Radeon HD 5800 Series
Windows Graphics Driver Version: 15.301.1901.0
OpenGL Version: 4.2.13417 Compatibility Profile Context 15.301.1901.0
libcurl Version: libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.8 nghttp2/1.25.0 J2C Decoder Version: KDU v7.10.6
 Firestorm Viewer Skin: Firestorm (Grey)
Window size: 1920x1181 px
 Draw distance: 600 m
Bandwidth: 500 kbit/s
LOD factor: 2
Render quality: High-Ultra (6/7)
Advanced Lighting Model: Yes
Texture memory: 192 MB (1) VFS (cache) creation time (UTC): 2019-12-5T17:2:50 Built with MSVC version 1800
Packets Lost: 16/58,690 (0.0%) December 05 2019 17:40:41 SLT
Reported In:Firestorm Animesh Release

2019-12-06 18:27   
I went to Alen location use cut past in local chat of your viewer and clic the following link. secondlife:///app/teleport/|8002|Welcome/132/160/35 [^] .

No previous clear cache 500kbps 128m reach distance, my ping was 115ms , no pocket lost reported. I waited 5 minutes to make sure everything was downloaded . I witness that terrain portion is missing and obvious terrain texture is not appearing.

Please see [^] for representation of my viewer screen.

I suggest other to report their scene rendering problem here so Ubit can see a pattern that he can reproduce.

Hope it help
2019-12-07 04:42   
(edited on: 2019-12-07 04:47)
New test and a good news ( so far ) . I wanted to have a consistent repeatable failure test for Ubit. Also need a mean to measure the result. So I set my singularity viewer to 5000kpbs and 128m range. To measure the result I use the stat window advance display with a paid attention to the object count number. That number is increasing as long as the new object count per second is more then 0 .

The following link give you the result of 4 consecutive trials with clear cache between each. The result is that missing prim would happen 2 times out of the 4 trials. [^] Object count stabilise at 19978 when new object count is 0 and fail to meet that value when prim are missing.

Now the good news. I went to osgrid and talk to ppl that told me they dont have that issue , either they using the previous release of osgrid bin or the newest one. The previous one OpenSim Snail Dev OSgrid 695d807696: 2019-01-26 and the new one is [^] .

So I installed the newest release put my own grid ini settings in and run the simulator for gimisa4 again. This time 4 trials 4 success...No missing prim on land. Total object count result is a bit higher at 19995 when new object count stabilize to 0 at every of the 4 trials without object missing. So this proves (so far ) that bin of official snail release as an issue which next Yeti version seem to address.

I will leave gimisa4 region with this installation if you like to visit cut past and clic in local chat secondlife:///app/teleport/|9000|gimisa4 [^]

Hope it helps.

2019-12-07 11:02   
Thanks gimisa --

All of the following was done with Draw distance: 600 m and without clearing cache:-

Here's another ( better?) workaround ( for me):-
Setting Bandwidth to 400 kbit/s , positioning my AV at two different corners of the 2x2 and logging in and out 5 times -- there was NEVER any loss of terrain and my AV was never grey !!!
I then changed it back to 500 and logged in and out twice -- both times there was loss of terrain .
And then back again to 400 with 2 logins -- no loss of terrain.
And I don't need to clear cache to stop my AV from being grey.

Other tests:-
I logged in and out 6 times at Bandwidth: 1500 kbit/s ( instead of 500) and only half the time there was a loss of land.
I put it back to 500 and changed DRAW DISTANCE to 200 ( instead of 600) positioned my self at 2 different corners of the 2x2 and logged in 4 times -- every time there was loss of terrain.
Each of these losses still gets fixed by TPing to another region and back ( but it never fixes my grey AV - only clearing cache does that).
Changing DRAW DISTANCE to 800 made no difference.
2019-12-08 08:54   
(edited on: 2019-12-08 12:55)
But then I logged in today ( the next day) and there was loss of terrain.
 So I set it at 300 and the 2nd time I logged in there was loss of terrain.
Its now at 200 and after 3 logins -- no loss.
See how it is tomorrow :(

( What's the drawback side-effect of 200 ? )

2019-12-08 08:58   
been there a few times, even with 3000kbps no issues :(
2019-12-08 09:01   
you are getting in region by direct login or tp from other?
2019-12-08 12:56   
(edited on: 2019-12-08 15:33)
Direct login
( TP to another region and back always fixes it -- but not my grey AV)
All of my testing has been on the 2x2 region "Winter" not the 1x1 "Welcome" ( as my visitor detector tells me )

I noticed the omission that my server has an SSD -- no HD -- super fast

2019-12-08 20:13   
Well sorry to report that I witness missing prim in gimisa4 with 0911 release and 5000kbps. Turning it back to 500kbps and re loging in same region still missing item with 0911 from osgrid. All prim show on tp from an other region not adjacent to gimisa4.
2019-12-09 03:03   
issues are to be expected with highband width, viewers just can't handle it, that is why i mentioned "even with 3000kbps"
2019-12-09 07:31   
(edited on: 2019-12-09 07:48)
gimisa and Alan... assuming you are using latest dev master (or the OSGrid latest update which is also latest dev master code), can you try a viewer based on latest LL code base 6.3.4 to see if that has any effect?

Unfortunately Firestorm for OpenSim is not yet updated and is still at version 6.0.2. There are experimental builds but they are not yet openly released so it is best not to try those for this test.

But most other TPVs are now updated to include LL 6.3.4 code... e.g.

1. Get the up to date Singularity installer (1.8.7 (7992) 24-Nov-2019) from the bottom at this page: [^]

2. or use Cool VL Viewer latest version 1.26.24 (2019-11-30) from the downloads link at the top of: [^]

2019-12-09 09:04   
(edited on: 2019-12-09 09:08)
Hi Sir I thank you for your attention. I running under ubuntu 18.04.3 up to date so I cannot use the pre compiled version offered for window. If you read my earlier post you will see that I am testing with singularity and cool viewer as follow:

    "I use viewer singularity alpha issue 6994 dating 2018-04-9 . I have been using this viewer since release. I also tried cool viewer, 1.26.4 this week release reading above that the issue was possibly with firestorm.
    It is interesting to note that I have one computer that I could not update cause too old. That computer runs ubuntu 12.04 with mono version 3.2.8 and gimisa3 region simulator version 0901 official release. The rendering there is without issue. "

Its hard to validate if test is conclusive without visiting the complete region attentively when only a few prim are missing. So I have use a test criteria with the help of the statistic window advance stat section total objs count . see [^] Looking for consistency in reported object count in my case 19990 objects in this regular region.

Aside from opensim offical release I have also tried with osgrid latest [^] [^] . I withnessed same failure after a time at 500kbps. Its hard to get consistent failure most of the time its good and once of a sudden it fails.

I am now testing Lanani latest. [^] She seem to have regressed her last release ( november ) in her december release to something that in her experience works well. With it so far I notice that at 500kbps bandwidth everything is fine . Crossing fingers ...

Hope the above report helps .
Thanks again for your and Ubit works to make this new release a success.

2019-12-09 09:06   
Installed Singularity Beta 1.8.7 . It (eventually) defaults to Max Bandwidth of 750. (I set Draw Distance to 608 and Graphics ULTRA)
At 750 there was terrain loss -- at 500 too -- at 200 no loss
(After first installing Singularity Max Bandith was at 2000 -- somehow it self adjusted to 750.)
First time I TP'd to another region and TPing back the Viewer crashed ( second & 3rd time after relogins - no crash)
Singularity has another setting TEXTURE BANDWIDTH which defaults to 3000 which I left alone.
PS I hate that I can't resize Camera Control and there's no Mouselook button !
2019-12-10 04:24   
Hi, you both run the viewers in linux or just Gimisa?
2019-12-10 05:11   
(edited on: 2019-12-10 11:50)
For me as stated its ubuntu 18.04.3 for Alan you have your reply above when he fist posted .

" Version: Microsoft Windows 7 SP1 64-bit (Build 7601) "

 So far Lanani build does not create the issue with me at 500kbps. She offers the source if you want to compare. Please note that in official release 0901 bandwidth setting was never an issue at least to me. As stated by Alan the default setting of singularity is 750kbps . Most user will not touch that and will simply consider that the actual region they are visiting is lagging and move on ....

Hope it helps .

2019-12-10 05:16   
(edited on: 2019-12-10 11:23)
We use new viewers features (many years old in them), like local object cache. That is different protocol, so different issues.
We do know that high bandwidth set always causes these issues,
Thing is why only some have problems now :(

2019-12-10 11:29   
(edited on: 2019-12-10 17:22)
I just lost some terrain at 200 ! This sucks ( so far no grey AV)

So I set it back to 500 and logged out and in to a different 2x2 region and there was lost terrain. So its not just happening in one Region (2x2).

2019-12-10 11:35   
and other regions? like osgrid lbsa, wright plaza etc ?
2019-12-11 03:52   
So your recommendation is use window 10 with new viewer and set bandwidth to 500kbps.

Can I suggest adding this in the release notes as minimum requirements for opensimulator version 091 .

Thanks for clarifying.
2019-12-11 05:20   
(edited on: 2019-12-11 06:35)
I recommended nothing.
Cannot make recomendations like that, without understandig the issue.

Some I can, at least to test
- run only one viewer at a time.
- keep it the selected application...

Run it with the default settings about region objects caching.

2019-12-11 06:32   
(edited on: 2019-12-11 06:33)
As Ubit said. I don't think he made such restrictive recommendation anywhere gimisa.

It remains to be seen what the issue is, but we all do appreciate it is happening. We did observe this a lot during development, and indeed I was the initial reporter on this issue back in April 2019. See attached images for typical visual glitches seen then. But those issues were addressed some time ago and even with excessive bandwidth settings in testing some of us are not now seeing the terrain and object loss at all.

Lets hope we can pin down the common aspects of the environment or context that cause this one day.

2019-12-11 06:43   
Since I turned off object cache I receive reports that previous issues, since the upgrade to master code, are resolved and objects rezz and behave properly. I know that's not exactly evidence, but you cannot help but wonder what's going on there. I have one last grid with defaults, they just reported in 2 more problems regarding objects and specifically mesh not showing...

I also find it sad that we seemingly lower the bandwidth each major version instead of aiming to use the new push in broadband connectivity to actually support +1500kbps. It feels like going backwards instead of forwards.
2019-12-11 07:53   
I agree lets hope we can pin down what context would reliably make it work. As you know oscc is being held this week-end with opensimulator release 091 . The question will be is what I see what you see?

I though to give a trial to OSCC keynote 2 which is available for visiting as we speak. Using the object count as criteria here is the three test results I did there.

Clear cache before each test. Used cool viewer. Set at 500kbps and reach of 128m. Teleport in same location, look in same direction. Result taken after object count stabilized. All three reference pictures look similar. Detail can be found in picture as follows:

Window 10 , object count 2813, [^]
ubuntu 18.04 , object count 3601, [^]
ubuntu 14.04 , object count 2354, [^]
2019-12-11 08:00   
(edited on: 2019-12-11 08:00)
The issues occurred previously with SupportViewerObjectsCache set to false and true as reported above. The default for this setting now is true. Ubit indicated the mechanism changed even if you have SupportViewerObjectsCache set to false.

Note I am running with Firestorm set to 1500bps. I appreciate our environments and the regions/grid we are trying all vary of course. One day I am sure we will pin this down! Yours optimistically.

2019-12-11 08:07   
(edited on: 2019-12-11 08:19)
gimisa… just a thought... check your Winver with the command "winver". It looks from the pasted info that you are reporting your Windows 10 version is a really old one...

1511 10586 November 10, 2015

There have been many fixes and .NET updates since then. I wonder if you have a test environment with the latest Windows updates?

1909 18363 November 12, 2019

2019-12-11 08:22   
(edited on: 2019-12-11 08:29)
The issue of mesh not showing until you click on it is a different problem. This issue is for terrain lumps missing or objects (prims and/or mesh) not showing and no amount of waiting or clicking where it should be shows the outline or makes it rez. Lets try to separate these issues to home in on the problem. Anyone reporting mesh not showing please ask them if it shows an outline or rezzes when they click where it should be. If so lets separate that issue out.

2019-12-11 09:24   
There were also changes to sending terrain patches based on viewer view distance setting, I actually planned to revert that commit after seeing nearby terrain tiles not loaded properly, but reproducing this is hard as the failures depend on the protocol itself, which is kinda meh.

Frankly something seems botched with viewerobjectcache and those view distance changes and I think the best test-case really is reverting those and trying one-for-one to see if the problems can be reproduced, I don't see another way.
2019-12-11 10:54   
Hi all,
I am reviewing [^]
It would seem that at present there is no clear suggestion that this is viewer related, especially if this is new behaviour. I am going to leave the issue open, as this discussion is clearly ongoing, but for now, I'll put it in the "probably not viewer" pile.
2019-12-11 13:40   
(edited on: 2019-12-12 01:50)
winver: [^]

So far I only validate if I see or not see the object. I did not click on it to validate if the mesh is there.

But I know what you mean. I have seen that happen before when you try to rez new imported mesh . You see a frame of it when you click on where it should be even if you dont see the object.

I will be in the look out to that fact next time I witness missing one.

2019-12-12 01:50   
(edited on: 2019-12-12 01:51)
Gimisa.. as you noted in the image, your Windows 10 version is 1809 (issued November 13, 2018) so about a year old and pretty recent. There have been two updates since then to 1903 and 1909. I have no information that this will be relevant, but in the interests of pinning this down I thought I would check. [^]

2019-12-12 09:03   
Very interesting , I though window 10 was updating automatically . I request an update via parameter command to comply with your request and saw only little updates to net for exemple. I got restart request . When back in I did winver command as per your earlier instructions and got the SAME version number.!!

See for yourself: [^]

I check with :
"Select the Start button > Settings > System > About ."

And got same value. Additional detail provide with above function is installation date 2019-11-09 ( this computer is brand new DELL )

Here is more detail of Net and C++ version number should that be helpfull: [^]

Clear cache and going back to oscc keynote2 but this time with default cool viewer bandwidth of 2000kbps I got 2865 object count when stabilised compare to 2813 on earlier report .

Hope it helps
2019-12-12 11:26   
I just logged in again at 200 and for the first time at 200 my AV skin was grey ( and some terrain was missing) -- So I'm not sure how DIRECTLY involved MAX BANDWIDTH is in all of this? ( Other than it happens less often the lower the Bandwidth). But clearing CACHE always works.
2019-12-12 14:44   
(edited on: 2019-12-13 01:15)
I had a couple of machines where the automatic update did not get offered... I used the manual update assistant for those... [^]

Though, I have no evidence the version you are using is an issue gimisa.

2019-12-13 09:38   
sorry for asking such thing, but can you test the exact same viewer at SL ?
2019-12-13 12:44   
(edited on: 2019-12-14 06:08)
Two questions to be replied.

The first one is from Mister Austin as follows:
...This issue is for terrain lumps missing or objects (prims and/or mesh) not showing and no amount of waiting or clicking where it should be shows the outline or makes it rez.
To concure with this statement following two pictures.

One show 2 chairs and machine with missing one in the middle in edit mode. Is can be seen its totaly not there compare to second picture showing all of them in place in edit mode for comparaison.
Missing chairs: [^] Not missing chairs: [^]

The second question could we get same experiment with same viewer ( and settings 128m reach distance and 500kbps ) .

So this experiment is in SL Svarga location , a location that includes only prims not even sculpty.
Since I dont know the region enough to spot any missing thing all I can do is report the number of objects statistic presents.
First trial no viewer action simply rez in and correct for avatar white out by editing apparence.
Second trial is with clear cache and rez back in svarga same position same looking direction.
Third trial is no clear cache rezzing again in svarga.
1- 5120 objects reported [^] .
2- 3876 objects reported [^]
3- 4259 objects reported [^]

A day after this test this is what I saw with same setting in a visit to everything seem normal except a house I happen to check out . [^] .

For me it seem related to time somehow like its harder the first logging of the day in a region when I had no visitor. Can it be connected to flotsamcache the cache module as this one has a schedule for cleaning up. I will diseable this module later and see if it has influence on tomorrow result.

hope it helps

2019-12-14 12:35   
(edited on: 2019-12-14 19:55)
I probably should disclose that both the server desktop and the laptop running the viewer enjoy Comcast's 40 Mbps upload and 10 download ( as well as everything on the server being on an SSD - no HD ).

Also the rez point on the tested 2x2 region was mostly 10m away from the edge of the region. Any terrain loss seemed to be always over 256m away.
Yet terrain loss is invariably associated with a grey AV.

2019-12-14 13:31   
During oscc19 on Dec 14 at 13:00 PST this is what Caro Kelso and me were seeing from the stage of "Other Social Worlds and the Future of the Metaverse" presentation :

gimisa nothing [^] my viewe
kelso 3 seats 4 avatar no hat view [^]
caro 3 seats 4 avatar with Mel with Hat [^]
2019-12-14 14:33   
(edited on: 2019-12-14 14:34)
Just to report that I was using Firestorm 6.3.5 (experimental build for tests) at the OSCC19 opening plenary session, core dev panel and a following talk with 1500bps set for bandwidth, ultra display setting and 512m view distances and had no terrain or object loss. Ditto when I visited the shopping plaza and several of the expo areas.

2019-12-14 14:56   
oscc is a poor metric to test this on, so is OSGrid, there are too many variables at play there that, due to changes on how this stuff is sent in the first place, make it hard to determine if it is just a network glitch or an actual bug. Remember this stuff sends over UDP, even with the protocol as is it is difficult to determine if stuff has sent or not.

Since the problem occurs as of recent changes, what do we actually know here? We know the recent changes caused problems, so naturally they have to be the cause right? I am not so sure, I think the real cause here is an age old protocol deficiency that the recent "fixes" have brought to light.

As such I went back and looked at the changes in the commits and I reverted some of them. Now I found the protocol itself to be more stable, more consistent udp traffic and no more "burst and fails" as I have been seeing.

I get the "send by view distance" is a design to actually reduce the traffic and only send what is needed, but I think viewers cannot handle these bursts of data is creates. At least the Firestorm logs suggest udp pipeline breakdowns no matter the bandwidth.

And again, should the thrive not be to have viewers and OpenSim stable at ever higher bandwidth settings. Folks we are not in 2010 anymore, most people have more than 2mbit in download speeds if not more. Sure, adjust for those who don't, but at the same time don't cripple what capabilities we have just because of that.

I may make a patch of my changes at some point which both reverted and changed some stuff, which so far have resolved most issues I was made aware of by now over 10 different grids.

I strongly urge to review the changes to view distance rendering and sending of data as well as viewer object caching as those, for me and at least 6 other grids, were the main cause of trouble with master code. With that many people reporting issues and now a return to the status quo I simply find it hard to blame anything but those changes.
2019-12-14 15:23   
(edited on: 2019-12-14 15:27)
That post dating 2010 already state that bandwidth was not an issue back then when internet download speed was in the order of one or two mega ... Thanks to Shelenn to have point that one out for me: [^]

So more then eager to test what you did Tampa

2019-12-15 01:11   
Good work tampa. I hope this lets us home in on the problems. I have no doubt that the terrain loss and missing objects was first seen, and then quite seriously, in early April 2019 and was mitigated but jit fully resolved after that.

On the changes in bandwidth for users you note, I would point out though that some users, including me, will have been using systems with very fast gigabit university connections for their viewers for some years in SL and OpenSim without such problems showing.
2019-12-15 01:21   
(edited on: 2019-12-15 01:22)
Understanding a bit more about how the viewer side region cache actually works might help, but that may be inappropriate for this already long thread of comments on the issue. I do see quite a bit of white where textures should be and always fix that by clearing the cache. I use my viewers for SL and multiple OpenSim grids with direct login or HG jumps, will be changing view distances, zooming way out and back (way beyond the view distances) and in testing often am teleporting all over the place and will often not have a full region, so have bot worried that this may be a serious issue, but it does happen multiple times each week.

So this makes me wonder how robust the viewer side region cache mechanism is... especially in three situations...

1. revisiting a region after an earlier visit in same viewer session where the whole content was nit downloaded before avatar moved away.

2. having multiple avatars log in with multiple instances of the same viewer on one system. I often in testing have 3 or 4 viewers running.

3. changes made by one user in a region while other users are logged in being properly propagated.

etc. !!!

2019-12-19 03:14   
Made a few changes that may have impact on this
2019-12-19 06:06   
I saw the changes. Openvue and Ailand grids (all regions) and OSGrid "RuthAndRoth" region all now on latest dev master with the UDP ack and resend changes (

I am not myself seeing the terrain and object loss recently, but the update is in place in case others wish to test from their own viewer environments.
2019-12-19 07:55   
Hi would like to thank Ubit for the work he is doing on this difficult problem .

Per my test I witness that its hard to tell if viewer is effectively presenting all of region object if one does not know the region. There could be a wall or other object masking the missing object. That is why my test include a numeric value corresponding to the object counted in the scene by the viewer and in condition at hand.

The important point is consistency in reported value after proper time is allowed to let the count stabilize. One might question this test. I build confidence in this test by doing it in gimisa3 gimisaOS welcome region. This region runs "OLD" opensim release 0901 . The three following pictures shows a number of objects consistent after each loging . The first loging is after visiting which I will present results next. Second test is after clear cache . Third test is just reloging after second test.

gimisa3 test 1 object count 9309: [^]
gimisa3 test 2 object count 9320: [^]
gimisa3 test 3 object count 9300: [^]

Visiting welcome with same condition first teleport without doing anything . Second teleport after clear cache before logging , third teleport after doing nothing.

welcome test 1 object count 2376: [^]
welcome test 2 object count 2557: [^]
welcome test 3 object count 2441: [^]

Please note the difference in prim count ( a larger test in my region ) and in consistency of results . I am only a user and people with more knowledge could comment on what the viewer is reporting when object count is presented and if truly pertinent to the situation being tested.

As to its results your conclusion is as good as mine...
2019-12-19 08:49   
(edited on: 2019-12-19 13:56)
Using Firestorm with 1,500kbps bandwith and 512m draw distance
Openvue grid, Openvue region, Welcome plot (which covers whole 256m256m region) has 1,789 prims.

hop:// [^]

Firestorm (Feb 9, 2019) Objects - land impact = 1,789.
Scene Load Statistics Object Count = 1,938.

Tested also with Singularity Beta 1_8_7_7997_x86_64, using 512m viewer distance and 2,000kbps bandwidth and 3,000kbps texture bandwidth...

Singularity Beta 1_8_7_7997_x86_64 (Dec 13, 2019) Primitives on parcel: 1,789
Scene Load Statistics Object Count = 1,938.

The higher scene load statistics object count versus the reported prim/land impact is expected as Ubit notes below.

2019-12-19 09:02   
(edited on: 2019-12-19 12:06)
Using Firestorm with 1,500bps bandwith and 512m draw distance.

Visiting gimisa3 I see a region of 256x256 and the plot name "gimisa3 WELCOME region" which is not the full region that contains 5,175 prims/land impact equivalents. Note that the plot area is 60,512sq.m. So there are other plots on the region. I see 3 other plots when I use "Show property Lines". A total of 7,210 objects are in use on the region across all plots. Scene Load Statistics Object Count = 7,375.

Visiting gimisa4 I see a region of 256x256 and the plot name "gimisa4 Castle of ODDS" which is the full region in size (65,536sq.m) that contains 10,973 prims/land impact equivalents. Scene Load Statistics Object Count = 11,122.

The higher scene load statistics object count versus the reported prim/land impact is expected as Ubit notes below.

2019-12-19 09:11   
(edited on: 2019-12-25 02:40)
Using Firestorm with 1,500kbps bandwith and 512m draw distance.

Visiting Alan's grid

Welcome is a 256mx256m region with one land plot (named as the default "Your Parcel") and contains 1,725 prims/land impact. Scene Load Statistics Object Count = 2,115.

Winter is a 2x2 (512mx512m) var region with one land plot "Winter 2X2" that reports 4,080 prims/land impact. Scene Load Statistics Objects Count = 4,939.

The higher scene load statistics object count versus the reported prim/land impact is expected as Ubit notes below.

2019-12-19 09:19   
Viewer stats objects counts include things like each terrain 16x16m terrain patch etc
2019-12-19 13:45   
(edited on: 2019-12-20 13:05)
gimisa, on your images of the three visits to Openvue..where do you get the (different) object counts from?

In each image, as far as I can see it says objects = 1,805.

I was not sure why Cool VL reports different numbers to Firestorm and Singularity, so I installed the latest CoolVLViewer- (2019-12-14) to test myself... using default (?) bandwidth of 2,000 kbps, view distance = 512m...

hop:// [^]

About land - Objects - Primitives on parcel = 1,789.
Simulator Statistics Object Count = 1,938.

I.e. identical to Firestorm and Singularity.

2019-12-24 06:20   
Hi M. Austin. I thank you for your question.

I pretend that a simple examination of the land when you rez is not sufficient to asses the situation in regard to invisible prims.

I propose to compares object count from viewer statistic provide after stabilization for multiple logging to validate if the object presented to the user is all the object to be presented. So when count is similar between multiple logging I feel confident that all the object are presented by viewer and visible to user.

Please note in region where you have child agent created by the simulator in adjacent region the object count will be MUCH more important then the land count result by the amount of object visible to the viewer from those region. To be comparable one must be located and oriented in same direction on each logging.

Might I take this occasion to wish all opensim dedicate developers a productive 2020 for opensim.
2019-12-24 06:55   
Firestorm Viewer advice on setting bandwidth.... [^]
2019-12-24 10:39   

Above firestormviewer web link is same as I posted in this mantis post (0035940)
gimisa (reporter) 2019-12-05 03:27 thanks for re posting.

Might I re post also the (0036001) done 2019-12-19 07:55 Mainly its results. Understanding that all three picture on each region were taken logging repeatedly in the region of test and reporting viewer statistic object count on each of the three logging.

gimisa3 test 1 object count 9309: [^] [^]
gimisa3 test 2 object count 9320: [^] [^]
gimisa3 test 3 object count 9300: [^] [^]

welcome test 1 object count 2376: [^] [^]
welcome test 2 object count 2557: [^] [^]
welcome test 3 object count 2441: [^] [^]

You might be able to do similar test and come to your own conclusions.
2019-12-24 10:51   
Trying to figure out where you got those object counts gimisa ..

All three of your images in each set show the same number of actual objects ..

i.e. [^]
2019-12-24 12:54   
(edited on: 2019-12-26 01:50)
Me too.

2019-12-26 06:00   
The latest changes don't fix the issues I see. I do think it can be related to a client with less than perfect connectivity. I say it that way because with http and the udp stack in the server its supposed to handle these cases and not lose data. I dont see tons of retransmissions but at times a backup in un-ack'd data. Afain the protocols should handle that and not fail to rez objects or terrain.

Tampa back on 12/14 alluded to having backed out some change-sets and as a result getting better performance. Any chance you could share??

One more observation. With bandwidth set to 1500 on a hard wired connection I see the available bandwidth from "show queues" as closer to 2400. IDK if that number is calculated somehow but I've never seen it match the viewer settings for desired bandwidth. Might be something to that.
2019-12-26 12:09   
Thanks for the question. There is a few object count in stat its true.

I believe the important stat in our test is the render object count found in the advance pane of the viewer statistic .

 Let me post back the image presenting 4 stats on gimisa4 that I posted
(0035947) 2019-12-07 04:42 [^]

To obtain this image I copied 4 time the result object count presented in advance render object count as presented here: [^]

hope it helps
2019-12-30 10:08   
(edited on: 2019-12-31 06:19)
gimisa and alanscotch… we are trying things again and I was just visiting gimisa4.
It is on OpenSim Snail Release (Unix/Mono)

It all looks good to me even on a very slow link away from my usual rig this weekend.

I can't reach [^] Welcome today.. but I know Alan said he was already on latest (recent anyway) dev code.

Ubit did make a change to UDP handling to help prevent overload of data going to the viewer when it gets overloaded.. We know there are a lot of objects (10K+ on gimisa4), and in testing cache clearance and so on all can add temporarily to the load. I know you let things settle before reading off object numbers.

To try to get a handle on this I wonder if its possible for you (both?) to

a) update to latest dev master as at 2019-12-18 23:26 which incorporates the UDP throttles. Any adjacent regions that will be within view distance ought to be updated too just as belt and braces.

b) use a viewer that we know how it works (or think we do?) try Firestorm 6.0.2 if you will until we get to the bottom of the problem.

c) log on and let your inventory completely load,

d) then do a few log on tests and look round. Ideally test on a region that is placed a couple of regions away from an adjacent region (assuming you don't set the view distance larger than 512m) so that there is less confusion with adjacent region issues.

If you see especially terrain chunks missing that will be helpful to see the snapshot. I think object numbers are likely to be confusing and differ by lots of things, but if you definitely know there should be an object somewhere and cannot see it, and if you click in the area its meant to be and no outline wireframe or object shows when you do that... that is what we want to know too.

2019-12-31 14:58   
(edited on: 2020-01-01 06:30)
gimisa reports he is fixed after update of his grid to latest dev master as at 18-Dec-2019.

AlanScotch... if you use DreamGrid , can you update to 3.299 which now includes the 18-Dec-2019 OpenSim dev master incorporating the UDP throttle change and report any issue related to this Mantis after that?

2019-12-31 15:02   
I can safely say that I haven't seen terrain drops with the new code but this is definitely not fully resolved with prims failing to rez. UDP is still problematic especially with anything like a lossy connection.
2019-12-31 15:14   
Mike, do you mean completely missing even if you click where they are meant to be, or do they show a wireframe or appear when the area they should be in is clicked?

Which grid and region, and what viewer version if so? Lets try to pin this down, I am on a nice slow connection with packet loss showing for next few days!
2020-01-02 04:07   
M. Aiaustin here is results of test done with dec 18 build : [^]

First image compare Firestorm versions 64_5.0.7.52912, 64_5. and singularity . Second page show scenegate 0_1_2_41405 the new viewer release and cool viewer 1.26.24 .

All test were done three time one as is , on with clear cache and one as is again. Also except for the test done with the newest firestorm version all other test were done so they compare with previous notes posted in this mantis.

Firestorm-Singularity show success : [^]
Scenegate-coolViewer show problems : [^]

Hope it helps.

View Issue Details
8633 [opensim] [REGION] OpenSim Core major always 2019-12-03 13:12 2019-12-31 13:41
Verwijs Linux  
normal Bullseye (10)  
Standalone (Multiple Regions)
Mono / Linux64
Unable to connect to MySQL 8.xx with "mysql_native_plugin"
Unable to connect to MySQL 8.xx with "mysql_native_plugin".
i've added "mysql_native_plugin" to mysql configuration, so it should work...

22:06:34 - [SERVICE BASE]: Failed to load plugin OpenSim.Region.Framework.Interfaces.ISimulationDataStore from OpenSim.Data.MySQL.dll with args DataSource=localhost; Database=opensim; User ID=Opensim_Tester; Password=*****;System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. ---> Mono.Btls.MonoBtlsException: Ssl error:1000042e:SSL routines:OPENSSL_internal:TLSV1_ALERT_PROTOCOL_VERSION
at /build/mono-
at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00048] in <f1d89164a14d4cc28f481be33ba79a08>:0
at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status, System.Boolean renegotiate) [0x000da] in <f1d89164a14d4cc28f481be33ba79a08>:0
at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake(Mono.Net.Security.AsyncOperationStatus,bool)
at Mono.Net.Security.AsyncHandshakeRequest.Run (Mono.Net.Security.AsyncOperationStatus status) [0x00006] in <f1d89164a14d4cc28f481be33ba79a08>:0
at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation (System.Threading.CancellationToken cancellationToken) [0x000fc] in <f1d89164a14d4cc28f481be33ba79a08>:0
--- End of inner exception stack trace ---
at Mono.Net.Security.MobileAuthenticatedStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation)[0x0004b] in <f1d89164a14d4cc28f481be33ba79a08>:0
at System.Net.Security.SslStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x00006] in <f1d89164a14d4cc28f481be33ba79a08>:0
at MySql.Data.MySqlClient.NativeDriver.StartSSL () [0x00035] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.NativeDriver.Open () [0x002ce] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.Driver.Open () [0x0000b] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.Driver.Create (MySql.Data.MySqlClient.MySqlConnectionStringBuilder settings) [0x0004e] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.MySqlPool.CreateNewPooledConnection () [0x00000] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.MySqlPool.GetPooledConnection () [0x0008a] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.MySqlPool.TryToGetDriver () [0x0003f] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.MySqlPool.GetConnection () [0x0001c] in <0004ab8b375b422f9000ac25a68089d9>:0
at MySql.Data.MySqlClient.MySqlConnection.Open () [0x0016d] in <0004ab8b375b422f9000ac25a68089d9>:0
at OpenSim.Data.MySQL.MySQLSimulationData.Initialise (System.String connectionString) [0x00015] in <6b964457a60c4879989d4066068e2275>:0
at OpenSim.Data.MySQL.MySQLSimulationData..ctor (System.String connectionString) [0x00013] in <6b964457a60c4879989d4066068e2275>:0
at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <610ede100ffd4304b7e2f592d47303a9>:0
--- End of inner exception stack trace ---
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x0001a] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Reflection.RuntimeConstructorInfo.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00086] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Reflection.RuntimeConstructorInfo.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.RuntimeType.CreateInstanceImpl (System.Reflection.BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[] args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes, System.Threading.StackCrawlMark& stackMark) [0x0022b] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Activator.CreateInstance (System.Type type, System.Reflection.BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[]args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes) [0x0009c] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Activator.CreateInstance (System.Type type, System.Object[] args) [0x00000] in <610ede100ffd4304b7e2f592d47303a9>:0
at OpenSim.Services.Base.ServiceBase.LoadPlugin[T] (System.String dllName, System.String className, System.Object[] args) [0x0008b] in <3be84d26ce914911b42e2814d93fd8b6>:0
22:06:34 - [SERVER UTILS]: Error loading plugin OpenSim.Region.Framework.Interfaces.ISimulationDataService from OpenSim.Services.SimulationService.dll. Exception: Could not find a storage interface in the given moduleSystem.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: Could not find a storage interface in the given module
at OpenSim.Services.SimulationService.SimulationDataService..ctor (Nini.Config.IConfigSource config) [0x000cd] in <a35eea81d5954a55a7803b284eb93aec>:0
at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <610ede100ffd4304b7e2f592d47303a9>:0
--- End of inner exception stack trace ---
at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x0001a] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Reflection.RuntimeConstructorInfo.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00086] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Reflection.RuntimeConstructorInfo.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.RuntimeType.CreateInstanceImpl (System.Reflection.BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[] args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes, System.Threading.StackCrawlMark& stackMark) [0x0022b] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Activator.CreateInstance (System.Type type, System.Reflection.BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[]args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes) [0x0009c] in <610ede100ffd4304b7e2f592d47303a9>:0
at System.Activator.CreateInstance (System.Type type, System.Object[] args) [0x00000] in <610ede100ffd4304b7e2f592d47303a9>:0
at OpenSim.Server.Base.ServerUtils.LoadPlugin[T] (System.String dllName, System.String className, System.Object[] args) [0x0009d] in <585dd54713344d4bb50f4e8a671cdbbf>:0
22:06:34 - [SERVER UTILS]: Error loading plugin OpenSim.Services.SimulationService.dll: Exception has been thrown by the target of an invocation. args.Length 1
22:06:34 - Fatal error: System.Exception: Could not load an ISimulationDataService implementation from OpenSim.Services.SimulationService.dll:SimulationDataService, as configured in the LocalServiceModule parameter of the [SimulationDataStore]: config section.
at OpenSim.OpenSimBase.StartupSpecific () [0x001c9] in <20d88addcbf8427baf13a308fafb915e>:0
at OpenSim.OpenSim.StartupSpecific () [0x0010c] in <20d88addcbf8427baf13a308fafb915e>:0
at OpenSim.Framework.Servers.BaseOpenSimServer.Startup () [0x00069] in <af68679cae9a428e9b8ab9526695ee27>:0
2019-12-03 13:37   
I do believe the "Latest" mysql requires encrypted connections, which Opensimulator does not support, you must disable TLS/SSL on the server side ... If possible ..

Or use MariaDB that is not enforcing that requirement currently ...
Robert Adams   
2019-12-03 14:18   
That has been my experience -- the latest MySQL has added a bunch of security stuff to the login and connections that have made a lot of old libraries fail. The security additions are probably a Good Thing in the long run but it has tripped up many usages.

My solution has been to either down rev the MySql server version or switch to MariaDB.
2019-12-03 22:55   
It would have a small impact on the performance of the connections and the more you have the worse it would be, given OpenSim uses a ton of those I bet you would see slowdown of 10% at worst. MariaDB said it would ask users on secure install script whether to enable encrypted connections or not, so it is not a requirement, but I do not know what the default will be, guessing no, but cannot say for sure.

The question of good or bad can only really be asked for remote db and there you should use tunnels anyways at which point you already have a layer of encryption. Though I usually try to run database local to systems and would recommend doing that, because network and drive delay.

That said, would upgrading the plugin OpenSim uses even be possible? Could it provide the connector and still offer non-encrypted connections side-by-side?
2019-12-04 12:25   
disabling SLL did the trick for me :) by adding "ssl=0" and "skip_ssl" to mysql configuration. thanks BillBlight :)

An other option would be to add (if possible) "caching_sha2_password" (mysql 8.xx default) authentication for connecting to mysql..

more info here: [^]
Ferd Frederix   
2019-12-31 13:41   
Marked at fixed per Verwijs

View Issue Details
8632 [opensim] [REGION] Scripting Engine minor always 2019-12-01 16:09 2019-12-31 13:38
Ferd Frederix Xengine and Yengine  
Windows 10  
normal Yeti  
none Yeti "Server Release Notes" hash #defa235859889dbd"
Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
.NET / Windows64
Changed event fires with a 0x8 when Physics changes
All my dragons stopped flying in released code :-(

Opensim now fires the changed event with a CHANGED_SCALE when Physics kicks in. The way I had coded things, this causes the scripts to think it is time to shut down. I can code around it, but its going to break a LOT of content already out there.
Rex a prim. Add this simple script:

    changed(integer what)
        llSay(0, (string) what);

Now set the physics true and you will see it say Object: 8, which is incorrect. 8 is CHANGED_SCALE. [^]
2019-12-03 03:22   
Does this issue affect YEngine as well?
2019-12-03 07:10   
Hope your dragons will be happier with last change on master
Ferd Frederix   
2019-12-03 10:39   
Thank you, will add this one patch and try it tonight.
Ferd Frederix   
2019-12-31 13:37   
Fixed!, Thank you very much!

View Issue Details
8637 [opensim] [REGION] Script Functions minor always 2019-12-27 03:01 2019-12-28 06:20
Cnayl Rainbow  
Grid (1 Region per Sim)
BulletSim, ubODE
Mono / Linux64
Events moving_start() and moving_end() don't work the same as in Second Life
In Second Life these events are triggered by any movement but in OpenSim they are not. I have tried moving physical objects and also using function llMoveToTarget and in no case do the events seem to fire.
Create a sphere, make it physical and add the simple test script below. Then move the ball by hand. In Second Life as soon as it starts and stops moving it will report this via the moving_start & moving_end events, however in OpenSim it doesn't trigger these events.


2019-12-27 15:18   
Thanks for the report
Will take a look
2019-12-27 15:53   
(edited on: 2019-12-29 04:43)
This was already discussed in past ( mantis 6519)
when the events were made operational only for KFM and MovetoTarget
already then it was known SL did it on more cases...
but never improved
now many scripts may have handlers only considering those cases, and some may misbehave on editing position
fun fun..

Cnayl Rainbow   
2019-12-28 03:41   
I did try with MoveToTarget in a 0.9.1 region and that didn't trigger the events.

I guess if it's a case of "that's how it is" at least the wiki at [^] needs updating to show this in the notes column...
2019-12-28 04:33   
(edited on: 2019-12-29 04:42)
acording to those old mantis it should work (?)
issue now is how ill defined that actually is, at sl seems just a position change when code is actually "looking", didn't test enter sim, but on rez does not trigger them now, position change on edit triggers both at edit release (at least right order)
also seems some needed filtering is up (we will need some, position can have "noise")

With this ill conditions definition don't see how this things can be used reliable on any script, even "there" (didn't even looked to attachments cases where wiki just says "something" needs to be done)
I still don't say its a case of "that's how it is" but sure not that c... we see there...

Cnayl Rainbow   
2019-12-28 06:20   
Here is a test script I tried out - very chatty in SL but nothing in OpenSim

        vector pos = llGetPos();
        llSetStatus(STATUS_PHYSICS, TRUE);
        // Little pause to allow server to make potentially large linked object physical.
        // Look for owner within 20 meters in 360 degree arc every 1 seconds.
        llSensorRepeat("", llGetOwner(), AGENT, 20.0, PI,1.0);
    sensor(integer total_number)
        // Get position of detected owner
        vector pos = llDetectedPos(0);
        // Offset back one meter in X and up one meter in Z based on world coordinates.
        vector offset =<-1,0,1>;
// offset = offset*llDetectedRot(0); //Adding this line will orient the follower relative to the owner's position.


View Issue Details
6303 [opensim] [REGION] Scripting Engine minor always 2012-09-18 04:47 2019-12-16 06:59
TBG Renfold  
Grid (Multiple Regions per Sim)
Firestorm 4.2.2 (29837)
Touch event only fires once.
(0.7.4 Rel and I suspect master dev)

Compared to LL's touch event (this does not inclued _start & _end as they do as intented) OpenSim only seems to fire the event once until the avatar touches the object again.

On LL's grid the event is repeatedly fired until the avatar stops touching.
    touch(integer t)
        llSetColor(<llFrand(1), llFrand(1), llFrand(1)>, ALL_SIDES);
Basic script used:

        llSay(0, "Script running");
    touch(integer t)
        llSay(0, "Touched.");
2012-09-18 04:48   
Do you hold the mouse in place or wiggle it about ?
TBG Renfold   
2012-09-18 07:56   
Seems to work if I wiggle the mouse on the prim, but as soon as you stop, it stops.

It seems to be only when the mouse is held in place, the lack of event firing occurs.
2012-09-21 01:54   
Tested in Imprudence 1.4.0 beta 1 in both OpenSim and SL
Artemis Tesla   
2013-09-23 17:46   
Any chance of this getting fixed ?
2013-12-05 18:00   
This is going to be a complicated problem as the client appears to stop sending ObjectGrabUpdate messages when the pointer stops moving. This means some timer is required inside OpenSimulator to keep generating events, and proper processing to stop on degrab and stop if the viewer fails to send degrab for some reason.
TBG Renfold   
2019-12-16 04:28   
Should this be closed? It's been 6/7 years since this issue was created.
2019-12-16 06:59   
You can close it if has been solved or if the definition has changed. Far as I know there were some updates to the system to fix detectedgrab, not sure if that solved this too.

View Issue Details
8636 [opensim] [REGION] OpenSim Core minor always 2019-12-12 07:51 2019-12-13 08:22
aiaustin PC  
normal 10  
new master (dev code)  
  master (dev code) 65 d400b2c (2019-12-10 12:36)
Grid (Multiple Regions per Sim)
.NET / Windows64
Firestorm 6.3.2 expt
[ENTITY TRANSFER MODULE]: Exception on teleport ... Object reference not set to an instance of an object
I am seeing a red error consistently when I teleport from one OSGrid region "Vue-Port" (on latest Dev Master 65 d400b2c (2019-12-10 12:36)) to for example "sandbox Plaza" (on OpenSim Yeti Dev 052e4a060c: 2019-12-03 14:27:31 +0000 (Unix/Mono)) or "Dev Outreach" (on experimental code? - OpenSim Yeti Dev 05:41:10 12-10-2019 (Unix/Mono))…

15:49:24 - [ENTITY TRANSFER MODULE]: Exception on teleport of Ai Austin from <120.9305, 130.0715, 25.51622>@Vue-Port to <128, 128, 1.5>@Sandbox Plaza: Object reference not set to an instance of an object. at OpenSim.Region.Framework.Scenes.ScenePresence.MakeChildAgent(UInt64 newRegionHandle) in K:\OSGRID\opensim-\OpenSim\Region\Framework\Scenes\ScenePresence.cs:line 1610
   at OpenSim.Region.CoreModules.Framework.EntityTransfer.EntityTransferModule.TransferAgent_V2(ScenePresence sp, AgentCircuitData agentCircuit, GridRegion reg, GridRegion finalDestination, IPEndPoint endPoint, UInt32 teleportFlags, Boolean OutSideViewRange, EntityTransferContext ctx, String& reason) in K:\OSGRID\opensim-\OpenSim\Region\CoreModules\Framework\EntityTransfer\EntityTransferModule.cs:line 1200
   at OpenSim.Region.CoreModules.Framework.EntityTransfer.EntityTransferModule.DoTeleportInternal(ScenePresence sp, GridRegion reg, GridRegion finalDestination, Vector3 position, Vector3 lookAt, UInt32 teleportFlags) in K:\OSGRID\opensim-\OpenSim\Region\CoreModules\Framework\EntityTransfer\EntityTransferModule.cs:line 806
   at OpenSim.Region.CoreModules.Framework.EntityTransfer.EntityTransferModule.TeleportAgentToDifferentRegion(ScenePresence sp, UInt64 regionHandle, Vector3 position, Vector3 lookAt, UInt32 teleportFlags, GridRegion& finalDestination) in K:\OSGRID\opensim-\OpenSim\Region\CoreModules\Framework\EntityTransfer\EntityTransferModule.cs:line 578
   at OpenSim.Region.CoreModules.Framework.EntityTransfer.EntityTransferModule.Teleport(ScenePresence sp, UInt64 regionHandle, Vector3 position, Vector3 lookAt, UInt32 teleportFlags) in K:\OSGRID\opensim-\OpenSim\Region\CoreModules\Framework\EntityTransfer\EntityTransferModule.cs:line 407
2019-12-12 12:51   
Running on master code myself I am not seeing that, it looks like it is unable to make the previous simulator presence a child agent when teleporting, that in itself is not bad, it just means teleporting back is like teleporting to a place never visited before, taking a bit longer perhaps. Child agents are cleared after a while anyways so.

Does this happen on your own grid as well? If not, try contact OSGrid, problems comes from their binary, maybe not compiled properly.
2019-12-12 12:53   
think it is part of them mess after a failed tp/login
2019-12-12 14:24   
Thx. The error was observed between two OSGrid regions and was repeated. I will tidy up and retest in a cleaner environment.
2019-12-13 08:22   
I identified the issue as one specific Roth 2.0 mesh body (RothToo RC1 Mesh Body_One_Piece). Even going back to the original vendor box for a fresh copy shows the error. Resetting scripts in the object doe snot make any difference. I will investigate more.

View Issue Details
8635 [opensim] [GRID] Other Service tweak have not tried 2019-12-10 14:42 2019-12-11 06:38
simfr Linux  
tampa Debian  
low 10 / Buster  
no change required  
Grid (Multiple Regions per Sim)
Mono / Linux64
Having two Regions on a single host using mariaDB
Following lattency / performance issue, on our VPS hosting 2 regions, we would like to go from 2 SQLLite DB to 2 mariaDB.
Initially, the SQLLite DB was on the same directory of each region (easily transferable/scalable).
With mariaDB, is it better to :
1) Having a single mariaDB Server, with 2 databases (for each regions)
2) Habing two mariaDB Servers, with 1 database each ?
2019-12-11 06:38   
Mantis is not a user-support forum, for that visit the wiki: [^]
It also has information on best practices regarding setups.

View Issue Details
8366 [opensim] [GRID] Hypergrid major always 2018-09-11 21:48 2019-12-05 11:30
normal 16.04LTS  
Grid (1 Region per Sim)
Mono / Linux64
Attached scripts lose all state on first hypergrid jump
On the first HG jump to a foreign grid, scripts in all attachments cease working. They don't even receive a state_entry or CHANGED_REGION event. AO's, pose and photography HUD's, followcams, opencollars, mesh body HUDs will all stop working.

While still in the destination at the foreign grid, if we then cross or TP into another region on the same destination grid, scripts will start working again but have totally reset, lost all stored state like variable contents that they still had when leaving our own grid initially.

- Scripts are enabled on the destination grid regions
- Happens between fast grids as well as slow grids
- Happens even with one single scripted attachment with a small script
- I've heard this DID work between two hypergridded OS 0.8 regions, yet to confirm

I don't know whether this bug is limited to specific viewers (in this testcase I used the latest Firestorm)
2018-09-12 06:35   
Doesn't work either for the first jump from a 0.8 region to another grid's 0.8 region so this issue has been around for a while.
2019-09-20 01:13   
Dupe of 8049 (I am not allowed to add that relationship)
2019-09-20 03:38   
don't think viewers have anything to do with it
Sounds like just another HG "glitch"

Note that scripts transfer can only be expected to work between regions running similar versions, and same script engine. Xengine to Yengine may work, reverse will not.
There are also the diferent permissions settings...

But your observation that if failed already on old 0.8<->0.8 does point to a origianl issue somewhere on HG code
2019-09-20 04:14   
made a simple test wearing a box with this script
integer a = 0;
integer lastEv = 0;
        llSay(0, "Script running");
    touch_start(integer bbb)
        llOwnerSay((string)a++ +" "+(string)lastEv);
    changed(integer ch)
        lastEv = ch;

tested HG teleports btw my test grid and a a osg region almost on master
both on Yengine, but the issue should be on code paths shared by all engines.

on first HG tp the script did seem dead
repeating back and fw it did work fine

[04:09] Grid: The region you have entered is running a different simulator version.
Current simulator: OpenSim osC2_master_b3690c_111151_091819 (Unix/Mono)
Previous simulator: OpenSim Snail Dev (Win/.NET)
[04:09] Object: 32768
[04:09] Object: 256
[04:09] Object: 512
[04:10] Object: 11 512
[04:10] Object: 12 512
[04:13] Object: 32768
[04:13] Grid: Teleport completed from hop:// [^]
[04:13] Grid: The region you have entered is running a different simulator version.
Current simulator: OpenSim Snail Dev (Win/.NET)
Previous simulator: OpenSim osC2_master_b3690c_111151_091819 (Unix/Mono)
[04:13] Object: 256
[04:13] Object: 512
[04:14] Object: 13 512
2019-09-20 04:16   
tp to lbsa did a full reset, because lbsa is on Xengine.
return, worked fine.
2019-09-20 04:21   
btw don't make my mistake, always edit scripts on ground, not wearing them :)
thats another old issue
2019-09-20 04:50   
Script working on the second try makes sense, the destination has the asset at that point, but during the first jump the asset arrives after you get there at which point the state cannot be retrieved anymore, you have arrived already. Sending the attachments over before doing the jump would likely solve this, but that would mean redesigning the protocol.
2019-12-05 10:44   
I don't have the bug after changing the following setting from co-op (default) to abort for the destination region, but there is a warning there in the comment about possible stability issues:

    ; Controls whether scripts are stopped by aborting their threads externally (abort)
    ; or by co-operative checks inserted by OpenSimulator into compiled script (co-op).
    ; co-op will be more stable as aborting threads can cause instability.
    ; abort was the default option in OpenSimulator 0.8 and before.
    ; If this setting is changed between co-op and abort, then existing scripts will automatically be recompiled if necessary.
    ; However, the setting change will not take affect until the next time you restart the simulator.
    ; Setting changes will not affect state information stored for scripts.
; ScriptStopStrategy = co-op
ScriptStopStrategy = abort

This is on XEngine btw, I never really tried YEngine.
2019-12-05 10:49   
thx for the feedback
Yengine to Xengine will always reset scripts and lose state.
X to Y may work, because now Y can read X state, at least most the time.

but there are HG thingies..
2019-12-05 11:30   
My case is about XEngine hypergrid to XEngine (which works with 'abort' but not the default 'co-op'). That it fails with HG'ing YEngine to YEngine as well is interesting.

Be careful with testing, as you said once an attached script is cached it's fine on a return visit. Best test with fresh scripts.

View Issue Details
7636 [opensim] [GRID] Other Service block always 2015-07-09 05:08 2019-12-03 11:44
Cz Wolf Linux  
normal 14.04.2 LTS  
Standalone (1 Region)
Mono / Linux64
Firestorm 4.7.1 (45325)
Avatars cannot login/verify, Diva distro, standalone + OSG on one PC.
This problem with gatekeeper service I consulted with Nebadon and Allen Kerensky, and it may be connected to:
Field 'TMStamp' doesn't have a default valueMySql.Data.MySqlClient.MySqlException
in newest MySQL
- have newly installed server version: 5.6.25 MySQL
- have mono 4.0.1 or
- have new database
- have already running OSgrid OpenSimulators for reference
- have Mono JIT compiler version 4.0.1 (tarball Thu May 28 09:08:28 UTC 2015) or
- unpack and configure DIVA distro, binary, diva-r25950
- run simulator
- create users using console or using Wifi web
- unable to verify identity on login for any user
The console outputs (the whole process) included in attached file or to be found here online, as long as not solved issue: [^]
Unable to verify identity - DIVA.txt (55,780) 2015-07-09 05:08
IRC discussion with Nebadon & Allen.txt (12,550) 2015-07-09 23:57
Isis Ophelia   
2015-07-09 22:53   
I had also "unable to verify identity" I run diva-r25950. Both diva and the viewer in the same LAN behind a router on windows 8.1

In your attached file I read that "'TMStamp' doesn't have a default value" and googling for TimeStamp I found this: ".... for a timestamp that the operating system can provide during program execution" Seems to me that your operating system can not provide Mysql with the right timestamp to be executed.

I tried and tested so many different things, not sure which one fixed the problem. Listing them here, if you want to test them:
1)made new Inbound rules for tcp + udp ports in my windows firewall for public, private and domain.
2) to forward same tcp+udp ports in my router to my PC local IP.
3) this step is mentioned here [^] under NAT Issues. Added an entry to the hosts file. Mine looks like this: <---- I'm using a dyndns domain because I have a dynamic external IP. Yours would look instead like this: your_external_IP

If I remove this entry in the hosts file I can not connect to my diva installation. So seems this one fixed the problem.

I can now connect to my regions and teleport to other grids, but I still can not teleport back home.

On a side note. I see in your diva.txt attachment that you get the same error when diva comes up: OpenSim.Framework.Communications.RestClient [REST CLIENT] Error fetching resource from server: [^]
System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (500) Interner Serverfehler.
   bei System.Net.HttpWebRequest.GetResponse()
   bei OpenSim.Framework.Communications.RestClient.Request(IServiceAuth auth)

I don't know why we both get the same error.
Cz Wolf   
2015-07-09 23:56   
Thank you Isis for your reaction, going through my logs and for many suggestions. Reading that, I can add some more info on my configuration. There is no NAT and the computer is directly connected to internet, being a dedicated server just for opensim run by server hosting provider. The viewer is running on another PC, operating system and on different continent. :) There was no need to set any port forwarding rules, just to specify different ports for http listener and everything else listening on 9000 because of already running 3 other simulators (downloaded from OSG pages, success, no issues). Everything else is on default values and should work with them. Issues about teleporting you are describing I met when trying to deploy Raspberry PI but it is a different story about ARM architecture probably. Also teleporting was reported on Mantis (and closed and marked as resolved) by another user+Diva - not sure where. That metaverseink error seemed to me as trivial, some forgotten link and I have no answer to that too. Timestamps changed some way in newest MySQL and can be the cause as mentioned. There is a chance that change is still not reflected in Diva distro and that the fix is not described only. Including now our discussion on IRC (me, Nebadon and Allen) about this. After that discussion I tried to comment row in /etc/mysql/my.cnf i found, this way: # explicit_defaults_for_timestamp - my goal was to reestablish previous behavior in older versions of MySQL servers. But that did not help and no change was noticed after reboot. What we may need is the info how to run current diva opensim together with new MySQL, or to change the code of opensim in diva distro to reflect the change, or the culprit needs to be found somewhere else. I hope that the included discussion can be helpful too.
Isis Ophelia   
2015-07-10 11:19   
MySql is Version 5.5.8
I'm using Mowes Portable II for MySql + Apache + PHP5

You are probably using a newer version as the one with MoWes as the distributor of mowes has given up few years ago. Sorry Cz that I could not add more to help with your issue.
Cz Wolf   
2015-07-26 06:40   
Thank you anyway Isis! Further experimenting done ... Adding my new findings connected to the problem described above. My current oppinion and the conclusion: There is MySQL/TMStamp problem to be solved, to get compatibility MySQL/Diva distro. Otherwise I need a suggestion how to set corresponding values in Diva (similar to those working for standalones downloaded from I could also live with the solution - adding Wifi pages to standalone downloaded from if I knew that it is possible and how to do that. What I tried was:

Previously I got running sim in OSgrid, in addition now I am also able to run standalone with hypergrid enabled, having code from and described configuration (new MySQL, new Mono, default settings). I was getting "Unable to verify identity" errors when using code too, but never I was getting TMStamp errors there. To get rid of "Unable to verify identity errors" when setting up the standalone from I edited:

In opensim.ini
-------------- - replaced by public IP everywhere
numbers of ports 8002 and 9000 - replaced by choosen port (e. g. 9200)

http_listener_port = choosen port (e. g. 9200)

; Include-Architecture = "config-include/Standalone.ini"
Include-Architecture = "config-include/StandaloneHypergrid.ini"

File: StandaloneCommon.ini, works when set to:

HomeURI = "${Const|BaseURL}:${Const|PublicPort}"
GatekeeperURI = "${Const|BaseURL}:${Const|PublicPort}"

MyRegion = "DefaultRegion, FallbackRegion"

GatekeeperURI = "${Const|BaseURL}:${Const|PublicPort}"

Result = working standalone, hypergriding tested & OK

Notes -->

File: OpenSim.ini, the original setting was:

; http_listener_port = 9000

Include-Architecture = "config-include/Standalone.ini"
; Include-Architecture = "config-include/StandaloneHypergrid.ini"

File: StandaloneCommon.ini, the original settings I changed were:

; HomeURI = "${Const|BaseURL}:${Const|PublicPort}"
; GatekeeperURI = "${Const|BaseURL}:${Const|PublicPort}"

Region_Welcome_Area = "DefaultRegion, FallbackRegion"

; GatekeeperURI = "${Const|BaseURL}:${Const|PublicPort}"


DIVA DISTRO / tries, no luck:

In opensim.ini - replaced by public IP everywhere
numbers of ports 8002 and 9000 - replaced by choosen port (e. g. 9200)

In MyWorld.ini - replaced by public IP everywhere
numbers of ports 8002 and 9000 - replaced by choosen port (e. g. 9200)

GatekeeperURI = "${Const|BaseURL}:${Const|PublicPort}"
HomeURI = "${Const|BaseURL}:${Const|PublicPort}"

When tried: getting the same errors - services:

Field 'TMStamp' doesn't have a default valueMySql.Data.MySqlClient.MySqlException: Field 'TMStamp' doesn't have a default value
  at MySql.Data.MySqlClient.MySqlStream.ReadPacket () [0x00000]: in <filename unknown>:0
  at MySql.Data.MySqlClient.NativeDriver.GetResult (System.Int32& affectedRow, System.Int32& insertedId) [0x00000] in <filename unknown>:0

[GATEKEEPER SERVICE] Login request for Wifi Admin - Unable to verify identity of agent Wifi Admin. Refusing service.
[LLOGIN SERVICE]: Login failed for Wifi Admin, reason: Unable to verify identity
2019-03-21 14:39   
I just had this error pop up on my stand alone. I reinstalled Windows so upgraded MySQL to ver.8.0 while I was at it. Now, OSgrid Snail Dev 695d807696: 2019-01-26 16:42:42 version running in stand alone with hypergrid gives me the "Field 'TMStamp' doesn't have a default value" error and I can't login. If I take it off hypergrid and run localhost, I can log in. Everything was fine when I was running the previous version of MySQL. I think it was 5.5 but can't say for sure.

OSgrid Snail Dev a1d132d3ca: 2018-10-25 02:36:36 +0100 works fine on hypergrid with MySQL 8.0.

The error in the log:

2019-03-21 14:17:07,563 ERROR Field 'TMStamp' doesn't have a default value
MySql.Data.MySqlClient.MySqlException (0x80004005): Field 'TMStamp' doesn't have a default value
   at MySql.Data.MySqlClient.MySqlStream.ReadPacket()
   at MySql.Data.MySqlClient.NativeDriver.GetResult(Int32& affectedRow, Int64& insertedId)
   at MySql.Data.MySqlClient.Driver.NextResult(Int32 statementId, Boolean force)
   at MySql.Data.MySqlClient.MySqlDataReader.NextResult()
   at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior)
   at MySql.Data.MySqlClient.MySqlCommand.ExecuteNonQuery()
   at OpenSim.Data.MySQL.MySqlFramework.ExecuteNonQueryWithConnection(MySqlCommand cmd, MySqlConnection dbcon) in K:\OSGRID\opensim-\OpenSim\Data\MySQL\MySQLFramework.cs:line 102
2019-03-21 14:17:07,581 ERROR at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at OpenSim.Data.MySQL.MySqlFramework.ExecuteNonQueryWithConnection(MySqlCommand cmd, MySqlConnection dbcon) in K:\OSGRID\opensim-\OpenSim\Data\MySQL\MySQLFramework.cs:line 102
   at OpenSim.Data.MySQL.MySqlFramework.ExecuteNonQuery(MySqlCommand cmd) in K:\OSGRID\opensim-\OpenSim\Data\MySQL\MySQLFramework.cs:line 77
   at OpenSim.Data.MySQL.MySQLGenericTableHandler`1.Store(T row) in K:\OSGRID\opensim-\OpenSim\Data\MySQL\MySQLGenericTableHandler.cs:line 308
   at OpenSim.Services.HypergridService.UserAgentService.StoreTravelInfo(TravelingAgentInfo travel) in K:\OSGRID\opensim-\OpenSim\Services\HypergridService\UserAgentService.cs:line 709
   at OpenSim.Services.HypergridService.UserAgentService.CreateTravelInfo(AgentCircuitData agentCircuit, GridRegion region, Boolean fromLogin, TravelingAgentInfo& existing) in K:\OSGRID\opensim-\OpenSim\Services\HypergridService\UserAgentService.cs:line 345
   at OpenSim.Services.HypergridService.UserAgentService.LoginAgentToGrid(GridRegion source, AgentCircuitData agentCircuit, GridRegion gatekeeper, GridRegion finalDestination, Boolean fromLogin, String& reason) in K:\OSGRID\opensim-\OpenSim\Services\HypergridService\UserAgentService.cs:line 270
   at OpenSim.Services.LLLoginService.LLLoginService.LaunchAgentIndirectly(GridRegion gatekeeper, GridRegion destination, AgentCircuitData aCircuit, IPEndPoint clientIP, String& reason) in K:\OSGRID\opensim-\OpenSim\Services\LLLoginService\LLLoginService.cs:line 1079
   at OpenSim.Services.LLLoginService.LLLoginService.LaunchAgentAtGrid(GridRegion gatekeeper, GridRegion destination, UserAccount account, AvatarAppearance avatar, UUID session, UUID secureSession, Vector3 position, String currentWhere, String viewer, String channel, String mac, String id0, IPEndPoint clientIP, TeleportFlags flags, String& where, String& reason, GridRegion& dest) in K:\OSGRID\opensim-\OpenSim\Services\LLLoginService\LLLoginService.cs:line 947
   at OpenSim.Services.LLLoginService.LLLoginService.Login(String firstName, String lastName, String passwd, String startLocation, UUID scopeID, String clientVersion, String channel, String mac, String id0, IPEndPoint clientIP, Boolean LibOMVclient) in K:\OSGRID\opensim-\OpenSim\Services\LLLoginService\LLLoginService.cs:line 547
   at OpenSim.Server.Handlers.Login.LLLoginHandlers.HandleXMLRPCLogin(XmlRpcRequest request, IPEndPoint remoteClient) in K:\OSGRID\opensim-\OpenSim\Server\Handlers\Login\LLLoginHandlers.cs:line 141
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleXmlRpcRequests(OSHttpRequest request, OSHttpResponse response) in K:\OSGRID\opensim-\OpenSim\Framework\Servers\HttpServer\BaseHttpServer.cs:line 1245
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleRequest(OSHttpRequest request, OSHttpResponse response) in K:\OSGRID\opensim-\OpenSim\Framework\Servers\HttpServer\BaseHttpServer.cs:line 812
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.OnHandleRequestIOThread(IHttpClientContext context, IHttpRequest request) in K:\OSGRID\opensim-\OpenSim\Framework\Servers\HttpServer\BaseHttpServer.cs:line 609
   at OpenSim.Framework.Servers.HttpServer.BaseHttpServer.OnRequest(Object source, RequestEventArgs args) in K:\OSGRID\opensim-\OpenSim\Framework\Servers\HttpServer\BaseHttpServer.cs:line 583
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at HttpServer.HttpClientContext.OnRequestCompleted(Object source, EventArgs args)
   at System.EventHandler.Invoke(Object sender, EventArgs e)
   at HttpServer.Parser.HttpRequestParser.AddToBody(Byte[] buffer, Int32 offset, Int32 count)
   at HttpServer.HttpClientContext.OnReceive(IAsyncResult ar)
   at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.ContextAwareResult.Complete(IntPtr userToken)
   at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
   at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
2019-03-21 14:41   
Opensimulator has issues with the newest MYSQL, standing issue ..
2019-03-21 21:58 [^]
Ferd Frederix   
2019-12-03 10:37   
(edited on: 2019-12-03 11:45)
Mentioned above, but unrelated to the timestamp issue is that you cannot teleport home when using the /etc/hosts hack to solve loopback issues. etc/hosts will work when your Public IP address changes, the driver method will not.

Under /etc/hosts (which changes the DNS name for the server on the server to itself as or the LAN address) you also will find you cannot log into another grid and visit your own grid from the server. If you use a Windows Loopback device driver, both will work : going home and Hypergridding in from another grid to yourself. This is due to a nasty bug in Opensim, discussed elsewhere, where Opensim tries to use the Gateway address instead of the Public WAN IP. This is typically, the routers gateway, which is certainly not going to work as it certainly does not loopback in any possible router.

See [^] for the correct way to set up a Loopback adapter.

Ferd Frederix   
2019-12-03 11:44   
(edited on: 2019-12-03 11:51)
Also unrelated to the main thread, but good to know: Never connect an old Sim On A Stick to the Hypergrid as it is easily hacked in very serious ways that will expose very private information on your CPU and LAN.

Also unrelated to the main thread, but mentioned above is that Search does not work in Diva distro. The error is caused by Diva's service at [^] which has been offline for several years.

I have an relative new replacement at, [^] which also works in the viewer search. The PHP search files are Open Sourced as AGPL at

How to use Across the Hypergrid Search:

This INI registers your grid to be crawled by Datasnapshot Services, which must be enabled separately. Prims, regions and such have to be marked as "Show In Search".

data_services= [^]

This INI Setting sets Search on in the viewer. I used both setting for legacy reasons, not sure if both are necessary.

SearchURL= [^]
SimulatorFeatures= [^]

Also look for this line, which lets you query the database at Hyperica ( or locally)


Optional Hyperica Destination Guide, which is a work in progress. It is currently hand edited and needs to be made to be automatic.

View Issue Details
8542 [opensim] [GRID] Robust Server block always 2019-06-09 10:31 2019-12-03 10:23
Xitano x64  
normal 1903  
Grid (1 Region per Sim)
Login Attempt: HandleRequest() threw exception System.FormatException:
HandleRequest() threw exception System.FormatException: A cadeia de caracteres de entrada não estava em um formato correto.
   em System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
   em OpenMetaverse.Vector3.Parse(String val)
   em OpenSim.Server.Handlers.Simulation.AgentHandler.DoQueryAccess(Hashtable request, Hashtable responsedata, UUID agentID, UUID regionID)
   em OpenSim.Server.Handlers.Simulation.AgentHandler.Handler(Hashtable request)
   em OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleContentVerbs(OSHttpRequest request, OSHttpResponse response)
   em OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleHTTPRequest(OSHttpRequest request, OSHttpResponse response)
   em OpenSim.Framework.Servers.HttpServer.BaseHttpServer.HandleRequest(OSHttpRequest request, OSHttpResponse response)

Robust ERROR:
14:23:35 - [LLOGIN SERVICE]: Login failed for Xitano OdnuM, reason:
Trying Login
2019-07-31 14:26   
was this on windows with .net4.8 ?
Ferd Frederix   
2019-12-03 10:23   
Educated guess: Since this is the only vector3 in in AgentHandlers.cs, DoQueryAccess it is line 132:

position = Vector3.Parse(tmpOSD.AsString());

Since the language that Xitano is using is Portugese, floats under Culture rules are formatted 0,123. The position vector could have been sent using a comma for decimal points somewhere else. In this case the Vector3.Parse(tmpOSD.AsString()) which could be a TryParse, will throw this fatal error.

Maybe, possibly, track down where the vector comes from and store it as Culture Invariant.

Is it possible the 'floats as commas' the reason Culture.SetCurrentCulture(); is in effect here, so it will convert them correctly? Not sure.

View Issue Details
8610 [opensim] [GRID] Grid Service minor have not tried 2019-10-22 01:06 2019-12-01 15:50
new 0.9.0  
Grid (1 Region per Sim)
OpenSim.Server.Base.ServerUtils [SERVER UTILS]: Error loading plugin
OpenSim.Server.Base.ServerUtils [SERVER UTILS]: Error loading plugin OpenSim.Services.Interfaces.IAssetService from OpenSim.Services.AssetService.dll. Exception: Could not load file or assembly 'System.Data, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Data, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
  at OpenSim.Services.AssetService.AssetServiceBase..ctor (Nini.Config.IConfigSource config, System.String configName) [0x00104] in <f31b652b231f4d628798c6b11ce3e08a>:0
  at OpenSim.Services.AssetService.AssetService..ctor (Nini.Config.IConfigSource config, System.String configName) [0x00000] in <f31b652b231f4d628798c6b11ce3e08a>:0
  at (wrapper managed-to-native) System.Reflection.MonoCMethod.InternalInvoke(System.Reflection.MonoCMethod,object,object[],System.Exception&)
  at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00008] in <d0e12f672b88444ab4b6d9b2ecf20142>:0
   --- End of inner exception stack trace ---
2019-10-22 01:14   
You have not configured your assetservice properly, not a bug
2019-11-12 04:12   
please can you help me to configure ?? how can i joind your?
2019-11-12 04:15   
Mantis isn't a user support forum, either use the mailing list or IRC, all information is on the wiki it has a full tutorial on how to set everything up
2019-11-12 08:00   
Consider update to (needs .net 4.6 or mono 5)
if not
In this case is hard to provide help. Compare you ini files with the provided ones.
see if there wasn't some file lost from bin folder...
2019-11-18 04:50   

i use opensim mono 6.4
Please somebody can help me...when i start robust in local it's i transfert all file in vps when i do momo robust.exe i have the errors.

 OpenSim.Server.Base.ServerUtils [SERVER UTILS]: Error loading plugin OpenSim.Services.Interfaces.IAssetService from OpenSim.Services.AssetService.dll. Exception: Could not load file or assembly 'System.Data, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Data, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
  at OpenSim.Services.AssetService.AssetServiceBase..ctor (Nini.Config.IConfigSource config, System.String configName) [0x00128] in <9fb00c51ec134bbba8fbb1d533604aab>:0
  at OpenSim.Services.AssetService.AssetService..ctor (Nini.Config.IConfigSource config, System.String configName) [0x00000] in <9fb00c51ec134bbba8fbb1d533604aab>:0
  at (wrapper managed-to-native) System.Reflection.RuntimeConstructorInfo.InternalInvoke(System.Reflection.RuntimeConstructorInfo,object,object[],System.Exception&)
  at System.Reflection.RuntimeConstructorInfo.InternalInvoke (System.Object obj, System.Object[] parameters, System.Boolean wrapExceptions) [0x00005] in <285579f54af44a2ca048dad6be20e190>:0
   --- End of inner exception stack trace ---
2019-11-18 05:13   
Verify the mono version by running mono --version and make sure you have at least 5.4 installed, if not head to the mono project site and follow the instructions on how to add the correct mono for your distro and version.

Again, mantis is not a user-support forum, as this is not a bug, but misconfiguration I suggest either asking on the mailing list or IRC for help.
2019-11-18 09:10   
(edited on: 2019-12-02 04:03)
System.Data is part of .net and should be part of you mono installation
possible(?) something wrong with you mono instalation
Please try install it with the package mono complete

Ferd Frederix   
2019-12-01 15:50   
Opensim Mailing lists is a good resource. In this case, you need Users, not Devs. [^]

View Issue Details
8290 [opensim] [REGION] OpenSim Core crash always 2018-02-15 04:52 2019-11-27 11:49
Verwijs Window  
immediate 10  
new master (dev code)  
Standalone (Multiple Regions)
.NET / Windows64
PGSQL: "operator does not exist: character varying = uuid"
Fatal error: Npgsql.NpgsqlException:
operator does not exist: character varying = uuid
Severity: ERROR
Code: 42883
Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts.
   at Npgsql.NpgsqlState.<ProcessBackendResponses_Ver_3>d__9.MoveNext()
   at Npgsql.ForwardsOnlyDataReader.GetNextResponseObject(Boolean cleanup)
   at Npgsql.ForwardsOnlyDataReader.GetNextRowDescription()
   at Npgsql.ForwardsOnlyDataReader.NextResultInternal()
   at Npgsql.ForwardsOnlyDataReader..ctor(IEnumerable`1 dataEnumeration, CommandBehavior behavior, NpgsqlCommand command, NotificationThreadBlock threadBlock, Boolean preparedStatement, NpgsqlRowDescription rowDescription)
   at Npgsql.NpgsqlCommand.GetReader(CommandBehavior cb)
   at Npgsql.NpgsqlCommand.ExecuteReader(CommandBehavior cb)
   at OpenSim.Data.PGSQL.PGSQLSimulationData.LoadLandObjects(UUID regionUUID) in C:\OPENSIM-PGSQL\OpenSim\Data\PGSQL\PGSQLSimulationData.cs:regel 720
   at OpenSim.Services.SimulationService.SimulationDataService.LoadLandObjects(UUID regionUUID) in C:\OPENSIM-PGSQL\OpenSim\Services\SimulationService\SimulationDataService.cs:regel 144
   at OpenSim.Region.Framework.Scenes.Scene.loadAllLandObjectsFromStorage(UUID regionID) in C:\OPENSIM-PGSQL\OpenSim\Region\Framework\Scenes\Scene.cs:regel 2224
   at OpenSim.OpenSimBase.CreateRegion(RegionInfo regionInfo, Boolean portadd_flag, Boolean do_post_init, IScene& mscene) in C:\OPENSIM-PGSQL\OpenSim\Region\Application\OpenSimBase.cs:regel 464
   at OpenSim.OpenSimBase.CreateRegion(RegionInfo regionInfo, Boolean portadd_flag, IScene& scene) in C:\OPENSIM-PGSQL\OpenSim\Region\Application\OpenSimBase.cs:regel 376
   at OpenSim.ApplicationPlugins.LoadRegions.LoadRegionsPlugin.PostInitialise() in C:\OPENSIM-PGSQL\OpenSim\ApplicationPlugins\LoadRegions\LoadRegionsPlugin.cs:regel 130
   at OpenSim.OpenSimBase.StartupSpecific() in C:\OPENSIM-PGSQL\OpenSim\Region\Application\OpenSimBase.cs:regel 285
   at OpenSim.OpenSim.StartupSpecific() in C:\OPENSIM-PGSQL\OpenSim\Region\Application\OpenSim.cs:regel 211
   at OpenSim.Framework.Servers.BaseOpenSimServer.Startup() in C:\OPENSIM-PGSQL\OpenSim\Framework\Servers\BaseOpenSimServer.cs:regel 170

Estate_settings > "RegionName" is being read as uuid witch should be "character varying", same goes fo all other "varchar" type fields, not supported by pgsql...

Gavin Hird   
2018-02-15 05:05   
Please fetch the query that is failing from your Postgres log file. The NPQSL log in isolation is almost impossible to decipher.
2018-02-15 06:58   
lines from from pgsql log.
I also searched entire solution to find where SQL statement(s) are set/used...
** at line: ..\OpenSim\Data\PGSQL\PGSQLSimulationData.cs(542) **

[3788] ERROR: operator does not exist: character varying = uuid at character 109
[3788] HINT: No operator matches the given name and argument type(s).
              You might need to add explicit type casts.

[3788] STATEMENT: select "RegionUUID", "Revision", "Heightfield" from terrain
                   where "RegionUUID" = (('ab244920-f45c-11e7-8f1a-0800200c9a66')::uuid)
                   order by "Revision" desc limit 1

** at line: ..\OpenSim\Data\PGSQL\PGSQLSimulationData.cs(712) **

[3788] ERROR: operator does not exist: character varying = uuid at character 39
[3788] HINT: No operator matches the given name and argument type(s).
              You might need to add explicit type casts.

[3788] STATEMENT: select * from land where "RegionUUID" = (('ab244920-f45c-11e7-8f1a-0800200c9a66')::uuid)

2018-02-22 12:33   
should be the same as mysql migrations to bypass the error. with sql that works for pgsql of course..
2019-11-27 11:46   
on linux with pgsql 12 i get this:


operator does not exist: character varying = uuid
Severity: ERROR
Code: 42883
Hint: No operator matches the given name and argument types. You might need to add explicit type casts.
at Npgsql.NpgsqlState+<ProcessBackendResponses_Ver_3>d__9.MoveNext () [0x00621]: in <ec511381da734f6d81dd6777723a907e>:0
at Npgsql.ForwardsOnlyDataReader.GetNextResponseObject (System.Boolean cleanup) [0x0013f] in <ec511381da734f6d81dd6777723a907e>:0
at Npgsql.ForwardsOnlyDataReader.GetNextRowDescription () [0x00024] in <ec511381da734f6d81dd6777723a907e>:0
at Npgsql.ForwardsOnlyDataReader.NextResultInternal () [0x0000e] in <ec511381da734f6d81dd6777723a907e>:0
at Npgsql.ForwardsOnlyDataReader..ctor (System.Collections.Generic.IEnumerable`1[T] dataEnumeration, System.Data.CommandBehavior behavior, Npgsql.NpgsqlCommand command, Npgsql.NpgsqlConnector+NotificationThreadBlock threadBlock, System.Boolean preparedStatement, Npgsql.NpgsqlRowDescription rowDescription) [0x00064] in <ec511381da734f6d81dd6777723a907e>:0
at (wrapper remoting-invoke-with-check) Npgsql.ForwardsOnlyDataReader..ctor(System.Collections.Generic.IEnumerable`1<Npgsql.IServerResponseObject>,System.Data.CommandBehavior,Npgsql.NpgsqlCommand,Npgsql.NpgsqlConnector/NotificationThreadBlock,bool,Npgsql.NpgsqlRowDescription)
at Npgsql.NpgsqlCommand.GetReader (System.Data.CommandBehavior cb) [0x000f5] in <ec511381da734f6d81dd6777723a907e>:0
at Npgsql.NpgsqlCommand.ExecuteReader (System.Data.CommandBehavior cb) [0x00061] in <ec511381da734f6d81dd6777723a907e>:0
at Npgsql.NpgsqlCommand.ExecuteReader () [0x00010] in <ec511381da734f6d81dd6777723a907e>:0
at (wrapper remoting-invoke-with-check) Npgsql.NpgsqlCommand.ExecuteReader()
at OpenSim.Data.PGSQL.PGSQLSimulationData.LoadObjects (OpenMetaverse.UUID regionUUID) [0x00060] in <af1f0e3be576457a94f950d710123ba3>:0
at OpenSim.Services.SimulationService.SimulationDataService.LoadObjects (OpenMetaverse.UUID regionUUID) [0x00001] in <e3bd25c9acd14eb88781b1d45cc4a690>:0
at OpenSim.Region.Framework.Scenes.Scene.LoadPrimsFromStorage (OpenMetaverse.UUID regionID) [0x0001e] in <04215e0ba5014d32916eb90bc0e23a4d>:0
at OpenSim.OpenSimBase.CreateRegion (OpenSim.Framework.RegionInfo regionInfo, System.Boolean portadd_flag, System.Boolean do_post_init, OpenSim.Framework.IScene& mscene) [0x0033d] in <45e3d9cf1102483b90822458b4fd4fe0>:0
at OpenSim.OpenSimBase.CreateRegion (OpenSim.Framework.RegionInfo regionInfo, System.Boolean portadd_flag, OpenSim.Framework.IScene& scene) [0x00001] in <45e3d9cf1102483b90822458b4fd4fe0>:0
at OpenSim.ApplicationPlugins.LoadRegions.LoadRegionsPlugin.PostInitialise () [0x00146] in <0d59cd3a70c248648a6bf565441b7979>:0
at OpenSim.OpenSimBase.StartupSpecific () [0x0028e] in <45e3d9cf1102483b90822458b4fd4fe0>:0
at OpenSim.OpenSim.StartupSpecific () [0x0010c] in <45e3d9cf1102483b90822458b4fd4fe0>:0
at OpenSim.Framework.Servers.BaseOpenSimServer.Startup () [0x00069] in <805cdcc3b1d34402bdeaaf06bffb6130>:0

-- END
with "OpenMetaverse.UUID regionUUID" ...
Gavin Hird   
2019-11-27 11:49   
I don't think the version of Npgsql that we can use (an old 2.x version) supports PostgreSQL 12 at all, so you are in uncharted territory.

View Issue Details
8631 [opensim] [REGION] OpenSim Core block have not tried 2019-11-24 00:40 2019-11-27 04:09
Grid (1 Region per Sim)
Mono / Linux64
Firestorm 64
After last update to git master, regions wil not start correctly anymore.
After update to last git master
I get several errors like this:

ERROR: There was an error while scanning assembly: /opt/opensim/DeepImpact/bin/OpenSim.exe (Could not load method 5 due to Could not load file or assembly 'Mono.Cecil, Version=, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e' or one of its dependencies.)

What is Mono.Cecil and how can I fix this?

When I restart the region second time, this error-messages are gone, but the region does not load RegionConfig.ini anymore and stops initializations with selecting region as root, what is wrong and I can't login to this region!

MonoVersion: (Debian Wed Apr 17 23:39:09 UTC 2019)
Linux-Version: Ubuntu 19.04
OpenSim-Version: master 6e2b5ac238ec5614fb9067ef94024bccf0459264
2019-11-24 00:56   
(edited on: 2019-11-24 00:57)
Mono.Cecil is included in bin, and seems the right version, with correct dependencies

2019-11-24 01:20   
I have identified the problem at this commit update mono addins ( need to runprebuidl and recomp opensim)

Have todo with addins
But I have running clean with
This does not help.

This commit is the last working for me:
103ebac0823b78934d60cb06cdaf97b817f29534 : terrain: make sure modify does get unblocked

This next commit fails:
7dd5c9ccadd299b07170452a8cac3e4866fee732 : update mono addins ( need to runprebuidl and recomp opensim)

I have still no idea to solve this problem. running runprebuild will not work either
2019-11-24 01:56   
If I checkout last master and revert last changes to the files

to version in commit 103ebac0823b78934d60cb06cdaf97b817f29534
then it works.

What is the reason to change or update mono-addins/cecilRefelctor?
Is this update necesarry or can I use the previous version, which seems working to me?
2019-11-24 03:48   
ok changed the mono.cecil and the all lot again
can you please test?
Monamusa Kaliopov   
2019-11-24 05:15   
here all works fine (debian 9.x)before and after the replacement of the .dll
2019-11-24 05:16   
Yes, this latest commit fixed the issue :-) Thank you.
Monamusa Kaliopov   
2019-11-27 04:06   
(edited on: 2019-11-27 04:08)

so your issue was resolved .. this ticket need the status resolved.

2019-11-27 04:09   
Mono .dll replaced by Ubitumarov.

View Issue Details
8629 [opensim] [GRID] Asset Service major always 2019-11-19 16:26 2019-11-20 14:38
nixnerd linux  
high 0.9.1.x  
unable to reproduce  
none master (dev code)  
Grid (1 Region per Sim)
Mono / Linux64
Residents in my grid are telling me perms recently changed on rezzed assets that were prev copy/trans ans are no longer are
My gut instinct tells me such changes have happened over the last few weeks, maybe two, maybe four
2019-11-20 02:58   
Sorry, not enough information
2019-11-20 12:22   
(edited on: 2019-11-20 12:22)
Can you give the situation.. which grid, which version of OpenSim, what assets, what changes. Give something that lets others set up a test environment to replicate the issue.

2019-11-20 14:38   
Unable to replicate, after backing up sim and restarting to marking as resolved

View Issue Details
8628 [opensim] [REGION] OpenSim Core major always 2019-11-14 04:44 2019-11-19 08:09
aiaustin PC  
normal 10  
confirmed master (dev code)  
  master (dev code) Dev 36 45625a0
Grid (Multiple Regions per Sim)
.NET / Windows64
Firestorm 6.0.2 OS
Viewer Disconnect when TP between two grids from a region with same name as destination
I am observing an issue where the viewer disconnects (every time) to its B&W screen on HG TP between two grids from a region with the same name and on the same x,y map grid coordinates as the destination region on the other grid. At least that seems to be the common cause, as I can TP fine to regions on the destination grid with unique region names.

Actual cases are between OSGrid regions (e.g. "Vue" or "Far North") to Openvue grid regions (again e.g. "Vue" or "Far North").

OSGrid is on latest OSGrid release from 1-Nov-2019. Openvue grid is on latest dev master as at 14-Nov-2019. Avatar has no Bakes on Mesh. Viewer is standard Firestorm 6.0.2 OS version.

Disconnects as described using both hop:// in the title bar of the viewer or using domain:port:region in Map Tool for TPs.

Clearing Viewer cache and restrating has no effect.
This is a partial trace of the destination region of "Vue" o Openvue grid coming from OSGrid "Vue region on one failed attempt... the trace at the OSGrid console end looks normal.

12:33:10 - [CompleteMovement]: Missing COF for e858df02-a860-4b92-937a-2b87e4ebcd6d is ae3d94fa-122e-f1d7-7773-29ce654e7144
12:33:10 - [CompleteMovement]: HG
12:33:10 - [CompleteMovement]: end: 360ms
12:33:10 - [HGUUIDGatherer]: Failed to fetch asset 9a728b41-4ba0-4729-4db7-14bc3d3df741 from [^]
12:34:10 - [LLUDPSERVER]: No packets received from root agent of Ai.Austin for 60000ms in Vue. Disconnecting.
12:34:10 - [CLIENT]: Close has been called for Ai.Austin attached to scene Vue
12:34:11 - [JobEngine]: Stopping AsyncInUDP-e858df02-a860-4b92-937a-2b87e4ebcd6d
12:34:11 - [SCENE]: Removing root agent Ai.Austin e858df02-a860-4b92-937a-2b87e4ebcd6d from Vue
12:34:11 - [CAPS]: Remove caps for agent e858df02-a860-4b92-937a-2b87e4ebcd6d in region Vue
Firestorm.log (241,695) 2019-11-14 07:06
Ai-Austin-Firestorm.log (229,127) 2019-11-14 07:23
2019-11-14-Viewer-Disconnected-BandW-Screen.jpg (201,398) 2019-11-14 07:25
2019-11-14-Viewer-Contacing-New-Region-BandW-Screen.jpg (189,067) 2019-11-17 03:48
2019-11-14 04:52   
(edited on: 2019-11-14 04:55)
Another trace... from OSGrid "Far North" -> Openvue "Far North"

Viewer crashes to B&W screen which then shows the QUIT dialogue.

OSGrid end... looks normal "avatar has left the building".

Openvue end...
11:02:14 - [HELO SERVICE]: Unable to perform HELO request to [^] The remote server returned an error: (404) Not Found.
11:02:14 - [HG INVENTORY SERVICE]: HELO returned
11:02:14 - [CompleteMovement]: Missing COF for e858df02-a860-4b92-937a-2b87e4ebcd6d is ae3d94fa-122e-f1d7-7773-29ce654e7144
11:02:14 - [CompleteMovement]: HG
11:02:14 - [HELO SERVICE]: Unable to perform HELO request to [^] The remote server returned an error: (404) Not Found.
11:02:14 - [HG ASSET SERVICE]: HELO returned
11:02:14 - [CompleteMovement]: end: 547ms
11:02:14 - [HGUUIDGatherer]: Failed to fetch asset 9a728b41-4ba0-4729-4db7-14bc3d3df741 from [^]

then after 1 minute

11:03:13 - [LLUDPSERVER]: No packets received from root agent of Ai.Austin for 60000ms in Far North. Disconnecting.
11:03:16 - [CLIENT]: Close has been called for Ai.Austin attached to scene Far North
11:03:16 - [JobEngine]: Stopping AsyncInUDP-e858df02-a860-4b92-937a-2b87e4ebcd6d
11:03:16 - [SCENE]: Removing root agent Ai.Austin e858df02-a860-4b92-937a-2b87e4ebcd6d from Far North
11:03:16 - [CAPS]: Remove caps for agent e858df02-a860-4b92-937a-2b87e4ebcd6d in region Far North
11:03:16 - [Scene]: The avatar has left the building

2019-11-14 05:58   
(edited on: 2019-11-14 06:02)
I made a "Far North" on ZetaWorlds, teleported over to North via worldmap just fine in FS 602

Just went back fine as well. The errors there are timeouts which could happen for all sorts of reasons.

2019-11-14 06:11   
(edited on: 2019-11-14 06:21)
Ai check if regions uuids are diferent (simple silly things check first)

2019-11-14 06:17   
(edited on: 2019-11-14 06:20)
Thanks Tampa and Ubit… I did check the UUIDs of the regions as I also immediately suspected that... and they are different in all cases.

That's also why I cleared the viewer cache in case there was some viewer side content caching going on. That had no effect.

I also made sure I was not using any Bakes on Mesh. Used the standard Firestorm 6.0.2 OS viewer, etc.

The 60 second time out is a bit irrelevant, as that is just the time out of the attempted login to the destination grid/region which crashes the viewer immediately.

I placed local avatars on the destination region and on the source region and I see the avatar go away cleanly, and see it arrive on the destination grid, even as the viewer of the teleporting user crashes, and as expected it clears away after the timeout.

I wonder if this might be something OSGrid side?

2019-11-14 06:21   
(edited on: 2019-11-14 06:27)
Ah, let me check is any ADJACENT (child) region has a UUID that matches....

No they don't - they were a bit similar so I had a scare for a moment.

2019-11-14 06:23   
Seems like if the UUID were the same it would not even teleport you, at least I cannot get there now having set the region UUID the same as yours, just teleports me back to the region center.
2019-11-14 06:28   
The regions are at the same x,y location on both grids too.. though that has not caused issues before.
2019-11-14 06:31   
Otherwise most welcome regions would have trouble too, remember most of them are either 9000,9000 or 7000,7000 for example, named the same too. Whatever is going on hints more toward something losing connection for some reason.

To clarify you are getting an actual crash aka program close and not a simple "you have been disconnected" ?
2019-11-14 06:33   
(edited on: 2019-11-14 06:37)
Tampa, if you still have your "Far North" region up locally on you grid, can you see if you can teleport back and forth to

hop:// [^]

You can also use a space rather than the %20 in the name in the top navigation bar. But if I do that on mantis it does not render properly.

I was able to crash straight away when I did that from far North on the Openvue grid...

so if you can also go here...

hop:// [^]

Then TP to hop:// [^]

and then back to your grid Far North. Does that all work?

2019-11-14 06:35   
(edited on: 2019-11-14 07:26)
Correct Tampa. To clarify.. the viewer is immediately crashing to its Black and White style crash screen with the "View IM & Chat" and "Quit" buttons as usual for a Firestorm viewer crash.

See attached 2019-11-14-Viewer-Disconnected-BandW-Screen.jpg

2019-11-14 06:53   
"debug http all 6" at each end does not show anything unusual beyond the messages shown above.
2019-11-14 07:06   
Added firestorm log from a logout vue to osg
2019-11-14 07:24   
Added Ai-Austin-Firestorm.log of Openvue to OSGrid crash as a comparison.
2019-11-17 03:53   
When the TP occurs from grid 1/region to grid 2/region the view almost instantly goes to its Black and White state. But it does not immediately shows the disconnected from region/Quit popup. It shows the "Contacting New Region" progress bar which continues to move across to about 75%...

See attached image 2019-11-14-Viewer-Contacting-New-Region-BandW-Screen.jpg

After a while at around 75% it then shows then shows the popup saying disconnected from region and providing the two View IM and Quit buttons as the only things you can do.

See attached image 2019-11-14-Viewer-Disconnected-BandW-Screen.jpg
2019-11-17 05:01   
(edited on: 2019-11-17 05:04)
As I said, main issue on this is region's position on grid map.

Region positions are used as the main region identification in viewers as the so called region handle, a long number created from map position X and Y.

So HG will just fail if there is an overlap of handlers of regions seen at start grid, and the handlers of regions seen at destination grid

For viewers same handler (position on map) means SAME region.

2019-11-17 05:06   
Thanks Ubit. Fix can be to shift X,Y positions of regions on one of the grids then. Easy enough for specific commonly used HG TPs or identified conflicts.

But I do now have a concern for the many grids based on packaged distributions like Diva D2 and Fred Beckhusen's DreamGrid as people will likely use the default x,y position as regions are created. We used to have many grids that base their regions on and around 1000,1000.
2019-11-17 05:18   
yes it is a big HG issue.. no idea if it ever did seem to work, because things are as i said, and we can't disconect viewer from all regions during TPs, they need to stay connected to sender until the TP is done. So very confusing if they think sender and receiver are the same...
2019-11-17 09:06   
"Region positions are used as the main region identification in viewers as the so called region handle"

Another rather stupid part of the protocol then. Can this be worked around? Perhaps tricking the viewer? Else I suppose we need to talk to the viewer devs to account for situations where the overlap causes issues.

That said, all the grids I run put their Welcome at 7000,7000 and teleporting between them has not caused issues, same with Far North being located the same position on ZetaWorlds and on Vue, yet the logout only happens when I try to go to OSG. Am I missing something?
2019-11-17 10:41   
Good point Tampa... one end of my example HG TP fails is OSGrid. Does not matter if it is source or destination.

Maybe worth some more testing to see if It is an issue beyond OSGrid... which it ought to be given what Ubit had said about how viewers work. Makes me wonder if we got away with it working in some way before viewer side caching was enabled? Or if changes... speed ups... in HG TP gave shown the Underlying issue more clearly.
2019-11-18 03:19   
Just as a check, I have established that the issue occurs between any two grids I have tested on.. and is a NOT specific to one of the locations being on OSGrid.

Simply moving the x,y location of one end of the HG TP makes it work.
2019-11-18 04:10   
Confirmed across 5 grids, though what to do about it is another page entirely. Changing this to confirmed though since it's kind of a big deal for HG.
2019-11-18 13:21   
Seems like Ubit made changes to master, I can pull in the changes and apply them to Far North if you want to test there.
2019-11-18 13:28   
(edited on: 2019-11-18 13:49)
I just fixed the block of those teleports.
We had it on one code path, not other.
Nothing new. This teleport never worked.
There may still be crashes if there are adjacent regions around both ends if the teleport.
Will check that code.

2019-11-18 13:48   
(edited on: 2019-11-19 04:00)
I made changes on my grids to ensure none of my regions overlap in terms of map grid coordinates already.

Good thought about adjacent visible (child) regions triggering the problem as well as the specific source and destination.

I made a suggestion for a minor rewording of the message Ubit put into the commit.

Try going other region first
Try going to another region first

2019-11-18 14:25   
could we not teleport the user to a "pseudo region" at another position on the local grid, which isn't a region but just like a "holding pen" pretending to be different coordinates, that then just sends the viewer on the real hg teleport from there, if this condition is detected?
2019-11-18 14:47   
(edited on: 2019-11-18 14:47)
I like that idea, kinda like old HG you needed to use the links and then you could jump on the local grid just automatic without the user seeing it. Weren't there coordinates 0 to 32 that are reserved for something anyways? Could use those for that.

2019-11-19 08:09   
Sometimes I experience another issue, where I get an "Unable to verify identity" message when I try to TP from my test grid to some other grids (e.g. OSG never fails, Metropolis fails) or when I try to TP back to my grid without providing a region. The interesting and maybe related thing, is that it works if I TP first to a working grid and from there to the blocking grid (e.g. first TP to OSG then to Metropolis). I will investigate more time in exploring this later this week.

View Issue Details
8551 [opensim] [REGION] Scripting Engine major always 2019-06-19 10:22 2019-11-18 09:34
Grid (1 Region per Sim)
Mono / Linux64
YEngine leaking memory from strings in event
There is a memory leak in YEngine with any events that have string arguments. Events such as listen, link_message, http_request, http_response, dataserver, etc.

The memory from the string arguments does not appear to be cleared when the event exits, and as a workaround you must manually clear the string.

Curiously, the memory appears to be getting cleared on a region restart, or when you relog in the case of scripted avatar attachments.
The script below exhibits the problem, and memory usage will increase by 22 bytes with each click.

default {
    touch_start(integer num) {
        llMessageLinked(LINK_THIS, 0, "MEMORY LEAK", NULL_KEY);
    link_message(integer link, integer num, string msg, key id) {
2019-06-19 10:43   
(edited on: 2019-06-19 10:55)
can confirm this is an issue .. Work around until fixed is clearing the variables after they are used, as stated in this mantis ..

default {
    touch_start(integer num) {
        llMessageLinked(LINK_THIS, 0, "MEMORY LEAK", NULL_KEY);
    link_message(integer link, integer num, string msg, key id) {
        msg=""; //clear the msg variable after use.

Not really a leak more of an accumulation on uncleared variable memory space.

2019-06-19 10:59   
(edited on: 2019-06-19 11:00)
...more of an accumulation on uncleared variable memory space.

Isn't that what a memory leak is?

EDIT: Regardless though, this can result in an OutOfHeapException

2019-06-19 11:02   
technically a leak occurs without user interaction or active functions .. I know a minor difference but this takes activity to accumulate.

Yes OutOfHeap is the end result ...
2019-11-18 09:34   
Change master ( on this

View Issue Details
8613 [opensim] [REGION] Scripting Engine major always 2019-10-23 07:47 2019-11-18 04:33
Edward Ashford  
Grid (Multiple Regions per Sim)
.NET / Windows64
llDialog: At least 1 button must be shown - Scripting Flaw
llDialog: At least 1 button must be shown hop:// [^]

Yeah there are LOTS of those. It's a scripting flaw in Opensim that doesn't exist on SL
To fix it.... I would have to update literally hundreds of scripts. Big job. But thanks for letting me know. : )
OpenSim Snail Dev OSgrid a1d132d3ca: 2018-10-25 02:36:36 +0100 (Win/.NET)
2019-10-23 09:18   
That error message also appears in SL. Not having it was a bug that was fixed. We don't usually reintroduce fixed bugs.
2019-10-23 10:48   
Actually .. [^]

your region is running OpenSim Snail Dev OSgrid a1d132d3ca: 2018-10-25 02:36:36 +0100 (Win/.NET)
almost a year old build ... This was fixed in January of 2019
Edward Ashford   
2019-10-23 17:02   
Oh ok, thanks BillBlight. It's not actually my region, though I'll let the region owner know that.

View Issue Details
8447 [opensim] [REGION] Script Functions minor have not tried 2019-01-10 13:15 2019-11-18 04:33
SnootsDwagon All  
Standalone (1 Region)
Feature Request: llDialog() to allow empty [] list

Currently the Opensim script engine will hang on an unfilled [] list field. In truth, there is no absolute necessity to include a list in llDialog(), nor need to place "" within the brackets. On Inworldz they allowed empty [] without causing a script error; the system just "filled in" the empty brackets.

It would be wonderful if the Opensim script engine were updated to allow empty list brackets in llDialog(). In my particular instance it would prevent me from having to manually alter literally hundreds of scripts and place "" within the []. There are a lot of scripts coming in from Inworldz, where both subroutines at the end of the code and an empty llDialog() [] list was allowed. If empty [] were to be allowed in Opensim scripting, I would bless you and your family and your pets, showering good thoughts upon you and great appreciation. : )
2019-01-10 13:55   
<cia-opensim> opensim: ajlduarte * r43f4eca67cb0 OpenSim/Region/ScriptEngine/Shared/Api/Implementation (LSL_Api.cs):
<cia-opensim> mantis 8447: empty buttons list in llDialog now shows Ok button

This is now as current spec and hope it helps

if so, me, my family and my cats thank your blessing, good thoughts and great appreciation

2019-01-10 14:47   
Well awesome. I'll have to download and (sigh) re-install the latest version. Easier than updating 700 scripts though! :D

Which version is this now operational in? Thanks.
2019-01-10 14:50   
Commit r43f4eca67cb0

on the Master git ..
2019-01-10 15:37   
/me cocks dwagon head and scritches ear fins and politely requests that in layman's link. ;D
2019-01-10 15:41   
(edited on: 2019-01-10 15:42) [^] [^]

2019-01-11 06:10   
Thank you! : )
2019-01-11 06:14   
As a note-- first link on the first link page results in "page not found".

And for those of us who aren't system coders, "building" code isn't our cuppa tea. Not everyone is a tech, uses Visual Studio, etc.

Is there a 'ready to install' version of this available? (.exe, .msi or .zip version?)
2019-01-11 07:48   
if you are talking about this , "git clone git://" [^] that is a git repository so no you can't open that in the web browser ..

But if you read the page, you find the link to the web version of it, [^]

And No if you don't desire to build your own then you have to wait for wherever you normally get it, and you are at their mercy.
2019-01-11 09:57   
Eeeps! ;)

Seems odd to me for someone to go to all that work modding... then not build an installable file. Much as I appreciate all the work, doesn't do the average user much good if we can't install it.
2019-01-11 10:00   
That is because the dev branch is just that DEV ...

Once osgrid decides to update it's build, then people who can't or don't want to compile will have access ...
2019-01-11 13:22   
Ah I understand. Thanks Ubit, Bill. Will look forward to the release. : )
2019-01-11 13:52   
(edited on: 2019-01-11 13:56)
@SnootsDwagon - as well as the OSGrid add on region precompiled version at [^] are some ready to run versions

1. Sim on a Stick ... up to 0.8.0 - not updated recently. [^]
2. Diva Distribution (D2) ... up to date as at stable release. [^]
3. Outworldz Dreamgrid ... up to [^]

I have blog posts with some experience and resource notes for these at [^] [^]

2019-01-11 13:57   
OSGrid is not usually far behind the latest dev master version @Snootsdwagon .. last version is on 26 Nov 2018 at the moment, but they usually get a precompiled version ready as soon as they are comfortable the recent developments are stable.
2019-01-11 14:16   
@aiaustin, he was looking for a compiled version with THIS fix in it ..
2019-01-11 14:29   
Got it.
2019-01-11 19:27   
Yup. I have items I managed to salvage from Inworldz before it collapsed. All of them contain the same short script, with an "OK" llDialog() (no need for list variables)... and there are 700+ of them. (They explain the jokes in the Hall of Funny on ElvenSong). So it's waiting for the new version or re-doing 700+ scripts. I'll wait for the new version. ;D
2019-01-12 06:53   
Sorry, but we do not make snapshots of dev code. They can be dangerus.
Dev git code, specially after a commit, is in early testing stage.

Osgrid and several more people do compile and run it in easy recoverable, test regions, providing fundamental feedback.
Osgrid does binary releases from that on regular basis.
They are pre configured for osg usage, but can be made generic by replacing all ini files with oriignal ones.

Our own release cycle is very slow, because we would like to do it after collecting somewhat large feedback, even from users like osgrid users.
but then we keep making changes... ;)
2019-01-12 07:28   
I understand. For me this is a major one, as it affects 700+ items in one of our most popular exhibits. Every script is inactive because the script language doesn't recognize an empty [] list in llDialog. Could change it by hand... but that is a lotta, lotta time involved. It affected scripting brought in from elsewhere on the last Fundraising Event too; we were constantly having to upgrade scripts because of this issue and the issue of subroutines being forced at the beginning rather than the end of the code (what was Cory Linden even thinking?).
Anyhow, still stands: would love to see this update on OSgrid. Thx. : )
2019-01-12 13:10   
(edited on: 2019-01-13 01:29)
The OSGrid folks updated today to latest dev master ... [^]

2019-01-12 14:27   
Woot! Thanks Aiaustin & all!

View Issue Details
8626 [opensim] [GRID] Robust Server minor always 2019-11-12 14:27 2019-11-18 04:17
Grid (1 Region per Sim)
.NET / Windows64
When specifying region to login, user will sometimes land in a region with similar name.
This bug exists in past code as well, but the patch I'm submitting is for recent trunk (yeti).
Prior to logging into the grid, if a user specifies a region such as "Welcome", they may land in a region with a similar name such as "New Welcome".
Create multiple regions with similar names such as Welcome, My Welcome, Old Welcome. Open your favorite viewer, specify the region to login to as "Welcome" and then login. You may or may not land at your intended destination and may very well end up in Old Welcome.
I found that in OpenSimServices.LLLoginService in the LLLoginService.cs file the code tries to resolve the specified name by searching for a region "Like" the one specified and then returns the first element in the search, which may or may not be the correct region.

The changes I have made which are included in this patch will search first for the specific region name provided by the user, if found, it will return that region and the user will land there, if that region is not found, the code will continue as previously coded.

There are some changes to the OpenSim.Data.PGSQL project which I believe are fine, but I'm not a postgres user and my changes were done in that file by looking at other code in that files as an example. If you are a postgre user and have issues with this patch, check there first to be sure I didn't make an error. (3,749) 2019-11-12 14:27
2019-11-13 22:38   
applied patchs, then changed a few things..
2019-11-18 04:17   
Could someone test this, verify it works on both db systems?

View Issue Details
8627 [opensim] [REGION] Scripting Engine major always 2019-11-12 23:48 2019-11-14 07:34
Kayaker Magic Linux Mono  
high Dev  
Grid (Multiple Regions per Sim)
Mono / Linux64
YEngine gives reference error for logic == expressions
Several scripts of mine that worked fine in earlier versions of OpenSim/YEngine are now reporting an error on compile:
"Error: Object reference not set to an instance of an object"
I found the simplest example that gets this error is:
        if (0 == 0)
This is simplified from the original code where the first 0 was an integer expression that I was testing for 0. But even comparing 0 with itself generages that reference/instance error.
I'm unsure when the error appeared, the scripts were not generating errors on a dev master version from several weeks ago. I tried this little script in Snail Release and the error is still happening!
2019-11-13 04:15   
That does not seem like a reasonable thing to do and since that is effectively if(TRUE) why not use that?
2019-11-13 04:53   
Because it might break existing scripts you even don't have access to.
2019-11-13 04:56   
If a script contains if (0 == 0) or (TRUE) I think there are bigger issues to solve than that, because that is a non-sensical thing to do frankly.
Kayaker Magic   
2019-11-13 10:24   
My scripts do not conatain if (0 == 0). They contain
if ((complicated logical expression calling LSL bunctions)==0)
But I was able to simplify them to (0 == 0) and still get an error from the compiler.
2019-11-13 13:07   
this seems to be only a Constant compareOP Constant issue right?
( compareOP beening == <= etc)
2019-11-13 15:29   
made changes on master.
note that string compareOp string with
compareop diferent than '==' will work unlike standard
following c# strings order
Kayaker Magic   
2019-11-14 00:31   
Yes, this is a problem with comparOP Constant! And it is fixed, thank you.
Looking back at my original code that got the error, it looked something like:
if (a&CONST == 0)
According to the LL wiki, the == will be done first, which is two constants being compared. If the code is re-written to say:
if ((a&CONST) ==0)
Then there is no error. So the error yesterday is a reminder to add parentheses! I re-built and installed the new version of OpenSim (commit 45625a02a214d61dfc549d56c4a4daa44369f225) and I no longer see the error on the first if statement above. Now that I understand it is an issue with constants only, I wish you had left the error in, but changed the message to "you should fully parenthesize your if statements!".
2019-11-14 07:34   
yes a&CONST == 0 is silly
a trap for those used to left -> right parsing
always good idea to use, even abuse of () to enforce priority, and on any language
( something i also forget ;) )

View Issue Details
8623 [opensim] [REGION] OpenSim Core major random 2019-11-02 13:54 2019-11-13 06:33
Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Mono / Linux64
Firestorm, Dayturn, Singu
llSetLinkPrimitiveParamsFast inside for loop not updating
As visible here [^]

when llSetLinkPrimitiveParamsFast is put inside a for loop to change a prims size to make a rolling effect the new size information is not transmitted to the viewer. Before recent master builds this worked flawlessly each time, now the shown behavior happens 70% of the time and only very rarely does the expected behavior(smooth scaling of the prim) occur.

As shown the only way to actively get the effect is by right clicking the prim in question, then updates about the prim size are sent.

I have tried different viewers and different network settings, three more people are reporting seeing the same thing.

This is on XEngine with ubODE on master
Create a prim and place a script inside that within a for loop changes the prim size: llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SIZE... based on the loop integer
blinds.lsl (2,328) 2019-11-02 14:47
controller.lsl (310) 2019-11-02 14:48
2019-11-02 14:45   
Tried to replicate this ...

Couldn't on osGrid .. [^]
2019-11-02 14:50   
Uploaded both scripts, Prim should have 100 as description and Path Cut set to: 0.1250 and 0.6250

I tested this on master code with Firestorm, Dayturn and Singularity, all showing the same, stock configs and all, so not many variables left that could be the reason. I suspect it is something with scene update throttles, but hard to say, wouldn't mantis this if I wasn't sure there was something being weird :)
2019-11-02 14:57   
just test that on Y
amasing how you expected that to work on X with stock settings..
2019-11-02 14:59   
Using your script, [^]

It is still setup , Outreach Test
2019-11-02 15:31   
Like I said, this works 1/3 of the time, then results are as the video I posted, then it fails again, works, fails, works. It's strange.

I also tried on different regions, empty ones, and can get it to work more reliably, which leads me to suspect throttles of some kind introduced in the last 6 months to be causing scene update pauses because too many are sent. Problem is nothing is reported by the region itself, neither in stats nor elsewhere.

So if there is overload how would I even determine where that comes from then? It's the symptom of something else.
2019-11-02 15:51   
So I changed the sleep from 0.05 to 0.1 and now it works on the loaded region, set it lower again, fails. Empty region has no change.

Loaded region has 80k prims, 1700 scripts, 600 eps, stable sim fps, no packet loss no overloads or errors, nothing out of the ordinary.
2019-11-02 19:17   
I confirm, there is a problem, I managed to reproduce the problem.
For me it happens if the object is not used for a moment (I do not know exactly after how long).
It also occurs if the simulator is restarted.

The problem disappears if I recompile the script.
Reset script has no effect, you must recompile.

Video demo: [^]
Script used: [^]

PS: no tested with osSetPrimitiveParams, tested only with llSetLinkPrimitiveParamsFast

I hope that can help a little.
2019-11-02 20:01   
(edited on: 2019-11-02 22:04)
Restarting the simulator systematically causes the bug.
Add llResetScript() on change event "CHANGED_REGION_START" DO NOT avoid the problem.

2019-11-05 21:08   
Interesting. Frankly under X the changed states have not been reliable at all so I am not surprised. The specific one of region_start indeed far as I know never actually worked.

I did test this initially just after a binary upgrade and reboot so assumed the script cache was empty and it would recompile anyways. I still think it may be partially related to some scene update throttle, but that it started working after I forced the recompile changing the sleep time might hint to your experience with it.

Either way I will have to test how Y behaves with the same script and maybe make it default now as Ubit suggests anyways. I merely reported it out of fear some recent new throttle may be set lower than it should have been :)
2019-11-05 21:51   
I have not yet tested with YEngine because I thought I heard that he had some limitations ...
After some research on Google and OpenSim wiki, I could not find a descent documentation for YEngine.
Maybe you know a good reference?

I also tested with CHANGED_REGION_RESTART but it does not improve anything.
Decreasing the number of loops or significantly increasing the increment does not improve the behavior of the script either.
The only thing that seems to work a little efficiently is to use touch_start in the main script and thus remove the button and listen. In this way, the script continues to work, even after restarting the region.
2019-11-13 06:33   
(edited on: 2019-11-13 11:17)
Got around to test the original script on YEngine today, both 0.05 and 0.1 for the sleep seem to work, but only after I recompiled the script, upon first compile aka region startup it did not update properly, however it was running.

On a possible related note. I been seeing prims rescale themselves when edited, say I made a prim and scaled it from 1x1x1 to 10x10x10 it would reset to 1x10x10 or 10x1x10. This normally hints to packet loss or overload, but not this time. I run "force update" on the region console and the prim scaled itself to the scale I set aka 10x10x10 and stuck there.

This is a recent observation that could hint at what I originally suspected the cause for this bug to be and that is something with how the viewer receives or handles updates or how the region sends them now. It leads me to think beyond this being potentially just a bug with how region start handles running up scripts it could also be affected by what amounts to a loss of sync between region and viewer.

There is something wrong with how updates are handled now whether this be server or client side I cannot say, but the relation to the "force update" command being the way to resolve it may hint at what's wrong. I can make a new ticket to track that part, but I think it is still related to this one.

Small update: Able to reproduce original reported behavior in both X and Y, prim not updating until right clicked on.

View Issue Details
8625 [opensim] [REGION] Scripting Engine major always 2019-11-08 12:30 2019-11-08 18:00 Intel i7 Win 7.0  
high 9.1.1 Yeti Dev  
Grid (Multiple Regions per Sim)
.NET / Windows64
Scripts not compiling ( nor working) after installing 9.1.1 for the 1st time ( prev 9.0 )
 After installing 9.1.1 Yeti Dev for the first time ( previously 9.0 ) -- myself and another Grid owner are seeing an identical error to [^] when compiling a script. Even after trying the recommendations from the two NOTES in 8081:
2019-11-07 17:28:10,441 ERROR [XEngine]: Failure in DoOnRezScriptQueue() for item 3236037a-f1cb-417a-aca4-702343e6739f in Winter. Continuing. Exception
System.FormatException: Input string was not in a correct format.
   at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
   at System.Convert.ToSingle(String value, IFormatProvider provider)
   at Nini.Config.ConfigBase.GetFloat(String key, Single defaultValue)
   at OpenSim.Region.ScriptEngine.Shared.Api.LSL_Api.LoadConfig() in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\Shared\Api\Implementation\LSL_Api.cs:line 333
   at OpenSim.Region.ScriptEngine.Shared.Api.LSL_Api.Initialize(IScriptEngine scriptEngine, SceneObjectPart host, TaskInventoryItem item) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\Shared\Api\Implementation\LSL_Api.cs:line 307
   at OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance.Load(IScript script, EventWaitHandle coopSleepHandle, String assemblyPath, String dataPath, StateSource stateSource, Boolean coopTermination) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\Shared\Instance\ScriptInstance.cs:line 304
   at OpenSim.Region.ScriptEngine.XEngine.XEngine.DoOnRezScript(Object[] parms) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\XEngine\XEngine.cs:line 1501
   at OpenSim.Region.ScriptEngine.XEngine.XEngine.DoOnRezScriptQueue(Object dummy) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\XEngine\XEngine.cs:line 1072
2019-11-08 12:38   
To elaborate -- the bug remained even after deleting the "ScriptEngines state" folder.
2019-11-08 12:56   
on opensim.ini check uncomented lines like
"MinTimerInterval = 0.1" or other float point number
if they show '.' as decimal separator, please test with ',' and let us know
if ',' is used, it should be '.'
2019-11-08 13:19   
keep in mind 0.9.1.x requires at least .net4.6 installed (4.8 should work now, 4.7.2 possible safer option) and at least VS2015 (2019 not tested by me ) to compile
2019-11-08 17:58   
Error caused by region's Opensim.ini, "MinTimerInterval=" ( set to nothing) setting it to 0.05 fixed it.
2019-11-08 17:59   

View Issue Details
8081 [opensim] [REGION] OpenSim Core major always 2016-12-05 01:04 2019-11-08 13:08
aiaustin PC  
Ferd Frederix Windows  
high 10  
resolved master (dev code)  
no change required  
none master (dev code)  
  master (dev code)
Grid (Multiple Regions per Sim)
.NET / Windows64
[XEngine] DoOnRezScriptQueue Could not load file or assembly
08:58:34 - [XEngine]: Failure in DoOnRezScriptQueue() for item 1416cae8-4f6e-490a-8347-4b5cb75b54a5 in Openvue. Continuing. Exception System.IO.FileLoadException: Could not load file or assembly 'file:///D:\VW\Openvue-ScriptEngines\bd09a791-eba5-11dc-95ff-0800200c9a66\CommonCompiler_compiled_b381ffbc-5462-430c-bdd4-b988c9b0c575.dll' [^] or one of its dependencies. The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)
File name: 'file:///D:\VW\Openvue-ScriptEngines\bd09a791-eba5-11dc-95ff-0800200c9a66\CommonCompiler_compiled_b381ffbc-5462-430c-bdd4-b988c9b0c575.dll' [^]
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Activator.CreateInstance(String assemblyString, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, Evidence securityInfo, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.AppDomain.CreateInstance(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at OpenSim.Region.ScriptEngine.XEngine.XEngine.DoOnRezScript(Object[] parms) in d:\Temp\opensim-0.9.0-929-g181b1ad\OpenSim\Region\ScriptEngine\XEngine\XEngine.cs:line 1367
   at OpenSim.Region.ScriptEngine.XEngine.XEngine.DoOnRezScriptQueue(Object dummy) in d:\Temp\opensim-0.9.0-929-g181b1ad\OpenSim\Region\ScriptEngine\XEngine\XEngine.cs:line 1062

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
Tried with an empty ScriptEngines folder too, and get the same error.
2016-12-05 01:24   
AppDomainLoading = false (the default) in the OpenSim.ini)

I tried one run with DeleteScriptsOnStartup = true and then restsarting with this set back to false.

That seems to have cleared the issue. So lets put this down to an untidy stop earlier.
2019-11-07 14:15   
(edited on: 2019-11-07 14:23)
Reopen to allow other reporters to add details.

Note that I have found I sometimes get these red errors on first run after bigger updates and sometimes deleting the ScriptEngines state folder clears this issue.

2019-11-07 18:21   
(edited on: 2019-11-07 18:23)
Although we are installed with 9.1.1 Yeti Dev -- myself and another Grid owner are seeing an identical error when compiling a script (after installing 9.1.1 for the first time).
Even after trying the recommendations from the two NOTES (above):

2019-11-07 17:28:10,441 ERROR [XEngine]: Failure in DoOnRezScriptQueue() for item 3236037a-f1cb-417a-aca4-702343e6739f in Winter. Continuing. Exception
System.FormatException: Input string was not in a correct format.
   at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
   at System.Convert.ToSingle(String value, IFormatProvider provider)
   at Nini.Config.ConfigBase.GetFloat(String key, Single defaultValue)
   at OpenSim.Region.ScriptEngine.Shared.Api.LSL_Api.LoadConfig() in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\Shared\Api\Implementation\LSL_Api.cs:line 333
   at OpenSim.Region.ScriptEngine.Shared.Api.LSL_Api.Initialize(IScriptEngine scriptEngine, SceneObjectPart host, TaskInventoryItem item) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\Shared\Api\Implementation\LSL_Api.cs:line 307
   at OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance.Load(IScript script, EventWaitHandle coopSleepHandle, String assemblyPath, String dataPath, StateSource stateSource, Boolean coopTermination) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\Shared\Instance\ScriptInstance.cs:line 304
   at OpenSim.Region.ScriptEngine.XEngine.XEngine.DoOnRezScript(Object[] parms) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\XEngine\XEngine.cs:line 1501
   at OpenSim.Region.ScriptEngine.XEngine.XEngine.DoOnRezScriptQueue(Object dummy) in O:\Opensim\Opensim Git Source\opensim\OpenSim\Region\ScriptEngine\XEngine\XEngine.cs:line 1072

2019-11-07 18:52   
(edited on: 2019-11-08 01:16)
On major updates you are supposed to delete scriptengines folder..
Other updates, it actually depends on what is changed, so delete to be safe.
And these 2 issues are unrelated.

2019-11-08 01:15   
(edited on: 2019-11-08 03:00)
Alan, as Ubit said, the error you are getting looks different to the "Could not load file or assembly '...\ScriptEngines\....dll' or one of its dependencies. The process cannot access the file because it is being used by another process".

Ferd Frederix   
2019-11-08 13:00   
MinTimerInterval is set incorrectly. Take look in your region file, and in Opensim.ini, for MinTimerInterval=0.2. It could be set to a 0,2 instead of 0.2. It could be in Opensim.proto, a Dreamgrid-specific file that gets made into This could be due to a foreign Culture (non-english), r just an old setting in the INI that needs to be fixed by hand.

Failing that, try setting the PC to US English.
Ferd Frederix   
2019-11-08 13:08   
Resolving due to a config error
Ferd Frederix   
2019-11-08 13:08   
Config error

View Issue Details
5844 [opensim] [REGION] Scripting Engine minor always 2012-01-08 15:04 2019-11-06 07:44
Standalone (Multiple Regions)
Mono / Windows
NULL key value in in statement does not evaluate as false.
The NULL key "00000000-0000-0000-0000-000000000000" should evaluate as FALSE inside a conditional. See [^]

Drop the following script into any prim and let it run.

===== CUT HERE ======
        key id = (key) NULL_KEY;
        if (id) {
            llSay(0, "Claims to be 'TRUE'. Value = " + (string) id);
        } else {
            llSay(0, "Claims to be 'FALSE'. Value = " + (string) id);
0001-Evaluate-if-key_var-as-false-when-the-key-key_var-ha.patch (974) 2018-08-20 08:01
2012-01-09 13:46   
Looking at the code, I've found so far the following snippet

================== CUT HERE ===============
namespace OpenSim.Region.ScriptEngine.Shared.CodeTools
    public class LSL2CSCodeTransformer
        private SYMBOL m_astRoot = null;
        private static Dictionary<string, string> m_datatypeLSL2OpenSim = null;

        /// <summary>
        /// Pass the new CodeTranformer an abstract syntax tree.
        /// </summary>
        /// <param name="astRoot">The root node of the AST.</param>
        public LSL2CSCodeTransformer(SYMBOL astRoot)
            m_astRoot = astRoot;

            // let's populate the dictionary
            if (null == m_datatypeLSL2OpenSim)
                m_datatypeLSL2OpenSim = new Dictionary<string, string>();
                m_datatypeLSL2OpenSim.Add("integer", "LSL_Types.LSLInteger");
                m_datatypeLSL2OpenSim.Add("float", "LSL_Types.LSLFloat");
                //m_datatypeLSL2OpenSim.Add("key", "LSL_Types.key"); // key doesn't seem to be used
                m_datatypeLSL2OpenSim.Add("key", "LSL_Types.LSLString");
                m_datatypeLSL2OpenSim.Add("string", "LSL_Types.LSLString");
                m_datatypeLSL2OpenSim.Add("vector", "LSL_Types.Vector3");
                m_datatypeLSL2OpenSim.Add("rotation", "LSL_Types.Quaternion");
                m_datatypeLSL2OpenSim.Add("list", "LSL_Types.list");
================== CUT HERE ===============

Un-commenting the line:

   //m_datatypeLSL2OpenSim.Add("key", "LSL_Types.key"); // key doesn't seem to be used

and commenting the line:

   m_datatypeLSL2OpenSim.Add("key", "LSL_Types.LSLString");

Causes the expected behavior for some trivial test scripts. However, for some non-trivial scripts, am getting parse errors. And the non-trivial scripts compile correctly with type "key" being considered as a synonym for "string" as is currently implemented.
2018-08-20 08:03   
(edited on: 2018-08-20 08:05)
I have attached a simple patch that fixes this problem. I don't expect it will have any adverse side effects but I suggest you try it for yourself.

NOTE: The patch can be applied to both the 0.8.2 and 0.9 code versions.

2018-08-20 13:45   
This has been this way forever the way it is normally used is ,

if(key == NULL_KEY)

or similar !=NULL_KEY

where this patch could cause issue is if you are checking for the presence of a key at all, but not sure ...
2018-08-20 14:05   
I'm wondering if this could break , osIsUUID(String thing) because it seems to me this would always substitute a valid key format even if it is NULL_KEY ?
2018-08-21 10:03   
This problem has existed for a long time as can be determined by the age of this bug report. I had someone ask me about this recently as they ran were bitten by the problem.

The patch won't change the behaviour of osIsUUID() as that is a function call.
2018-08-23 23:40   
That patch will actually break string to boolean compares.
string test=NULL_KEY;
if(test) llOwnerSay("string is non-empty");

The problem is that string to boolean has a different behavior than key to boolean.
To fix that kind of issue you have to separate the types.
2019-11-06 02:08   
Since YEngine fixes this problem, I don't think that potential XEngine script breakage is worth it.
2019-11-06 03:13   
Unless there is a concrete plan to completely drop XEngine in the next release fixing things should still be on the agenda, after all we still fix bugs in Bullet too.
2019-11-06 07:34   
Just wanted to note since this was being discussed, but it's not just NULL_KEY that is supposed to be considered invalid for key to boolean, but all invalid keys should return false, i.e- any that aren't exactly 36 characters of hexadecimal with four dashes in the correct places. One of the horrible sad realities of Linden Labs deciding that keys should be multi-byte strings in a memory constrained environment *shudders*.

For example, in LSL on SL you can do the following:

    key invalidKey = "foo bar";
    if (invalidKey) { llOwnerSay("Key is valid"); }
    else { llOwnerSay("Key is invalid"); }

i.e- storing invalid data in a key is fine, but it will fail a conditional check, which is how you can test for it when reading keys from a notecard, user input etc.

But if keys are handled purely as strings this isn't possible, as there's no such thing as an invalid string, meaning the test should be completely different for keys.
2019-11-06 07:44   
Yes it should, and is on Y now
but due the the key duality, that was never acheived on X, for a reason or another.
and try to fix one case, breaks others.

so as before, do explicit compares with NULL_KEY, etc
check for valid uuid usind osIsUUID(..)
use () to enforce your order of evaluation of things..

View Issue Details
8622 [opensim] [GRID] Other Service major always 2019-11-02 08:44 2019-11-05 21:33
Ravelli Ormstein PC  
tampa Windows  
normal 7 SP1 64-bit  
unable to reproduce  
Standalone (Multiple Regions)
.NET / Windows64
Firestorm 6.0.2 (56680)
Attachments getting lost after viewer relog
CPU: AMD Phenom(tm) II X6 1090T Processor (3199.99 MHz)
Memory: 8192 MB
OS Version: Microsoft Windows 7 SP1 64-bit (Build 7601)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: AMD Radeon HD 6800 Series

Windows Graphics Driver Version: 8.17.0010.1404
OpenGL Version: 4.2.13399 Compatibility Profile Context 15.200.1062.1003
2019-11-02 14:13   
with that size you should be using mySQL(or MariaDB).
2019-11-02 14:25   
if by any chance you are using FAT, you may be close to its max file size also...
2019-11-02 14:41   
Created a standAlone directly from release, using sqlite, loaded a 5k prims, tested attaching, relog, etc, and no issues :(
2019-11-05 21:04   
"(and switching to it wouldn't fix this issue)" what makes you say that? Can you reproduce the issue on a region running MariaDB?

Setting up MariaDB is quite easy on all systems now, you download their installer, install it, setup an account for OpenSim to use and create a db for your region. Not only will this be more stable and faster, it is also far easier to administrate and you can even do incremental backups rather than full backups each time(assuming you actually care to run backups).

While sqlite technically supports multi-terabyte data sizes even they don't recommend it. Their main use cases extend to smaller dbs that need to be accessed quickly or store settings, it runs into issues the way OpenSim needs to tie into the database rather quickly. If you are running on SSD or raid maybe it can work quite well, but north of 10gb or more even that won't work so well no more.

If you need help setting up MariaDB you can always ask for help on IRC: freenode #opensim or #opensim-dev
Ravelli Ormstein   
2019-11-05 21:31   
Please delete "instantly" all data stored about and by me on and any potential third party service.
2019-11-05 21:33   
Closing upon request

View Issue Details
8600 [opensim] [REGION] OpenSim Core minor always 2019-10-17 01:58 2019-11-04 11:11
aiaustin PC  
normal 10  
new master (dev code)  
  master (dev code)  
Dev Master (2019-10-16)
Grid (Multiple Regions per Sim)
.NET / Windows64
[LLCLIENTVIEW]: HandleMapItemRequest exception
When I click on the map to teleport to a position within a region I am on I see a red exception message in the OpenSim.exe console for that region. It occurs at the time of the click on the map.

ERROR [LLCLIENTVIEW]: HandleMapItemRequest exception: Input string was not in a correct format.

The teleport still works though.

This is on an OSGrid region updated to (almost) latest dev master. I don't see it on a region that is on the current OSGrid release (2019-08-07). Still investigating the circumstances this occurs in. Treat this as an initial report in case others are seeing the same issue and to establish if its been there a while or its introduced recently.
2019-10-17 02:10   
(edited on: 2019-10-17 02:11)
I confirm this error and I have already reported it on IRC a few days ago.
Tampa advised me to debug LLClientView.cs with the following line of code:

m_log.ErrorFormat("{0} {1} {2} {3} {4} {5}", LogHeader, mirpk.AgentData.Flags, mirpk.AgentData.EstateID, 
mirpk.AgentData.Godlike, mirpk.RequestData.ItemType, mirpk.RequestData.RegionHandle);

and here is the console message got:
11:03:22 - [LLCLIENTVIEW]: 2 0 False 2 0

if that can help a little ...

2019-11-02 20:47   
This also happens when the map is open with llMapDestination
2019-11-04 11:11   
Meanwhile I been getting reports that indicate map tiles in minimap not loading for adjacent regions, not sure if related, but somethings up with the map as of late. This instability was not there a few months ago.

View Issue Details
8513 [opensim] [REGION] OpenSim Core major always 2019-04-05 08:22 2019-11-01 03:03
none master (dev code)  
Grid (Multiple Regions per Sim)
.NET / Windows64
Teleport refused because failed to verify user presence
Teleport fails between two regions with error in console and viewer:

2019-04-05 10:13:53,091 DEBUG [ENTITY TRANSFER MODULE]: Teleport of Test User from Test Region 1 to Test Region 2 was refused because Failed to verify user presence in the grid for Test User, access denied to region Test Region 2.

The regions are setup to where they are not immediately next to each other like this: [Test Region 1] [Void] [Test Region 2]

Teleport works one time to either region and then every subsequent teleport attempt thereafter fails with the above message. The only way I have found to get around this is to relog and then teleport to the desired region; but after that it is back to square one with the error messages, relog to teleport, repeat.

Strangely this does not happen with two completely blank regions; I only started noticing this when I started building and putting stuff out on the second region and attempted to teleport back to the first region and it failed. Blanking the regions out lets me teleport back and forth fine again but as soon as I start putting stuff out again teleports start to fail in this fashion.

Currently I see this on OSGrid with my two region test setup. I have not yet tested this on a local grid.
2019-04-05 08:36   
This may be a specific osGRID issue due to the regular cleaning of the presence table.
2019-04-05 09:30   
Possibly... But does it get cleaned out on each relog? Because I can make this happen consistently: Login > Teleport > Try teleport back; fails. Relog, can teleport once, fails every time after; repeat.

I will test and see if it's an issue on local grid and post the results here later on when I get a chance.
2019-04-05 19:59   
(edited on: 2019-04-05 20:41)
After some testing on local grid (Not OSGrid) I can also trigger this issue. I ran git bisect and found a bad commit in which it started happening but I don't think it found the correct commit because compiling the commit before that still exhibited the issue. So I think the issue is not quite as consistent as I first thought it is. Will need to run bisect again and see if I can find a point where the bisect result makes more sense.

2019-04-05 23:09   
(edited on: 2019-04-05 23:33)
5 git bisect sessions later... I think I have come up with a commit that makes sense now at commit df14ed7d312e2f38e21912447835d9f078b97a95

I did some extensive testing on the commit just before that one and can't get the issue to trigger. So I feel more confident that the issue starts appearing at df14ed7d312e2f38e21912447835d9f078b97a95

Git Bisect Results:

$ git bisect bad
df14ed7d312e2f38e21912447835d9f078b97a95 is the first bad commit
commit df14ed7d312e2f38e21912447835d9f078b97a95
Author: UbitUmarov <>
Date: Mon Jan 14 18:39:16 2019 +0000

    more on TP

:040000 040000 487d8bfaa32227c005e9862f77e98f5c3491c7b7 38063a13dcbdaae3bf790a9ae167c2c56c614ab9 M OpenSim
:040000 040000 9caa783069181cfc0cdecac35ed085f548b14e09 0ae596f7081ba2d5aea0a1a4609e4d6c0fc9565b M bin

2019-04-06 02:13   
This is another one of those odd ones, as I'm running my whole grid on the new code, and nobody is getting this error ...

I'm sure it is a combination of things causing it, just don't know what the secret sauce is ..
2019-04-06 10:12   
I have noticed that if NPCs are involved, as in, the creation of them and removal of them before TPing back and forth, it seems to make this trigger more easily.
2019-04-06 10:28   
@mewtwo0641 Try the latest master Ubit has been working on that I think ...
2019-04-06 18:18   
I just gave master a try but the issue still persists
2019-04-08 04:43   
The only way I have found to trigger this is doing "Suicidal" TP's , if you let both the receiving and sending regions settle , it does not seem to happen.
2019-04-08 19:07   
I did some more testing on this but this time with a new database and still see the issue. A new thing that I have noticed is that any regions that decide that the user is no longer online will be invisible to the user even if they are directly adjacent to the region the user is in ([Region][Region] As opposed to my original setup of [Region][Void][Region]).

Some regions within the same OpenSim instance will still accept TPs and some won't and will be invisible to the user. The regions that do and do not appear to be at random. Whenever a user TPs to a region that is still accepting TPs from that user there's a flood of messages in the console listing off the regions that aren't accepting TPs that look like this:

[ENTITY TRANSFER MODULE]: Region (Region Name) did not accept (User Name) (User UUID): Failed to verify user presence in the grid for (User Name), access denied to region (Region Name)

This scenario is more obvious when there are more than a couple regions on the OpenSim instance (The one I tested this time had about 10 regions).
2019-04-09 04:04   
This seems improved now as of master (commit f29fdb6bdae51e50f749e2144a3e92fb3171f436) but will keep an eye on it before confirming fixed since it's a random occurrence.
2019-11-01 03:03   
Haven't seen this issue for a while. Seems fixed by master.

View Issue Details
8621 [opensim] [REGION] Scripting Engine major always 2019-10-30 08:29 2019-10-31 02:55
aiaustin PC  
normal 10  
new master (dev code)  
  master (dev code)  
Grid (Multiple Regions per Sim)
.NET / Windows64
Improvement of informaton provided for DEBUG [YEngine]: parsing errors
YEngine is stricter on script syntax than XEngine but usually shows good error messages indicating the position of object, script name and even (line,character) information about the problem.

But I am seeing this message without further elaboration of the object:script involved.

DEBUG [YEngine]: parsing errors on 9pL0qeW@pcYBjkQc11I1HbE0ArzcUGFCNJdvSu966l7

Can this message be enhanced to give similar object:script and location information if possible?
Most YEngine script issues give good diagnostics to openSim.log with position of object and (line,character) position of the problem. E.g. the following which makes tracking down the problem easier...

WARN [YEngine]: compile error on w6kZVnpmgf5glL@6uVJusruZkOO7WhhgL@h6Ddfjt6c (asset://49b6aa9f-5fa3-4d49-8248-1e29c249036c [^])

INFO [YEngine]: - <144.7625, 212.0385, 23.40209> ICS 02-AR48-Firefly:control

INFO [YEngine]: - (180,18) Error: Object reference not set to an instance of an object.

0001-Add-more-debugging-info.patch (1,033) 2019-10-30 15:09
2019-10-30 09:55   
Error in question is located in: \OpenSim\Region\ScriptEngine\YEngine\MMRScriptCompile.cs line 70ff

Seeing the context of that part implementing at least the script name might be possible quite easily. Just flying over this for more may need to pull in other references.

Line 86 orig: m_log.Debug ("[YEngine]: parsing errors on " + m_ScriptObjCodeKey);

Replaced with: m_log.Debug ("[YEngine]: parsing errors on " + m_ScriptObjCodeKey + " (" + m_CameFrom + ")");

Have not tested that yet though.
2019-10-30 11:26   
Yes YEngine error reporting needs more work, and there are messages a lot more criptic than that :)
2019-10-30 12:55   
(edited on: 2019-10-30 12:55)
Thanks Tampa. I may make a custom version to track down a few issues.

The region is usually obvious from the context, but the most useful thing is the object and script name (some objects may have a lot of scripts) and helpfully the position x,y,z info.

2019-10-30 15:10   
I added a small patch that seems to build fine with master, maybe it adds the info you are looking for... or it crashes, let me know how it goes :)
2019-10-31 02:10   
(edited on: 2019-10-31 02:36)
Thanks Tampa, good of you to provde that. I tried it and do get the asset://UUID. [^] DEBUG [YEngine]: parsing errors on 9pL0qeW@pcYBjkQc11I1HbE0ArzcUGFCNJdvSu966l7 (asset://af8260d6-e808-4b76-ac2f-091670f19084 [^]

But meanwhile I have traced this through my MySQL database. It is an asset type 10 : LSL-Text, which I guess we already knew and the name is "From IAR" which is a bit vague. But I see I can open the content "BLOB" in the Windows MySQL Editor :-) So I have the contents of the faulty script now and it includes this line...


        -.1.2 does not look like good LSL does it :-)

That will let me track it down. For normal users the objectname:script and x,y,z position as reported on other YEngine error and log messages would be the most useful.

As people get OpenSim now its out they may be encouraged to try YEngine to see how it goes, so others will have transition issues I would imagine. Good diagnostics at this stage might be wise.

2019-10-31 02:34   
Having the asset uuid is a good starting point though, that can be searched in the db just like you did.

From what I can gather the part that parses this has no clue which object the script is actually it, it just does parsing, adding information to the position and objectname thus may be a bit more complex.

The patch should probably make it into master, at least then there is some info to track down issues even if it means digging through mysql :)
2019-10-31 02:55   
That would be good. Thanks Tampa, I tracked down the glitch on my setup.

View Issue Details
8620 [opensim] [REGION] OpenSim Core minor always 2019-10-29 08:53 2019-10-29 13:43
piusnoel x86_64  
normal 18.04  
Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Mono / Linux64
Simulator hangs forever after <ctrl>-c on Linux
On the Metropolis grid regions are deregistred from the grid whenever the simulator has been shut down by issuing a shutdown or quit command at the OpenSim console. Especially on home based simulators this leads to conflicts, as grid coordinates and region names can be reused by others.

For this reason it's a well known practice to shutdown the simulator using <ctrl>-c from the OpenSim console. While this works well on Windows systems it seems to block the terminal window in Linux systems.

It doesn't matter whether <ctrl>-c has been pressed in the simulator console window or a SIGINT signal has been sent by issuing a "kill -2 <pid>" command from another terminal window.
1) Run the simulator
2) enter <ctrl>-c from the simulator console
Related to 0007743, where shutdown and quit were affected as well.
2019-10-29 09:00   
Did not yet test in detail, but I've seen this on both, Simulator/Region console and Robust as well.
2019-10-29 09:03   
Yes, we still have that issue on Mono.
cntrl-c and signals still bypass normal shutdown. Doing fast application shutdown

But doing that, Mono runtime still fails to stop some threads, it was suposed to (background threads), so it just hangs..
.net runtime code does not show that issue.
2019-10-29 09:25   
Yes, already tested, it only applies to Linux (I dont know about Mac).

Do you have any ideas how it could be improved?

I was thinking about a Console.CancelKeyPress event and stop threads from there or set a flag that can be ckecked.
2019-10-29 11:54   
For Metropolis or grids like that it would make more sense to either handle reservations for coordinates via a separate system or patch the deregistration out entirely, both can be easily done. That has nothing to do with the bug itself, but I felt like mentioning that the method described is kind of a hack and should be handled more gracefully(shutdown is there for a reason else you lose progress)
Ferd Frederix   
2019-10-29 13:40   
Ctrl-C can destroy or lose fresh objects, scripts, and other assets as the backup task only runs every 5 minutes. Be sure to type 'backup', and let it finish before slaughtering the sim. Ctrl-C can still kill assets as it is non-ACID. It's just a bad idea that should be avoided. See [^]
Opensim already has a way to hold a region persistent, so you can shut it down properly with quit. Just add it to the list as Region_Name=Persistent in Robust.ini, in section [GridService]. When the simulator is shutdown, the region is signalled as offline but left registered on the grid.

Another tip: double quotes are never needed in the INI files.
2019-10-29 13:43   
If you want quick kill on linux just kill it's pid, but I'd agree that it's a bad idea to quick kill a running simulator ..

Personally I'd like it better if Ctrl-C did NOTHING .. Just my .02

View Issue Details
8616 [opensim] [REGION] Script Functions minor always 2019-10-26 09:38 2019-10-29 12:27
djphil PC  
normal 10  
Grid (Multiple Regions per Sim)
.NET / Windows64
[SCRIPT FUNCTIONS] A bush of dataserver functions are not implemented or return no value
Source @ [^]
2019-10-28 09:04   
Which ones specifically?
2019-10-29 11:19   
Well, apart from the functions/constants related to "Experience", the following functions:

- llRequestInventoryData(string name);
- llRequestUserKey(string username);
- llRequestUsername(key id);
- llRequestDisplayName(key id);
2019-10-29 11:45   
DisplayName is probably not gonna happen, but InventoryData isn't implemented?
2019-10-29 12:27   
Well put a LM into a prim and try this: [^]

View Issue Details
7743 [opensim] [REGION] OpenSim Core minor always 2015-11-18 08:09 2019-10-29 08:56
Shy Robbiani vServer 64-bit/4 GB RAM on i7  
Shy Robbiani Debian Linux 8 Lennie  
normal 3.16.0-4-amd64  
resolved master (dev code)  
Standalone (1 Region) , Grid (1 Region per Sim)
Mono / Linux64
Simulator hangs forever in shutdown on Linux
After the message "16:03:03 - [SHUTDOWN]: Shutdown processing on main thread complete. Exiting..." or killing the simulator with <ctrl>-C the simulator hangs forever.

I could not restart the simulator before manually killing the process since a port was still in use.

The problem exists in both, grid mode connected to OSGrid and standalone.
I cannot reproduce this behavior in Windows/.NET.
1) Run the simulator
2) enter shutdown, quit or <ctrl>-C from the simulator console
Later this week I will give it a try in another Linux environment as OpenSim in this VM seems to be very unstable. I had several OpenSim crashes today. It's the first time I'm running OpenSim on this box so I'm not 100% sure whether it's my setup (latest stable Debian and Mono) or OpenSim that causes troubles.

Linux Kernel: SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux
Mono Version: Stable

On another machine with exactly the same Debian release I've seen other network applications not terminating properly.
OpenSim.log (32,980) 2017-04-08 10:20
2015-11-18 18:19   
Confirming the issue here. Stopping the instance with ctrl-c makes it hang and I then have to use kill. Running on an OpenVZ container but Opensim is normally quite stable for me.

CentOS 6
Opensim master/9c5acb3df4173259c414221590761d27fa3af0ed
2015-11-19 05:51   
(edited on: 2015-11-19 05:51)
I can't confirm a freeze on Windows .NET requiring manual termination of the process as observed in a Linux environment but I do see that whenever I attempt to shutdown OpenSim, once it reaches the "[SHUTDOWN]: Shutdown processing on main thread complete." point, it freezes for a few seconds, turns white, and eventually I get an error from Windows saying "OpenSim has stopped working" then it gives me the options to check for a solution online or close the program.

There's no stack trace that I can see either in the console window or in the OpenSim log file.

This is on Windows 7 x64 with .NET 4.0

Jak Daniels   
2015-11-19 05:59   
I can confirm this happens to me too on linux. I have to kill -9 the mono process after 'shutdown'.
I do also see one or more 'Timeout detected for thread' messages during the shutdown phase.

Centos 6
Opensim Master @ commit 0fbb4f0067dd6ebda28ba27686686c09de473f83
2015-11-19 07:49   
My development environment is on win 7, and I also can't repo this problem :(
2015-11-19 08:16   
(edited on: 2015-11-19 08:23)
Not seeing this issue.
We have a number of OpenSim Dev/Master instances running on Linux, standalone and grid (including robust) both Bullet and uODE physics. Linux kernels 3.x and 4.x. Mono 4+

Initial issues when updating using git pull resulted in a bin directory with conflicting libraries. We did not investigate this issue.

Fresh clones resolved these issues and various configurations (ini) migrated from the original instances.

We also run Windows instances on Server 2012, similar issues with git update, fresh clones resolved.

When building OpenSim by default we always include rebuild (Linux mono #rebuild /t:rebuild).

Jak Daniels   
2015-11-19 08:42   
(edited on: 2015-11-19 09:13)
I also started with a fresh git clone of master.

I also tried with and without any addon-modules like OpenSimSearch and OpenSimProfile

I built with:
./ autoclean && ./ vs2010 && xbuild /p:Configuration=Release;

OS is Centos 6 (kernel 2.6.32-573.8.1.el6.x86_64)
Mono is version Stable

Using default configs from master, but with the usual replacements from OSGrid.

After the shutdown sequence reaches
[SHUTDOWN]: Shutdown processing on main thread complete. Exiting...

Opensim hangs, and ps -eLf shows 56 threads still running.
Here is a list of their names if that helps:

ps H -C mono -o 'pid tid cmd comm'
17137 17137 mono OpenSim.exe -inimaster mono
17137 17138 mono OpenSim.exe -inimaster mono
17137 17139 mono OpenSim.exe -inimaster Finalizer
17137 17140 mono OpenSim.exe -inimaster STP:Util:0
17137 17141 mono OpenSim.exe -inimaster STP:Util:1
17137 17142 mono OpenSim.exe -inimaster STP:Util:2
17137 17143 mono OpenSim.exe -inimaster STP:Util:3
17137 17144 mono OpenSim.exe -inimaster STP:Util:4
17137 17145 mono OpenSim.exe -inimaster STP:Util:5
17137 17146 mono OpenSim.exe -inimaster STP:Util:6
17137 17147 mono OpenSim.exe -inimaster STP:Util:7
17137 17148 mono OpenSim.exe -inimaster STP:Util:8
17137 17149 mono OpenSim.exe -inimaster STP:Util:9
17137 17150 mono OpenSim.exe -inimaster STP:Util:10
17137 17151 mono OpenSim.exe -inimaster STP:Util:11
17137 17152 mono OpenSim.exe -inimaster STP:Util:12
17137 17153 mono OpenSim.exe -inimaster STP:Util:13
17137 17154 mono OpenSim.exe -inimaster STP:Util:14
17137 17155 mono OpenSim.exe -inimaster STP:Util:15
17137 17156 mono OpenSim.exe -inimaster STP:Util:16
17137 17157 mono OpenSim.exe -inimaster STP:Util:17
17137 17158 mono OpenSim.exe -inimaster STP:Util:18
17137 17159 mono OpenSim.exe -inimaster STP:Util:19
17137 17160 mono OpenSim.exe -inimaster STP:Util:20
17137 17161 mono OpenSim.exe -inimaster STP:Util:21
17137 17162 mono OpenSim.exe -inimaster STP:Util:22
17137 17163 mono OpenSim.exe -inimaster STP:Util:23
17137 17164 mono OpenSim.exe -inimaster STP:Util:24
17137 17165 mono OpenSim.exe -inimaster STP:Util:25
17137 17166 mono OpenSim.exe -inimaster STP:Util:26
17137 17167 mono OpenSim.exe -inimaster STP:Util:27
17137 17168 mono OpenSim.exe -inimaster STP:Util:28
17137 17169 mono OpenSim.exe -inimaster STP:Util:29
17137 17170 mono OpenSim.exe -inimaster STP:Util:30
17137 17171 mono OpenSim.exe -inimaster STP:Util:31
17137 17172 mono OpenSim.exe -inimaster Timer-Scheduler
17137 17179 mono OpenSim.exe -inimaster Non-blocking no
17137 17180 mono OpenSim.exe -inimaster STP:PoolService
17137 17181 mono OpenSim.exe -inimaster PollServiceWork
17137 17182 mono OpenSim.exe -inimaster PollServiceWork
17137 17183 mono OpenSim.exe -inimaster PollServiceWork
17137 17184 mono OpenSim.exe -inimaster PollServiceWatc
17137 17185 mono OpenSim.exe -inimaster STP:ScriptsHttp
17137 17186 mono OpenSim.exe -inimaster mono
17137 17187 mono OpenSim.exe -inimaster mono
17137 17188 mono OpenSim.exe -inimaster mono
17137 17189 mono OpenSim.exe -inimaster mono
17137 17194 mono OpenSim.exe -inimaster MapItemRequestT
17137 17195 mono OpenSim.exe -inimaster MapBlockSendThr
17137 17201 mono OpenSim.exe -inimaster MeshWorkerThrea
17137 17202 mono OpenSim.exe -inimaster MeshWorkerThrea
17137 17203 mono OpenSim.exe -inimaster TextureWorkerTh
17137 17204 mono OpenSim.exe -inimaster TextureWorkerTh
17137 17210 mono OpenSim.exe -inimaster STP:XEngine:0
17137 17211 mono OpenSim.exe -inimaster STP:XEngine:1

2015-11-19 16:58   
most of those threads are service ones that should be in wait state, and should die with no problems
but at least one is stuck somewhere...
Shy Robbiani   
2015-11-21 05:35   
It seems to be a problem with Mono 4.2. After I replaced Mono Stable with Mono Stable the problem disappeared.
2015-11-23 20:07   
I'm not sure if this is related or not but I happened to come across this exception upon my latest code pull and shutdown:

2015-11-23 22:04:18,488 ERROR (1) - OpenSim.OpenSimBase [SHUTDOWN]: Ignoring failure during shutdown -
System.MissingMethodException: Method not found: 'Boolean OpenSim.Framework.Servers.HttpServer.BaseHttpServer.RemoveAgentHandler(System.String, OpenSim.Framework.Servers.HttpServer.IHttpAgentHandler)'.
   at OpenSim.ApplicationPlugins.Rest.RestPlugin.RemoveAgentHandler(String agentName, IHttpAgentHandler handler)
   at OpenSim.ApplicationPlugins.Rest.Inventory.RestHandler.Close() in c:\Users\Admin\Desktop\ostest\opensim\OpenSim\ApplicationPlugins\Rest\Inventory\RestHandler.cs:line 347
   at OpenSim.ApplicationPlugins.Rest.RestPlugin.Dispose() in c:\Users\Admin\Desktop\ostest\opensim\OpenSim\ApplicationPlugins\Rest\RestPlugin.cs:line 370
   at OpenSim.OpenSimBase.ShutdownSpecific() in c:\Users\Admin\Desktop\ostest\opensim\OpenSim\Region\Application\OpenSimBase.cs:line 894
Shy Robbiani   
2015-11-24 09:28   
I closed this as it definitely seems to be an issue with Mono Stable After I switched to Mono Stable the problem disappeared.

Just one more note: after I switched to Mono Stable on Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) x86_64 GNU/Linux the problem disappeared but I experiences irregular crashes.

After stepping back to Mono 3.2.8 (Debian 3.2.8+dfsg-10) as it's included with the Debian distribution the system runs stable and all shutdowns terminate as expected.
slow putzo   
2015-11-26 07:58   
I wanted to update this mantis to say I also have this same issue running Fedore distro.

Release Notes

You are at 2573869.9, 2556494.5, 22.2 in Sanctuary located at (
OpenSim Dev OSgrid (Dev) 5e4b166: 2015-11-23 (Unix/Mono)
Mono JIT compiler version 4.2.1 (Stable Thu Nov 12 04:43:41 EST 2015)

The simulators appear to be running fine, but kind of a nuisance not to be able to use normal commands to shut them down.


They are running in a “screen” terminal window.


Here is the log of a shutdown immediately after launching a region.


2015-11-25 17:18:29,952 INFO (1) - OpenSim.Framework.Servers.ServerBase [SERVER BASE]: Running shutdown_commands.txt

2015-11-25 17:18:29,978 INFO (1) - OpenSim.Framework.Servers.ServerBase [SERVER BASE]: Running 'backup'

2015-11-25 17:18:33,925 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Closing all threads

2015-11-25 17:18:33,926 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Killing listener thread

2015-11-25 17:18:33,926 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Killing clients

2015-11-25 17:18:33,926 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Closing console and terminating

2015-11-25 17:18:33,927 INFO (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Closing down the single simulator: Sanctuary

2015-11-25 17:18:34,148 DEBUG (Maintenance (Sanctuary)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Maintenance (Sanctuary), ID 79

2015-11-25 17:18:34,428 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: TriggerSceneShuttingDown

2015-11-25 17:18:34,428 INFO (1) - OpenSim.Region.Framework.Scenes.EventManager [EVENT MANAGER]: TriggerSceneShuttingDown done

2015-11-25 17:18:34,429 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Persisting changed objects

2015-11-25 17:18:34,588 DEBUG (1) - OpenSim.Services.GridService.GridService [GRID SERVICE]: Deregistering region Sanctuary (3b15c050-1fe4-11df-8a39-0800200c9a66) at 10054-9986

2015-11-25 17:18:34,909 DEBUG (1) - OpenSim.OpenSimBase [SHUTDOWN]: Shutting down region Sanctuary

2015-11-25 17:18:35,678 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice]: region Sanctuary: uuid 3b15c050-1fe4-11df-8a39-0800200c9a66: located directory id 4439471

2015-11-25 17:18:35,773 DEBUG (Threadpool worker) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Heartbeat-(Sanctuary), ID 75

2015-11-25 17:18:35,774 ERROR (Threadpool worker) - OpenSim.OpenSim [WATCHDOG]: Timeout detected for thread "Heartbeat-(Sanctuary)". ThreadState=Stopped. Last tick was 1916ms ago.

2015-11-25 17:18:36,025 INFO (1) - OpenSim.Region.DataSnapshot.DataSnapshotManager [DATASNAPSHOT]: Region Sanctuary is being removed, removing from indexing

2015-11-25 17:18:36,031 INFO (1) - OpenSim.Region.ScriptEngine.XEngine.XEngine [XEngine]: Shutting down 487 scripts in Sanctuary

2015-11-25 17:18:36,208 INFO (1) - OpenSim.Region.ClientStack.LindenUDP.LLUDPServer [LLUDPSERVER]: Shutting down the LLUDP server for Sanctuary

2015-11-25 17:18:36,208 DEBUG (1) - OpenMetaverse.OpenSimUDPBase [UDPBASE]: Stopping outbound UDP loop

2015-11-25 17:18:36,209 DEBUG (1) - OpenMetaverse.OpenSimUDPBase [UDPBASE]: Stopping inbound UDP loop

2015-11-25 17:18:36,210 DEBUG (Outgoing Packets (Sanctuary)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Outgoing Packets (Sanctuary), ID 59

2015-11-25 17:18:36,223 DEBUG (1) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread InventoryWorkerThread0, ID 66

2015-11-25 17:18:36,223 DEBUG (1) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread InventoryWorkerThread1, ID 67

2015-11-25 17:18:36,231 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Dispose Physics

2015-11-25 17:18:36,234 DEBUG (bulletunmanaged (Sanctuary)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread bulletunmanaged (Sanctuary), ID 57

2015-11-25 17:18:36,246 DEBUG (Incoming Packets (Sanctuary)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Incoming Packets (Sanctuary), ID 58

2015-11-25 17:18:36,391 INFO (1) - OpenSim.Region.OptionalModules.Avatar.XmlRpcGroups.SimianGroupsServicesConnectorModule [SIMIAN-GROUPS-CONNECTOR]: Closing SimianGroupsServicesConnector

2015-11-25 17:18:36,392 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.XmlRpcGroups.XmlRpcGroupsServicesConnectorModule [XMLRPC-GROUPS-CONNECTOR]: Closing XmlRpcGroupsServicesConnector

2015-11-25 17:18:36,798 INFO (1) - OpenSim.Region.DataSnapshot.DataSnapshotManager [DATASNAPSHOT]: data service [^] notified. Secret: 38384e09-f875-4b31-a5a0-dccc4566ac1d

2015-11-25 17:18:36,801 INFO (1) - OpenSim.Framework.Servers.BaseOpenSimServer [SHUTDOWN]: Shutdown processing on main thread complete. Exiting...

I'm certainly not saying it is not a mono issue, but I have been on release 4.x.x ever since OSgrid came back online with no issues whatever.

OSgrid release of opensim OSgrid (Dev) 41b2855: 2015-10-21
Runs without any issues on this version of mono however
OSgrid (Dev) 5e4b166: 2015-11-23 fails with this issue

Obviously something has changed in opensim, and if that change is a legal change and does not violate some mono restriction or specification they yes mono is broken.

A developer of opensim who know "what" is broken should report this to mono so it can be fixed, and I hope they are doing that.

As a side note, the reason I moved up to newer releases of mono from the Fedora distros 2.8 version was at the suggestion of Nebandon who was running mono 4.0.x at the time and was not experiencing issues I was with the old 2.8 release of mono.

I have not detected any other issues other than is shutdown issue, so I am going to remain at mono 4.2.x and just use "kill" for now.

I think dropping back to a much older release of mono is a very poor resolution to a problem that was not present one month ago in opensim without a detailed explanation that it is indeed a mono issue and not just a "guess" that it is.

slow putzo   
2015-11-26 13:05   
More information on this bug.

To say windows with .net is working correctly is also false. It is indeed throwing an ERROR at shutdown and could well be what is causing mono to hang.

Here is a shutdown in windows using .net for the second to the last version of opensim for OSgrid, and the last version of opensim released for OSgrid.

You can clearly see there are no ERRORS in shutdown previously, and there is after the current release.

There is something wrong that was not wrong before in mono and in .net. The difference is that .NET still closes, and mono does not.

OSgrid (Dev) 41b2855: 2015-10-21

2015-11-26 15:46:32,310 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Closing all threads
2015-11-26 15:46:32,310 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Killing listener thread
2015-11-26 15:46:32,310 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Killing clients
2015-11-26 15:46:32,310 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Closing console and terminating
2015-11-26 15:46:32,310 INFO (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Closing down the single simulator: Development
2015-11-26 15:46:32,357 DEBUG (Heartbeat-(Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Heartbeat-(Development), ID 67
2015-11-26 15:46:32,420 DEBUG (Maintenance (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Maintenance (Development), ID 72
2015-11-26 15:46:32,826 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Persisting changed objects
2015-11-26 15:46:37,029 DEBUG (1) - OpenSim.Services.GridService.GridService [GRID SERVICE]: Deregistering region Development (570c1600-3516-11e4-8c21-0800200c9a66) at 10054-9986
2015-11-26 15:46:37,295 DEBUG (1) - OpenSim.OpenSimBase [SHUTDOWN]: Shutting down region Development
2015-11-26 15:46:37,310 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice] Sending request <> [^]
2015-11-26 15:46:37,466 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice]: region Development: uuid 570c1600-3516-11e4-8c21-0800200c9a66: located directory id 4443169
2015-11-26 15:46:37,482 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice] Sending request <> [^]
2015-11-26 15:46:37,576 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice] Sending request <> [^]
2015-11-26 15:46:37,717 INFO (1) - OpenSim.Region.DataSnapshot.DataSnapshotManager [DATASNAPSHOT]: Region Development is being removed, removing from indexing
2015-11-26 15:46:37,748 INFO (1) - OpenSim.Region.ScriptEngine.XEngine.XEngine [XEngine]: Shutting down 492 scripts in Development
2015-11-26 15:46:37,842 DEBUG (1) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread InventoryWorkerThread0, ID 58
2015-11-26 15:46:37,857 DEBUG (1) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread InventoryWorkerThread1, ID 59
2015-11-26 15:46:37,857 INFO (1) - OpenSim.Region.ClientStack.LindenUDP.LLUDPServer [LLUDPSERVER]: Shutting down the LLUDP server for Development
2015-11-26 15:46:37,857 DEBUG (1) - OpenMetaverse.OpenSimUDPBase [UDPBASE]: Stopping outbound UDP loop
2015-11-26 15:46:37,857 DEBUG (1) - OpenMetaverse.OpenSimUDPBase [UDPBASE]: Stopping inbound UDP loop
2015-11-26 15:46:37,904 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice] Sending request <> [^]
2015-11-26 15:46:37,967 DEBUG (Outgoing Packets (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Outgoing Packets (Development), ID 62
2015-11-26 15:46:37,967 DEBUG (Incoming Packets (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Incoming Packets (Development), ID 61
2015-11-26 15:46:37,982 DEBUG (bulletunmanaged (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread bulletunmanaged (Development), ID 57
2015-11-26 15:46:37,998 INFO (1) - OpenSim.Region.OptionalModules.Avatar.XmlRpcGroups.SimianGroupsServicesConnectorModule [SIMIAN-GROUPS-CONNECTOR]: Closing SimianGroupsServicesConnector
2015-11-26 15:46:37,998 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.XmlRpcGroups.XmlRpcGroupsServicesConnectorModule [XMLRPC-GROUPS-CONNECTOR]: Closing XmlRpcGroupsServicesConnector
2015-11-26 15:46:38,092 INFO (1) - OpenSim.Region.DataSnapshot.DataSnapshotManager [DATASNAPSHOT]: data service [^] notified. Secret: 24383411-9692-40df-b8f1-e22e2bb9aa45
2015-11-26 15:46:38,107 INFO (1) - OpenSim.Framework.Servers.BaseOpenSimServer [SHUTDOWN]: Shutdown processing on main thread complete. Exiting...

OSgrid (Dev) 5e4b166: 2015-11-23

2015-11-26 15:49:02,654 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Closing all threads
2015-11-26 15:49:02,654 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Killing listener thread
2015-11-26 15:49:02,654 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Killing clients
2015-11-26 15:49:02,654 INFO (1) - OpenSim.OpenSimBase [SHUTDOWN]: Closing console and terminating
2015-11-26 15:49:02,654 INFO (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Closing down the single simulator: Development
2015-11-26 15:49:03,170 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: TriggerSceneShuttingDown
2015-11-26 15:49:03,170 INFO (1) - OpenSim.Region.Framework.Scenes.EventManager [EVENT MANAGER]: TriggerSceneShuttingDown done
2015-11-26 15:49:03,170 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Persisting changed objects
2015-11-26 15:49:03,186 DEBUG (Maintenance (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Maintenance (Development), ID 77
2015-11-26 15:49:03,217 DEBUG (36) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Heartbeat-(Development), ID 72
2015-11-26 15:49:03,217 ERROR (36) - OpenSim.OpenSim [WATCHDOG]: Timeout detected for thread "Heartbeat-(Development)". ThreadState=Stopped. Last tick was 625ms ago.
2015-11-26 15:49:03,295 DEBUG (TouchAllSceneAssets) - OpenSim.Region.CoreModules.Asset.FlotsamAssetCache [FLOTSAM ASSET CACHE]: Could not find asset ce5301d9-0943-4ffa-891e-f8305b748897, type 0 referenced by object @-Heather Genie Dressing Booth at <48.14737, 75.16174, 22.52853> in scene Development when pre-caching all scene assets
2015-11-26 15:49:23,795 DEBUG (1) - OpenSim.Services.GridService.GridService [GRID SERVICE]: Deregistering region Development (570c1600-3516-11e4-8c21-0800200c9a66) at 10054-9986
2015-11-26 15:49:24,061 DEBUG (1) - OpenSim.OpenSimBase [SHUTDOWN]: Shutting down region Development
2015-11-26 15:49:24,280 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.Voice.VivoxVoice.VivoxVoiceModule [VivoxVoice]: region Development: uuid 570c1600-3516-11e4-8c21-0800200c9a66: located directory id 4443177
2015-11-26 15:49:24,686 INFO (1) - OpenSim.Region.DataSnapshot.DataSnapshotManager [DATASNAPSHOT]: Region Development is being removed, removing from indexing
2015-11-26 15:49:24,733 DEBUG (1) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread InventoryWorkerThread0, ID 64
2015-11-26 15:49:24,749 DEBUG (1) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread InventoryWorkerThread1, ID 65
2015-11-26 15:49:24,749 INFO (1) - OpenSim.Region.ScriptEngine.XEngine.XEngine [XEngine]: Shutting down 492 scripts in Development
2015-11-26 15:49:24,827 INFO (1) - OpenSim.Region.ClientStack.LindenUDP.LLUDPServer [LLUDPSERVER]: Shutting down the LLUDP server for Development
2015-11-26 15:49:24,827 DEBUG (1) - OpenMetaverse.OpenSimUDPBase [UDPBASE]: Stopping outbound UDP loop
2015-11-26 15:49:24,827 DEBUG (1) - OpenMetaverse.OpenSimUDPBase [UDPBASE]: Stopping inbound UDP loop
2015-11-26 15:49:24,842 DEBUG (MapItemRequestThread (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread MapItemRequestThread (Development), ID 58
2015-11-26 15:49:24,858 DEBUG (Outgoing Packets (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Outgoing Packets (Development), ID 68
2015-11-26 15:49:24,858 DEBUG (1) - OpenSim.Region.Framework.Scenes.Scene [SCENE]: Dispose Physics
2015-11-26 15:49:24,889 DEBUG (Incoming Packets (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread Incoming Packets (Development), ID 67
2015-11-26 15:49:24,952 DEBUG (bulletunmanaged (Development)) - OpenSim.Framework.Monitoring.Watchdog [WATCHDOG]: Removing thread bulletunmanaged (Development), ID 57
2015-11-26 15:49:25,014 INFO (1) - OpenSim.Region.OptionalModules.Avatar.XmlRpcGroups.SimianGroupsServicesConnectorModule [SIMIAN-GROUPS-CONNECTOR]: Closing SimianGroupsServicesConnector
2015-11-26 15:49:25,014 DEBUG (1) - OpenSim.Region.OptionalModules.Avatar.XmlRpcGroups.XmlRpcGroupsServicesConnectorModule [XMLRPC-GROUPS-CONNECTOR]: Closing XmlRpcGroupsServicesConnector
2015-11-26 15:49:25,093 INFO (1) - OpenSim.Region.DataSnapshot.DataSnapshotManager [DATASNAPSHOT]: data service [^] notified. Secret: d73bfc15-b3db-46b6-800c-d5d320185478
2015-11-26 15:49:25,108 INFO (1) - OpenSim.Framework.Servers.BaseOpenSimServer [SHUTDOWN]: Shutdown processing on main thread complete. Exiting...

As I said, I have no proof this is the mono problem, but there is something wrong and it sure is suspicious that it might well be what is causing mono to hang and not close.
2015-11-27 01:57   
(edited on: 2015-11-27 02:34)
I also see OpenSim.exe hanging when I "q" out of an idle simulator.. on Windows 10/.NET with latest today's and on a freshly created standalone, using default SQLite with a single region set up for tests on other issues.

I see one final [WATCHDOG] red timeout message and then the console hangs.. and I left it for 5 minutes before I forcibly terminated it.

09:54:45 - [Scene]: The avatar has left the building
Region (Vue) # q
09:55:01 - [SHUTDOWN]: Closing all threads
09:55:01 - [SHUTDOWN]: Killing listener thread
09:55:01 - [SHUTDOWN]: Killing clients
09:55:01 - [SHUTDOWN]: Closing console and terminating
09:55:01 - [SCENE]: Closing down the single simulator: Vue
09:55:01 - [SCENE]: TriggerSceneShuttingDown
09:55:01 - [EVENT MANAGER]: TriggerSceneShuttingDown done
09:55:01 - [SCENE]: Persisting changed objects
09:55:01 - [WATCHDOG]: Removing thread Maintenance (Vue), ID 37
09:55:03 - [WATCHDOG]: Removing thread Heartbeat-(Vue), ID 34
09:55:03 - [WATCHDOG]: Timeout detected for thread "Heartbeat-(Vue)". ThreadState=Stopped. Last tick was 2438ms ago.

Note added: I am now suspecting this was because the SQLite data base was still persisting the objects loaded in a previous OAR, as on SQLite this can take a long time. It was just not clear whether or not the console had hung, there is no warning that objects are not yet fully persisted***, and the watchdog timeout red error as the last thing showing led me to terminate the process after 5 minutes. However, when I restarted many objects that should have been in the region were missing.

After a load oar, I don't think an immediate backup and persist of the objects is done or confirmed to the console. It is necessary to manually do a backup on the console or wait for the objects to be persisted. This can take a long time on SQLite if a big load oar has been done. When I retested this the backup took over 15 minutes.. hence the hang on "q" initially.

*** maybe at some stage a suggestion for improvement in this area ought to be made as it can lead to serious loss of content and data base corruption.

2015-11-27 07:33   
removed some of the timeouts messages with ThreadState=Stopped, they where just missing notification of thread termination to watchdog, so no impact on the issue, so this was just cleanup :(
09:55:01 - [SCENE]: Persisting changed objects - is a synchronous operation.
2015-11-27 08:01   
I see quite a few extra debug messages generally Ubit.. some might just be temporary, but they are very volumous.. should they not be only coming out if debug levels are set higher than the default? E.g...

11:54:24 - [CompleteMovement]: WaitForUpdateAgent: 15ms
11:54:24 - [MakeRootAgent]: enter lock: 0ms
11:54:24 - [MakeRootAgent]: out lock: 0ms
11:54:24 - [MakeRootAgent]: Grouptitle: 16ms
11:54:24 - [MakeRootAgent]: TriggerSetRootAgentScene: 16ms
11:54:24 - [MakeRootAgent]: position and physical: 16ms
11:54:24 - [MakeRootAgent]: TriggerOnMakeRootAgent and done: 94ms
11:54:24 - [CompleteMovement]: MakeRootAgent: 125ms
11:54:24 - [CompleteMovement]: MoveAgentIntoRegion: 125ms
11:54:24 - [CompleteMovement]: ReleaseAgent: 125ms
11:54:24 - [CompleteMovement]: ValidateAndSendAppearanceAndAgentData: 140ms
11:54:24 - [CompleteMovement]: attachments: 140ms
11:54:24 - [CompleteMovement]: openChildAgents: 156ms
11:54:24 - [CompleteMovement]: SendInitialDataToMe: 156ms
11:54:24 - [CompleteMovement]: end: 156ms
slow putzo   
2015-11-27 12:50   
After a long day of walking the commit path here is what I discovered.

My impression is any commit that starts with opensim-0.6.9.rc1- fails to shutdown, or has compile errors which I did not even try to test.

The only test I did was try to do a shutdown.

It looks like the opensim-0.6.9.rc1- release had this bug in it from the very start. When another developer did a commit that did not start with opensim-0.6.9.rc1- that commit would compile fine, and would shutdown fine.

I thought opensim was at release 0.8.3 prior to going to 0.9.0
Then I have no idea how the commit stuff works as I have no knowledge in that area at all. I could not even find this old release because my archive only goes back to 2011 and there the release was osgrid.opensim-04072011.v0.7.1.abea0c7

Unfortunately it looks like release opensim-0.6.9.rc1- became release 0.9.0 so now that has this bug in it as well.

opensim-0.9.0-102-g9afe2b0 SHUTDOWN FAILS

2015-10-21 23:47 Diva Canto Fix an issue introduced in 70a46fe0907c822a5244e36 SHUTDOWN FAILS - opensim-0.6.9.rc1-15867
2015-10-21 23:47 Diva Canto Fix an issue introduced in 70a46fe0907c822a5244e36 SHUTS DOWN NORMALLY - 41B2855
2015-10-21 00:11 UbitUmarov fix or remove some wrong ODE configuration settin SHUTDOWN FAILS - opensim-0.6.9.rc1-15861
2015-10-20 14:37 UbitUmarov STATUS_ROTATE are linkset flags and not prim SHUTDOWN FAILS - opensim-0.6.9.rc1-15851
2015-10-20 01:12 UbitUmarov update ODE windows DLL libraries to a modified ver WILL NOT COMPILE - opensim-0.6.9.rc1-15850
2015-10-19 22:58 Melanie Thielker Let the initiator of a teleport or crossing know t SHUTS DOWN NORMALLY - 2B437F8
2015-09-06 20:46 UbitUmarov add lost admin_reset_land method SHUTDOWN FAILS - opensim-0.6.9.rc1-15616
2015-09-03 19:51 UbitUmarov fix a old bug i added: MaxWearables can't be chang SHUTDOWN FAILS - opensim-0.6.9.rc1-15596-g7bfa311
2015-09-03 19:22 UbitUmarov fix CM_api compile error COMPILE ERRORS - opensim-0.6.9.rc1- 15595
2015-09-03 17:50 UbitUmarov missing file COMPILE ERRORS -
2015-09-03 17:39 UbitUmarov at last we can login and see objects ( friends is COMPILE ERRORS - opensim-0.6.9.rc1-15592
2015-09-02 18:54 UbitUmarov seems to compile ( tests comented out) COMPILE ERRORS - opensim-0.6.9.rc1-15591
2015-09-01 16:20 Diva Canto Moved ExtendedPhysics from OptionalModules to Bull SHUTS DOWN NORMALLY - 0235E58
2015-09-01 13:54 UbitUmarov bad merge? COMPILE ERRORS - opensim-0.6.9.rc1-15590
2015-09-01 10:48 UbitUmarov remove lixo SHUTS DOWN NORMALLY - F811FDF
2015-09-01 10:43 UbitUmarov Merge remote-tracking branch 'os/master' SHUTS DOWN NORMALLY - FB78B18
2015-09-01 10:40 UbitUmarov lixo NOTHING IN THIS, JUST ONE FILE - 52F7991
2015-08-23 17:25 UbitUmarov fix db region find by range for varregions ( igno COMPILE ERRORS - opensim-0.6.9.rc1-13940
2015-08-18 22:59 UbitUmarov change pollService stop() to send 503 error and no COMPILE ERRORS - opensim-0.6.9.rc1-13898
2015-08-18 20:32 UbitUmarov do keepalive on mesh and texture GET. Dont use reu COMPILE ERRORS - opensim-0.6.9.rc1-13897
2015-08-18 20:03 UbitUmarov try to serialize http requests from same connectio COMPILE ERRORS, DOES NOT RUN - opensim-0.6.9.rc1-13896

Today I had to revert my regions back to the OSgrid 2015-10-23 version because my residents were driving me nuts with things that did not work and I could not deal with all the problems. Once I did the revert, the complaining stopped.
2015-11-27 14:09   
(edited on: 2015-11-28 09:36)
slow putzo... 0.8.3 was in use briefly for dev master after the 0.8.2 release was branched off. Some development of 0.8.3 dev master continued and those have opensim-####### (using the first characters of the full long Git commit code) style naming for viewgit downloads as used previously.

The 0.6.9.rc1 download moniker was a viewgit file naming issue from the avination code merge commits that had been developed over the last month or more on a separate branch. That viewgit download file naming issue was resolved by @Melanie, though all commits in place remain with the faulty file naming for downloads. Due to the large number of changes introduced by the avination code merge the devs chose then to switch the viewgit label to 0.9.0-nnn-g####### (nnn being a sequence number, note the "g" for git and then the first 7 hex characters of the commit code).

The actual code version change to report in code was done by @Diva and followed a few days later, so some viewgit downloads labelled as 0.9.0-nnn-g####### report their version number as

Since the avination code was worked on over the last month or more in parallel with the main dev master, there are commits done on the original code base that overlap in time with commits now merged in from the avination branch... so trying to separate out now the commits on a timeline basis will be very hard. When all the avination code was merged the commits have dates that interleave those original main branch commits. That's why you see some commits labelled for download as just in between those with the faulty 0.6.9.rc1 and more recently the 0.9.0 file formats.

I hope that helps a bit in unravelling where the faults were introduced.

slow putzo   
2015-11-27 15:03   
That does explain why some commits do work interspersed with those that don't. It would appear this problem was in the very first commit I could find that compiled without errors and was labeled opensim-0.6.9.rc1-xxxxx.
The very first commits with than faulty name would not compile clean for me, and in fact required me to over-ride the error message windows was giving saying the program was not "valid" or something like that. Most of those back in early August were like that.

I hope this helps in some small way. There isn't much else I know how to do in terms of helping find what this issue is.

I am keeping my home region at the current release levels, as "I" do not notice any other issues other than the shutdown problem which I can work around with the kill command.
On the positive side, I do have much better "tp" experience and border crossings are much smoother.

2015-09-03 19:51 UbitUmarov fix a old bug i added: MaxWearables can't be chang SHUTDOWN FAILS - opensim-0.6.9.rc1-15596-g7bfa311

Was the earliest commit I could find that didn't have compile errors and it immediately followed a commit that did have compile errors.

Everything before the code merge started worked fine for shutdown.

I know that isn't much help. I don't think this is something that was working and then got broke, but rather existed in the code that was being merged.
I only use the code releases OSgrid puts out for my region updates, and it is very seldom I ever use a git release unless it fixes something I was having a specific issue with.
2015-11-27 15:21   
It is clear to me that issue is on the merged branch.
Can be code imported from avination, where the issue never happened, like it doesn't happen to me and others,
or it can be a bad git merge effect lost somewhere..
or even something I did messed up on this process...
slow putzo   
2015-11-27 15:28   
If there is anything I can do to assist in finding what the problem is, I will be happy to help. I'm not a programmer, but have a little experience now with at least testing to see if it fails or not. The problem is absolutely repeatable for me every time.
slow putzo   
2015-11-27 16:23   
UbitUmarov, I just compiled the latest commit you made after several of your commits today and it now shuts down correctly for me.
This is the latest commit that I just compiled and tested:
 2015-11-27 23:46 UbitUmarov remove terrain height clamping left over the ushor master SHUTS DOWN NORMALLY -
The previous one I tested was:
2015-11-26 16:29 Melanie Thielker Mantis 0007765: Add new ClampNegativeZ option. Defau SHUTDOWN FAILS
I am logged in on my region and so far everything appears as it should be.

If you want me to walk through the several commits to see which one fixed it, I will be happy to do that and report it back here. Maybe you already know what fixed it.
2015-11-27 16:28   
this can also be random :(
but I did a few changes on some threads control.
2015-11-27 16:39   
Just tried the latest commit as well and both shutdown command and ctrl-c are working normally with it.
slow putzo   
2015-11-27 16:47   
ok, I will find when it started to work for sure, so you will know if it becomes random for me or if it indeed is fixed. I did just find another failure and confirmed that it does not work in V0.9.0 but it has nothing to do with this problem.
2015-11-27 16:49   
and let us know that other failure
2015-11-27 16:59   
Poked around some and found "f16d36627f949a3568fea09dddcb76c9f8d823e6 - change threading on GetTexture and GetMesh NonSharable region modules" is where the problem got fixed.
2015-11-27 17:00   
thx :)
slow putzo   
2015-11-27 17:01   
see: [^]
For the other problem
2015-11-28 01:21   
(edited on: 2015-11-28 01:24)
Just a note for Ubit and others, as I see some work going on in the area of FetchInventoryDesc and pending event handling. iN the past we have had issues with some pending inventory fetch events never getting handled, or timing out after a very long time even after logoff, especially on OSGrid. This is an area we have had major grief with over the years. In one case inventory fetch hangs took nearly two years to pin down in work between JustinCC, Mata, myself and others. It was a totally major thing for some people with more complex setups. It got fixed, but it was one of those fine timing things. Please don't mess with thread timing, pending event completion assumptions, or thread count expansion without thinking if its necessary, and then thinking again, and again,.. before a change is made. Ai (grief avoidance officer) :-)

slow putzo   
2015-12-11 16:49   
This problem has returned in the OSgrid (Dev) 7d8b783: 2015-12-05 release of opensim distributed by OSgrid.

The failure is identical. I had stopped using git versions because the one problem I am having with a very complex script is so difficult to try and explain I decoded to wait for the OSgrid releases and see if they fixed that problem.

This shutdown problem does not happen on my windows instance, but it does give the "red timeout error" when shutting down.

I do not know if the two are actually linked.

2015-12-11 19:17:27,448 ERROR (82) - OpenSim.OpenSim [WATCHDOG]: Timeout detected for thread "MapBlockSendThread (Development)". ThreadState=Stopped. Last tick was 3011000ms ago.
2015-12-19 15:19   
I still compile from git, have never actually run the OSGrid download itself. Currently on version e095f51b05f980474cf8a43594025a46ee6fa0cf and I have not encountered the problem yet. I went back and compiled for the 12-5-15 OSGrid version and did not have the issue return there either.
slow putzo   
2015-12-21 19:54   
I just ran the latest GIT (opensim-0.9.0-216-g6437a94) as of today, and ran it on my test region. Using both physics engines the shutdown worked just fine.

There is a rather big difference in how fast the region comes online between the two physics engines.

 This is a nearly empty region with only 4 objects on it. All of these objects are currently undergoing mantis scripting bug fixes.
2015-12-22 03:20   
with only 4 objects there should not be a big difference..
But both Ode and ubOde now may seem to delay the startup.
Reason is that now there is a initialization step where objects physics model is built. So when main loop starts moving objects, they are really ready for it.
Some large meshs (that should be avoid on physics) can take sometime to build the physics model
You can see that step in the log just before start of heartbeat
The shutdown issue is strange, because there where no changes on the code areas we found before being the cause
Robert Adams   
2015-12-27 21:31   
Another data point: if I start up my OSGrid BulletSim regions (on Ubuntu 14.04, Mono JIT 3.2.8), if I immediately try to shut the simulator down with a 'q' on the console, the log gets down to the last SHUTDOWN message but never exits -- it sits forever and a kill is required.

If, on the other hand, I start the region and wait for the hypergrid friend messages to complete, the simulator shuts down with no problem. The hypergrid friend presence posting takes a while (minutes) as some of my friends are from grids that don't exist so there is a long DNS timeout trying to get the grid DNS address failure.

It looks like the friend presence posting threads can keep the simulator from shutting down.
slow putzo   
2017-04-08 09:49   
After holding off doing any updates of my operating system, with Fedora 22 now past end of life, I updated to Fedora 25 by going through an update from release 22, 23, 24, to the current release of 25. This problem returned immediately as I updated from release 22 to release 23. I did not track the versions of mono during the updates until I reached the final goal of getting to release Fedora 25.

I am testing on a different computer than my production regions are running on which are still running Fedora release 22 and do not have this issue.

I am attaching the log file to the initial start of a fresh copy of opensim with a blank database running ubODE and it is a 4 by 4 VAR instance. It is the only thing running on the Fedora 25 machine. I entered the "quit" command and it went to the final shutdown step and hangs. This is exactly what it was doing before.
I am attempting to get the current release of both Linux and mono to report here.

opensim release: OSgrid (Dev) 4499355: 2017-04-01
Linux: Fedora 25 Kernel Linux 4.10.8-200.fc25.x86_64 x86_64
mono: 4.8.0 (Stable 4.8.0520/8f6d0f6 Wed Mar 15 10:51:49 UTC 2017)

I am trying to figure out how to include the log file and it appears I need to finish this note first.
slow putzo   
2017-04-08 10:06   
I was able to attach the opensim.log file to this mantis report.

I notice a very strange thing about the log file.
version: OpenSim Dev OSgrid (Dev) 0170696: 2016-11-26

That date is not what is in the .version file in the "bin" directory. It has this information in it: OSgrid (Dev) 4499355: 2017-04-01

The ZIP file name this release came out of is:

I am running the singularity viewer and am able to go to the region and while it is just the bump in the ocean with zero prims and scripts I can fly around just fine and all appears to be ok.

It just will not shut down correctly and you have to use the "kill" command so you can get rid of the open port to restart it.

I hope even though this is a very old mantis this problem can be once again reviewed. Someone just starting to use opensim and using Linux with the current mono is not going to understand why they would need to go back to an ancient release to get opensim to function correctly at shutdown.

My servers that DO shutdown correctly using this same confusing version of opensim put out by OSgrid are running:
Fedora 22
Mono 4.2.3 (Stable Tue Mar 15 11:39:53 EDT 2016)

I say confusing because the information in the log file does not match what the release is suppose to be or what is in the .version file in the bin directory.
2017-04-08 10:17   
I have this problem on any mono newer than 4.0.4 If you want to install mono 4.0.4 yourself you can use my instructions, if you get stuck just let me know some newer mono has problem with compiling the older mono, but i have a work around for this that I have not documented yet. [^]
slow putzo   
2017-04-08 10:29   
Please ignore the "confusion" statement. I noticed after posting the log file that it was a log file of several restarts and was not a log of a single fresh restart. I deleted that log file and replaced it with the single "fresh restart" section.

Nebadon, I will try to fall back to version 4.2.3 since it is running fine on my other three servers. I'll post if that does work.

Not sure using old versions of mono is the best idea given they apparently do not believe this problem is a mono issue unless no opensim dev has ever reported it to the mono devs.
2017-04-08 10:31   
I believe at some point it was reported, but generally Mono devs need a example code that repeats the problem reliably, and Opensimulator is far to complicated for them to easily debug the problem with.
2017-04-08 10:32   
Also from my testing there is virtually no performance improvement between mono 4.0.4 and the very latest git master head version of mono, if there is any it is very minimal.
slow putzo   
2017-04-08 10:43   

Since I am able to shutdown a region using the web site interface is there even a reason I care if the quit command does not exit?
I normally do my nightly reboots without doing anything to shutdown the regions, I simply reboot the server and let it bring everything back online at 4 am every night. The only time I have ever needed to do a quit was if I wanted to move the region or make some kind of name change etc. The function in the web interface gives me that ability I believe. As far as OSgrid is concerned the quit probably did complete and the only extra step I need might only be to kill the task in my server on such occasions.
2017-04-08 10:44   
I have regions running on 4.0.4 that have been up for 500+ days without a restart :)
slow putzo   
2017-04-08 10:52   
You are blessed. In Florida I would be happy if we could keep the power on for 500+ days let alone our phones running and Internet access working for even 180+ days at a time.

I think we do a doomsday exercise ever few month here with extended outages of one or more utilities.
2017-04-09 13:34   
@nebadon The main reason to upgrade to newer mono is for potential reduction in the obvious memory leak OpenSim has. After 18 days I had a region consume nearly 10GB of memory when inworld osGetPhysicalMemory only reported 2GB of memory used. I have the hope that newer versions of mono will somewhat reduce this problem hence why I upgraded in the first place. The shutdown problem is a bit of an inconvenience, but nothing that can't be kill -9 'ed. Still should probably put a line in there to make sure it exits properly. Most distros won't stay on 4.0 forever, once they switch to newer versions the reports will come flooding in.
2017-04-30 08:33   
(edited on: 2017-04-30 08:48)
After much searching in the googleverse, it seems a lot of mono developers are having issues with Environment.Exit, most are replacing it with alternative functions ..

Now for my purposes, I have replaced all instances of Environment.Exit, in ServicesServerBase.cs and BaseOpenSimServer.cs with System.Diagnostics.Process.GetCurrentProcess().Kill(); , now you tend to loose the ability to catch shutdown exceptions, but at this point I just want a clean shutdown and not a hang ...

And the instance still appears to finish all shutdown steps, it does not just die .. It dies at the end of shutting down the final thread .

2017-04-30 13:50   
Just tried that and shutdown works properly now. Probably not the actual way to do this in newer mono, but I haven't been able to find a proper fix for this either. Seems like a common issue with mono, but most just mention this to fix it. It shouldn't really matter much since it's pretty much the last step in the shutdown, but it's not issuing the same shutdown message as before so that might be an issue if that is used elsewhere.
2017-04-30 14:29   
tampa, yeah I am sure someone may have a better "fix" but from what I have found there are lots of issues with "hangs" with Environment.Exit, in the mono world ..
2017-05-22 18:12   
(edited on: 2017-05-23 03:40)
Adding some information about this... [^]

Mono JIT compiler version 4.6.2 (Stable Mon Nov 21 12:08:40 UTC 2016)

On this version of mono, one can enter the /proc/pid/task entry for the application and see separate pid for the hanging threads. Killing any of these allows the application to exit.

2017-05-23 16:39   
still hanging after update to 07e614a32c79b9295b162119d95ab1770243a8cc

Run in debugger - pause application execution manually after hangup and find the program looping here.. [^]

Call stack...
System.Threading.Monitor.Monitor_wait() in
System.Threading.Monitor.ObjWait(bool exitContext, int millisecondsTimeout, object obj) in
System.Threading.Monitor.Wait(object obj, int millisecondsTimeout, bool exitContext) in
System.Threading.Monitor.Wait(object obj, int millisecondsTimeout) in
OpenSim.Framework.BlockingQueue<OpenSim.Framework.Servers.HttpServer.PollServiceHttpRequest>.Dequeue(int msTimeout) in /team/staging/opensim/OpenSim/Framework/BlockingQueue.cs:81
OpenSim.Framework.Servers.HttpServer.PollServiceRequestManager.PoolWorkerJob() in /team/staging/opensim/OpenSim/Framework/Servers/HttpServer/PollServiceRequestManager.cs:235
System.Threading.ThreadHelper.ThreadStart_Context(System.Threading.ThreadHelper state) in
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Threading.ThreadHelper state, bool preserveSyncCtx) in
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Threading.ThreadHelper state, bool preserveSyncCtx) in
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Threading.ThreadHelper state) in
System.Threading.ThreadHelper.ThreadStart() in
2017-05-23 17:15   
that is a wait with a timeout of 5s
and now code does issue a abort to those threads
2017-05-23 17:16   
and by default it is background thread.. ie a non blocking one on exit
2017-05-23 17:44   
this is now the log output on windows shutdown:
the thread you seen above is one of the 3 PollServiceWorkerThread
note that most of this threads are background ones, we should not need to kill them (on hard quit at least)

2017-05-24 01:39:04,309 DEBUG [WATCHDOG]: Removing thread MapBlockSendThread (ubittest11), ID 41
2017-05-24 01:39:04,379 DEBUG [GetMeshModule] Closing
2017-05-24 01:39:04,399 DEBUG [WATCHDOG]: Removing thread GetMeshWorker0, ID 43
2017-05-24 01:39:04,414 DEBUG [WATCHDOG]: Removing thread GetMeshWorker1, ID 44
2017-05-24 01:39:04,414 DEBUG [GetTextureModule] Closing
2017-05-24 01:39:04,429 DEBUG [WATCHDOG]: Removing thread GetTextureWorker0, ID 45
2017-05-24 01:39:04,454 DEBUG [WATCHDOG]: Removing thread GetTextureWorker1, ID 46
2017-05-24 01:39:04,454 DEBUG [WebFetchInvDescModule] Closing
2017-05-24 01:39:04,469 DEBUG [WATCHDOG]: Removing thread InventoryWorkerThread0, ID 17
2017-05-24 01:39:04,484 DEBUG [WATCHDOG]: Removing thread InventoryWorkerThread1, ID 47
2017-05-24 01:39:04,484 INFO [LLUDPSERVER]: Shutting down the LLUDP server for ubittest13
2017-05-24 01:39:04,484 DEBUG [UDPBASE]: Stopping outbound UDP loop
2017-05-24 01:39:04,484 DEBUG [UDPBASE]: Stopping inbound UDP loop
2017-05-24 01:39:04,484 DEBUG [JobEngine] Stopping Incoming Packet Async Handling Engine (ubittest13)
2017-05-24 01:39:04,509 DEBUG [JobEngine] Stopping Outgoing Queue Refill Engine (ubittest13)
2017-05-24 01:39:04,529 DEBUG [WATCHDOG]: Removing thread MapItemRequestThread (ubittest13), ID 53
2017-05-24 01:39:04,534 DEBUG [JobEngine] Stopping HG Incoming Scene Object Engine (ubittest13)
2017-05-24 01:39:04,554 DEBUG [WATCHDOG]: Removing thread Outgoing Packets (ubittest13), ID 57
2017-05-24 01:39:04,579 INFO [XEngine]: Shutting down 96 scripts in ubittest13
2017-05-24 01:39:04,639 DEBUG [SCENE]: Dispose Physics
2017-05-24 01:39:04,724 DEBUG [WATCHDOG]: Removing thread Incoming Packets (ubittest13), ID 56
2017-05-24 01:39:04,744 DEBUG [JobEngine] Stopping ServiceThrottle
2017-05-24 01:39:05,174 DEBUG [WATCHDOG]: Removing thread PollServiceWorkerThread 0:9000, ID 21
2017-05-24 01:39:05,189 DEBUG [WATCHDOG]: Removing thread PollServiceWorkerThread 1:9000, ID 22
2017-05-24 01:39:06,824 DEBUG [WATCHDOG]: Removing thread PollServiceWatcherThread:9000, ID 23
2017-05-24 01:39:06,824 DEBUG [WATCHDOG]: Removing thread MapBlockSendThread (ubittest13), ID 54
2017-05-24 01:39:10,699 DEBUG [JobEngine] Stopping Non-blocking non-critical job engine
2017-05-24 01:39:10,719 INFO [SHUTDOWN]: Shutdown processing on main thread complete. Exiting...
2017-05-24 09:03   
8989e8ef Does complete the shutdown process on standalone. But, both Robust and OpenSim still hang on exit.
2017-05-24 22:20   
Did some changes, and now I do see shutdown work on more cases with mono 5.0
Possible still needs more work.

Thanks Bill Blight for setting up a Ubuntu VM just for me to test this issue
2017-05-25 05:48   

OpenSim has nice clean shutdown,

Robust does shut down, but leaves this behind...

08:20:48 - [CONSOLE]: Quitting

Unhandled Exception:
System.NullReferenceException: Object reference not set to an instance of an object
  at OpenSim.Framework.Monitoring.JobEngine.Stop () [0x00099] in /team/staging/opensim/OpenSim/Framework/Monitoring/JobEngine.cs:144
  at OpenSim.Framework.Monitoring.WorkManager.Stop () [0x00001] in /team/staging/opensim/OpenSim/Framework/Monitoring/WorkManager.cs:87
  at OpenSim.Server.Base.ServicesServerBase.Run () [0x00050] in /team/staging/opensim/OpenSim/Server/Base/ServicesServerBase.cs:255
  at OpenSim.Server.OpenSimServer.Main (System.String[] args) [0x00330] in /team/staging/opensim/OpenSim/Server/ServerMain.cs:163
[ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException: Object reference not set to an instance of an object
  at OpenSim.Framework.Monitoring.JobEngine.Stop () [0x00099] in /team/staging/opensim/OpenSim/Framework/Monitoring/JobEngine.cs:144
  at OpenSim.Framework.Monitoring.WorkManager.Stop () [0x00001] in /team/staging/opensim/OpenSim/Framework/Monitoring/WorkManager.cs:87
  at OpenSim.Server.Base.ServicesServerBase.Run () [0x00050] in /team/staging/opensim/OpenSim/Server/Base/ServicesServerBase.cs:255
  at OpenSim.Server.OpenSimServer.Main (System.String[] args) [0x00330] in /team/staging/opensim/OpenSim/Server/ServerMain.cs:163
2017-05-25 07:20   
Shuts down fine on regions as above, but now seeing this error

10:16:00 - Timeout in threadfunc 1 (STP:Util:49)
10:16:00 - Timeout in threadfunc 2 (STP:Util:21)
10:16:00 - Timeout in threadfunc 3 (STP:Util:24)
10:16:00 - Timeout in threadfunc 4 (STP:Util:45)

The last number is usually different .. Not sure if it is related to the shutdown or not, this error is actually on startup, and occasionally. But just in this latest build.

(And you are very welcome for the server, have fun with it)
2017-05-25 17:08   
I did fix those timeouts.. on my box.. missed the file on commit to master :)
Marcus Llewellyn   
2017-05-26 09:56   
I can confirm clean shutdowns now.

Mono JIT compiler version 5.0.0 (Stable Tue May 23 12:12:24 CDT 2017)

Compiled from commit 8f10db0a6a4831cded816e6d08b09fe0e47c77b4

Ubuntu 17.04 x86_64 Linux 4.10.0-21-generic
2017-05-26 15:02   
Compile as Release does help a bit on all aspects

Just if something goes wrong, there is less information to debug it
slow putzo   
2017-07-01 13:16   
(edited on: 2017-07-01 13:18)
Confirm Fedora 25 with:
Mono JIT compiler version 4.4.2 (Stable Tue Aug 2 08:14:37 UTC 2016)

Mono JIT compiler version (2017-02/5077205 Wed May 24 13:16:08 UTC 2017)

Clean shutdown.

Shy Robbiani   
2019-10-29 08:10   
I'm going to set this on resolved/fixed now, as shutdown and quit commands on Linux servers worked well for quite a long time.

Current Ubuntu LTS servers with Mono 5.n/6.n still keep hanging after a SIGINT signal has been received either by pressing <ctrl>-C in the OpenSim console window or by issuing a "kill -2 <pid>" command from a terminal window.

However, even related, this should be treated as a separate issue. Pius Noel will take a closer look into this and probably file a new report in a few days.

View Issue Details
8618 [opensim] [REGION] Script Functions feature always 2019-10-26 13:34 2019-10-28 13:59
Kayaker Magic All  
Master Snail Dev  
normal 0.9.1  
Grid (1 Region per Sim)
New OSSL function to return permission test for named function
Patch file to implement this is attached.
This is the minimalist way I can find to add an OSSL function that can tell a script if it is allowed to call an OSSL function by name.
If OSSL functions are disabled, it quietly returns 0 (false).
It uses the internal private function CheckThreatLevelTest to see if a function is allowed by the [OSSL] section in the INI files and returns 1 (true) if allowed, 0 (false) if not.
If a function does not have an Allow line in the INI files, this function returns FALSE(0) because no OSSL function may know the threat level of another function. This may be a false negative but is acceptable since nobody is going to call this new function to check permission on the innocuous functions like osApproxEquals, etc.
integer osPermissionToCall(string function)
Returns 0 (false) if you may not call the named OSSL function
Returns 1 (true) if you can call the named function
Threat Level This function does not do a threat level check
Permission Use of this function is always allowed by default
Delay 0 seconds
Quietly returns 0 (false) if all OSSL functions are disabled
        if (osPermissionToCall(“osGetGridName”))
            llOwnerSay(“You are on grid “+osGetGridName());
            llOwnersSay(“I can't tell what grid you are on”);
osPTC.patch (3,392) 2019-10-26 13:34
2019-10-28 09:03   
What would one do with that information? Most os functions specifically extend ll functions or provide completely new functionality not easily obtained by ll functions. Granted the error is somewhat intrusive when it happens, but that's easily solved by proper permissions set in the ini and restarting a region, which you otherwise have to do anyways to resolve it ultimately, so I don't see what this function would add that isn't already present.
Kayaker Magic   
2019-10-28 13:59   
What would we do with that information? Write professional LSL scripts that check some functions before calling them when they would generate error messages. Most people who run LSL scripts are users or visitors to regions. These users do not have the ability to “solve” problems by editing the ini files and restarting the regions they visit. As a programmer who writes code for these users, I want to write scripts that detect errors before they happen and give polite, easy to understand reasons why my code cannot work here now. Or to use alternate ways to get a similar result. This function will give people like me the ability to do that.

View Issue Details
8619 [opensim] [REGION] OpenSim Core minor always 2019-10-26 13:51 2019-10-28 09:20
Standalone (Multiple Regions)
Mono / Windows
viewer's crash on simcrossing
viewer's crash on simcrossing not sure what is going on but i have some logs

even if console sey simcros failed account will still be online for 1/2 minit's and flay and edit like noting is wrong. after 1/2 minit's viewer crash

crash never happend before sins yesterday morning after pc restart
have testet more viewers and catch cleand multy restarts from server and system.

--sim enter console--
21:42:57 - [LLUDPSERVER]: UseCircuitCode handling from endpoint, client unknown unknown failed. Exception Value cannot be null. at System.Threading.Monitor.Enter(Object obj)
   at OpenSim.Region.Framework.Scenes.Scene.AddNewAgent(IClientAPI client, PresenceType type) in O:\Opensim\Outworldz_Dreamgrid\OutworldzFiles\Opensim\OpenSim\Region\Framework\Scenes\Scene.cs:line 3081
   at OpenSim.Region.ClientStack.LindenUDP.LLClientView.Start() in O:\Opensim\Outworldz_Dreamgrid\OutworldzFiles\Opensim\OpenSim\Region\ClientStack\Linden\UDP\LLClientView.cs:line 810
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.AddClient(UInt32 circuitCode, UUID agentID, UUID sessionID, IPEndPoint remoteEndPoint, AuthenticateResponse sessionInfo) in O:\Opensim\Outworldz_Dreamgrid\OutworldzFiles\Opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 1827
   at OpenSim.Region.ClientStack.LindenUDP.LLUDPServer.HandleUseCircuitCode(Object o) in O:\Opensim\Outworldz_Dreamgrid\OutworldzFiles\Opensim\OpenSim\Region\ClientStack\Linden\UDP\LLUDPServer.cs:line 1667
Couldn't write out log message: System.FormatException: Input string was not in a correct format.
   at System.Text.StringBuilder.FormatError()
   at System.Text.StringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.String.Format(String format, Object[] args)
   at OpenSim.Framework.Console.LocalConsole.Output(String format, String level, Object[] components) in O:\Opensim\Outworldz_Dreamgrid\OutworldzFiles\Opensim\OpenSim\Framework\Console\LocalConsole.cs:line 394
   at OpenSim.Framework.Console.OpenSimAppender.Append(LoggingEvent le) in O:\Opensim\Outworldz_Dreamgrid\OutworldzFiles\Opensim\OpenSim\Framework\Console\OpenSimAppender.cs:line 65
21:43:07 - [ENTITY TRANSFER MODULE]: agent Grid Admin crossing to MainLand03 2004x2002y failed: agent update failed
21:59:14 - [SCENE]: Region MainLand06 2004x2000y authenticated and authorized incoming root agent Grid Admin b3141d72-2683-484a-bf53-ab013f50a1d5 (circuit code 1832751924)
2019-10-28 09:00   
That's an error with the console output, not actually an error that shows why the crash happened.
2019-10-28 09:20   
seems that for some reason comms btw regions / viewer are not that good.
(the console issue as no impact, just ugly ((and fixed on master)))

View Issue Details
8617 [opensim] [GRID] User Service minor always 2019-10-26 12:44 2019-10-26 13:26
OpenSim Snail Dev 3c4bc68
Standalone (1 Region)
.NET / Windows64
SQLite: Missing 'GetUserWhere' functionality [PATCH]
Console refactor introduced 'GetUserWhere' functionality. Function existed for SQLite but no content.
Commit 0fd17c08: Massive console refactor. Greatly simplify interface.
0001-SQLite-missing-GetUsersWhere-functionality.patch (1,296) 2019-10-26 12:44
2019-10-26 13:02   
As it is written, it's vulnerable to SQL injection.
2019-10-26 13:26   
(edited on: 2019-10-26 14:46)
Took OpenSim MySQL format as a template, think that was the OpenSim way.

View Issue Details
8400 [opensim] [REGION] Script Functions tweak always 2018-10-25 14:22 2019-10-25 16:07
Mandarinka Tasty  
won't fix  
Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
BasicPhysics, ODE, BulletSim, ubODE
Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX, .NET / Windows32, .NET / Windows64
More logical NPC's detection with llGetAgentList and replacing ssp.IsViewerUIGod with ssp.IsGod.

I've added more logical processing of NPCs' detection accordingly to applied NPC flags. Addtionally I've replaced ScenePresence bool IsViewerUIGod with correct IsGod.

The description of logics I have applied is as follows:

1. If bool AllowSenseAsAvatar = false ( OpenSim.ini , OpenSimDefaults.ini)

then NPC detection is not possible with llGetAgentList

Now we set AllowSenseAsAvatar = true in ini file.

2. If flag AGENT_LIST_EXCLUDENPC is applied as a scope in llGetAgentList

then NPC detection is not possible with llGetAgentList.

3. If NPC is not created with flag OS_NPC_SENSE_AS_AGENT within osNpcCreate

then NPC detection is not possible with llGetAgentList.

Those cases have been introduced by me as logical union = p v q v r,that means if one of them is true, then NPC detection is not possible with llGetAgentList.

To make NPC detection possible with my version of llGetAgentList one needs:

1. set bool AllowSenseAsAvatar = true in ini file.
2. do not use flag AGENT_LIST_EXCLUDENPC
3. create NPC using osNpcCreate with flag: OS_NPC_SENSE_AS_AGENT

I hope my explanations above are appropriately understandable.

In-world script school example:

integer i;
key npc = NULL_KEY;

    touch_start(integer num)
        if(npc == NULL_KEY)
        if(i == 0)
            npc = osNpcCreate("John","Smith",llGetPos()+<0,0,2>,"MyClone",OS_NPC_SENSE_AS_AGENT);
            list agents = llGetAgentList(AGENT_LIST_REGION, []);
            integer j;
            while (j < llGetListLength(agents))
                string bot = "";
                key id = llList2Key(agents,j);
                string name = llKey2Name(id);
                if(npc == id)
                    bot = "\t<--- NPC has been detected!\n"
                llOwnerSay(name + " [ " + (string)id + " ]" + bot);
2018-10-26 18:18   
(edited on: 2018-10-26 18:19)
Not that I mind this, but just an observation ..

SL does not have NPC, so should we be adopting ll functions to fit us, and be outside of ll spec or just use our own functions such as the existing osGetNPCList() ?

Just not sure it is a good habit to get into ..

Mandarinka Tasty   
2018-10-26 19:06   
@watcher )
First at all, SL does not care what we do or not do with functions that have been designed by LL. All our efforts are meaningless for them , if we repeat those functions with 1-1 precision, or we modify them due to our needs.
It is impossible to make ideal clone of SL, and also mighty majority of people do not want that.
Hence, as you notice, reading my words, I opt for adopting LL functions and modyfing them into our environment accordingly to our needs, wishes etc.
I also consider that reaching LL spec is useless in OpenSim, because it's not possible in 100%. We can try to "stand on our heads" and we will not repeat it as they did. So for what to keep those functions exactly the same?
Additionally, code is opensourced, so anyone is free to set it as he/she wants.

Our osGetNPCList() is very nice tool to detect and list only NPCs.
That is why I have decided to limit using llGetAgentList with NPC and only allow if they are sensed as avatars = agents and not excluded from detection. That is more logical in my opinion. Personally i would even eliminate scanning NPCs with llGetAgentList, but let us do some consensus.
What do you think about my thoughts?
2018-10-26 19:08   
Yeah was not trying to start a debate, I just see a lot of people scream "We need to be exactly like LL" and then at the same time they scream the opposite when it does not do exactly what they want ...

I'll just keep my opinions to myself in the future ..
Mandarinka Tasty   
2018-10-26 19:23   
@watcher )
Please always share your opinions, because it gives us/me possibility to observe problems and concepts from other perspective. Thanks in advance.
What I've been personally observing for the very long time is: people rather want to look exactly here, as their SL avatars. And many of them also would like LL scripted functions to be improved.
Mandarinka Tasty   
2019-10-25 14:43   
The patch has been removed by the author.

View Issue Details
8114 [opensim] [REGION] OpenSim Core feature always 2017-01-04 18:17 2019-10-25 16:07
Mandarinka Tasty Unix, Win, Mac  
patch included master (dev code)  
won't fix  
Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
BasicPhysics, ODE, BulletSim, ubODE
Unknown, Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX, .NET / Windows32, .NET / Windows64
[PATCH] Giving possibility to add/remove estate manager via simulator console.
Hello :)

The patch has been included.

I've implemented the possibility to add / remove estate manager using

simulator region's console commands:

estate add manager <estate-id>[ <UUID> | <Firstname> <Lastname> ]

estate remove manager <estate-id>[ <UUID> | <Firstname> <Lastname> ]

0001-Master-Giving-possibility-to-add-remove-estate-manager-via-.patch (12,969) 2018-07-13 07:09
Add-show-estates-to-available-commands-as-alias.diff (1,149) 2019-01-24 20:03
2018-07-11 04:35   
(edited on: 2018-07-13 07:10)
Patch has been updated to apply to master (11th of July 2018)


2018-07-13 07:33   
While you are in there, how about adding "show estates" to the command handling to bring in line with the other commands "show regions", "show users" and so on?
2018-07-13 07:37   
@Tampa Feel free to add them to the patch. I have just made sure that the patch from Mandarinka Tasty was applyable to current master.
2018-07-13 07:39   
If I knew how to do that I would not be asking...
Ferd Frederix   
2019-01-23 21:11   
Can this patch get some attention from core? It is a useful feature in applications such as Dreamgrid that automate useful tasks such as adding a user, a region and the estate manager with a few clicks via the GUI. In this case, it's the only step missing, the estate manager.
2019-01-24 13:47   

Region (Old Expo) # estate show
Estate information for region Old Expo
Estate Name ID Owner
TestEstate 122 Bill Blight

Region (TestRegion1) # help estates

For more information, type 'help all' to get a list of all commands,
              or type help <item>' where <item> is one of the following:
estate create <owner UUID> <estate name> - Creates a new estate with the specified name, owned by the specified user. Estate name must be unique.
estate link region <estate ID> <region ID> - Attaches the specified region to the specified estate.
estate set name <estate-id> <new name> - Sets the name of the specified estate to the specified value. New name must be unique.
estate set owner <estate-id>[ <UUID> | <Firstname> <Lastname> ] - Sets the owner of the specified estate to the specified UUID or user.
estate show - Shows all estates on the simulator.
2019-01-24 20:04   
Added patch to add "show estates" as command alias for "estate show" to bring in line with other commands such as "show regions", tested against current master and working
Ferd Frederix   
2019-01-25 09:14   
Updated [^] to have the estate link region command.

Bill, there is no console method to add an Estate Manager to a sim while retaining ownership. There can be just one owner, but can be multiple managers.
2019-01-25 09:15   
Did you all miss the fact that my comment was right after aiaustin saying that show regions would be a good addition, and I was pointing out that it already existed ..
Ferd Frederix   
2019-01-25 10:54   
I'm sorry, Bill. He deleted his comment after you posted. I assumed you were mistaken about what I was asking. I apologize for any misunderstanding.
2019-01-25 11:02   
Ahhhh, I was still seeing his comment until I did a full refresh for some strange reason ... Sorry for getting a little bent ..
paela argus   
2019-01-25 11:48   
more 1 owner for one parcel ? lol nop never !
paela argus   
2019-01-25 11:52   
I do not see how it's convenient to add an estate manager console I already see user dramas this function should be deleted no interest except for the external devs of logicial as ferd fact

View Issue Details
7916 [opensim] [REGION] Script Functions minor always 2016-06-03 23:37 2019-10-25 16:05
Mandarinka Tasty  
acknowledged master (dev code)  
won't fix  
Grid (1 Region per Sim)
Mono / Linux64
osSetTerrainTexture and osSetTerrainTextureHeight neither work for Estate Owner nor Estate Manager without God Powers
Hello !

I have noticed that functions:

osSetTerrainTexture and osSetTerrainTextureHeight work only for Grid Administrators and Region Administrators, if God Powers are enabled for them.

And this situation exists , regardless settings in osslEnable.ini

Hence, it can be considered as limitation of using these functions.

In my opinion estate owner and estate manager with userLevel = 0 ( no god powers)

should also have possibility to use such script functions in their objects.
I have attached PATCH: that includes solution:

I have replaced condition:

if (World.Permissions.IsGod(m_host.OwnerID) with condition:

if ((World.Permissions.CanIssueEstateCommand(m_host.OwnerID, false)) && (estate != null))

In this way, every user with access to Estate Menu is able to use those functions

regardless of UserLevel assigned to the account.

Certainly, by design , those functions require appropriate Thread Level or

individual settings in osslEnable.ini.

That I have not changed to preserve compatibility.
Mandarinka Tasty   
2019-10-25 14:40   
The patch has been deleted by the author.

View Issue Details
8344 [opensim] [REGION] OpenSim Core feature always 2018-07-19 21:33 2019-10-25 16:05
Mandarinka Tasty  
won't fix  
Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
BasicPhysics, ODE, BulletSim, ubODE
Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX, .NET / Windows32, .NET / Windows64
Firestorm 5.0.11
Possibility to complete disabling parcel bans - free proposition.
The patch has been included.

I've thought of making some better usage of hidden config boolean: DisableParcelBans and I've decided to share my idea of solution.

A scenario of situations that one might use with DisableParcelBans = true can be found in educational social virtual environments or in some RP game simulators.

Sometimes it is just better to find compromise, than to use ban hammer )
Certainly estate bans work with my patch, since they are higher level of region's management ( example: for teachers etc).
If one finds it interesting, take the patch and apply into your source code or read how I've written it and repeat in your code.
Mandarinka Tasty   
2019-10-25 14:47   
The patch has been removed by the author.

View Issue Details
8110 [opensim] [REGION] OpenSim Core feature always 2017-01-01 13:18 2019-10-25 16:04
Mandarinka Tasty Unix, Win, Mac  
acknowledged master (dev code)  
Standalone (1 Region) , Standalone (Multiple Regions) , Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
BasicPhysics, ODE, BulletSim, ubODE
Unknown, Mono / Linux32, Mono / Linux64, Mono / Windows, Mono / OSX, .NET / Windows32, .NET / Windows64
The addition of OwnerID to be displayed in SceneObjectReport and ScenePartReport
Hello )

The patch has been attached.

Actually, the object's information, that is displayed after using

region console commands: show object id, show object name, etc

does not contain info concerning object's owner.

This patch allows for showing Owner ID in displayed reports.
Mandarinka Tasty   
2019-10-25 14:48   
The patch has been removed by the author.

View Issue Details
8080 [opensim] [REGION] Script Functions minor N/A 2016-12-04 23:34 2019-10-25 16:00
Lotek Linux  
normal 14.04LTS  
acknowledged master (dev code)  
Grid (1 Region per Sim)
Mono / Linux64
OSSL proposal: HG capable osInstantMessage and osGiveInventory
I would like to propose two or three new functions, since the Linden equivalents don't work over the hypergrid. We can already do avi to hypergrid-avi transfers but not object to hypergrid-avi.


osInstantMessage(key user, string loginuri, string message);

Sends an instant message to a hypergrid user


osGiveInventory(key user, string loginuri, string inventory);

Sends an object from prim inventory to a hypergrid user


Ideally, also:

osGiveInventoryList(key user, string loginuri, string folder, list inventory);

Which sends multiple items from a list in prim inventory to a hypergrid user


Can this be done if the foreign LoginURI plus the foreign avatar UUID are known?

The newly introduced loginuri parameter would be what is usually seen on the name tags of hypergrid visitors, and similar to what's returned for our local grid by osGetGridLoginURI();
Examples that fail currently with the Linden functions:

llInstantMessage(kForeignAvatar, "Hello");
(silently fails)

llGiveInventory(kForeignAvatar, llGetInventoryName(INVENTORY_NOTECARD,0));
[23:31] llGiveInventory: Can't find destination 'a6396f7c-dd01-4fb9-abb4-9b5f706d6aaf'

This will only work when the hypergrid avatar is visiting us in our sim our object is in.

But it won't work when they reside on their foreign home grid as the avatar UUID is not known to our own local grid.
Linden equivalents:

llInstantMessage(key user, string message); [^]

llGiveInventory(key destination, string inventory); [^]

llGiveInventoryList(key target, string folder, list inventory); [^]
2016-12-05 05:14   
this may need to wait for a HG revision
Mandarinka Tasty   
2016-12-05 19:21   

There is possibility to send InstantMessage

to foreign avatar = located in foreign grid

from local avatar = located in local grid.

Because local grid is not able to know foreign avatar's key, then

we need to find it. And we can do that using:

osAvatarName2Key(string firstname, string lastname);

It is example script, I use to send message:

    touch_start(integer num)
        llInstantMessage(osAvatarName2Key("John.Smith",""),"Hello !!!");

Please, carefully, pay attention on syntax of firstname and lastname
Mandarinka Tasty   
2016-12-05 19:29   
Certainly, sending item using llGiveInventory, unfortunately does not work.

But in my opinion, problem exists in llGiveInventory's way of sending item.

So, personally, I would rather think about improving llGiveinventory,

than creating osVersion.
Mandarinka Tasty   
2016-12-05 20:59   
I have made: llGiveInventory send an item to foreign avatar,

when avatar is offline.

In case of being online, it was working.

And I have added message about what has sent folder to foreign avatar

in aspect of llGiveInventoryList
Mandarinka Tasty   
2016-12-05 21:02   
These are school examples of LSL code:

    touch_start(integer num)


    touch_start(integer num)
        list items;
        integer i;
            string item = llGetInventoryName(INVENTORY_ALL,i);
            if(item != llGetScriptName())