OpenSim Core Bugs

Syndicate content MantisBT - Issues - (rdcdev)
MantisBT - Issues - (rdcdev)
Updated: 13 min 14 sec ago

0007058: Change OpenSim [GridInfo] defaults to remove confusion

Tue, 2014-07-29 21:47
The [GridInfo] defaults have 127.0.0.1:9000 in them which modern viewers like Singularity load when you try to connect to a given region directory.<br /> This tends to overwrite whatever setting the user just tried to put in manually.<br /> <br /> I suggest changing the 127.0.0.1 defaults to something NOTICEABLY INVALID like:<br /> FIXMEINOPENSIMINI:9000<br /> <br /> then put some comments around indiciating to use basically what is in your regions.ini or robust.ini or HG configs.
Categories: OpenSim Bugs

0005463: Console displays error at some point, then loops permanently and crashes sim.

Tue, 2014-07-29 21:45
For unknown reason console will display the following error repeatedly in a loop until the sim crashes. Have not been able to determine what starts this issue.<br /> <br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: An error has occured while attempting to a<br /> ccess the XmlRpcGroups server method groups.getAgentGroupMembership at <a href="http://gr">http://gr</a> [<a href="http://gr" target="_blank">^</a>]<br /> oups.osgrid.org/xmlrpc.php<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: Data at the root level is invalid. Line 1,<br /> position 1. at System.Xml.XmlTextReaderImpl.Throw(Exception e)<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]:<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: RequestingAgentUserService ::<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: RequestingSessionID :: 00000000-0000-0000-<br /> 0000-000000000000<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: RequestingAgentID :: 00000000-0000-0000-00<br /> 00-000000000000<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: AgentID :: e749c837-0927-b09f-33ea-7599751<br /> 779bf<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: WriteKey ::<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: ReadKey ::<br /> 13:34:29 - [XMLRPC-GROUPS-CONNECTOR]: GroupID :: a5a64071-08c9-4726-a68d-ed49134<br /> 4f714<br /> 13:36:56 - >>> DoDelete action:; RegionID:4413d220-072c-11e0-81e0-0800200c9a66
Categories: OpenSim Bugs

0007220: Hypergrid jump from OSGrid to Kitely Welcome Center confuses viewer / server about worn attachments

Tue, 2014-07-29 06:15
If I hypergrid jump from Wright Plaza to Kitely Welcome Center, the viewer (happens with 3 viewers I have tried) or the server seem to get confused about whether my attachments are worn or just rezzed inworld. My attachments seem to exist in BOTH conditions at once. Attachments which I was wearing during the jump will appear (in my viewer) as detached, floating inworld. But the same attachments ALSO appear (in my viewer) as worn. I say ALSO because editing these floating attachments and clicking RELOAD will RELOAD the attachments inworld and ALSO on my body. The attachments are sculpts, so I can watch them turn into spheres and reload their shape, inworld and on my body, at the same time. Other Kitely users have taken screenshots of me in this state and their screenshots show me appearing (to other users) as bereft of ALL attachments. The rogue attachments do NOT show at all in other user's viewers. So my viewer and other user's viewers are showing different versions of the scene. I don't know which version is "correct" as to what is actually happening. I don't know whether this is a server issue, a viewer issue, or what. But it is a mess.<br /> <br /> Clicking REMOVE OUTFIT and then REPLACE OUTFIT, from the Inventory folder which contains the attachments, makes the floating attachments vanish from inworld and return to my body (in my viewer.) In the viewers of other users, my attachments never return and I am bereft of all attachments. <br /> <br /> A Kitely admin suggested that I might not have full perms on some of the attachments, but a permission check says that I do. <br /> <br /> This issue has only recently started happening for me on Kitely Welcome Center.
Categories: OpenSim Bugs

0007238: Attachments dont show in guest grid after you did hypergrid to it.

Mon, 2014-07-28 17:54
When you hypergrid to a guest grid , your attachments dont show anymore<br /> sometimes the appear in a flash and then the dissapear.<br /> This technical break the use of Hypergrid compleet. we cannot find any configuration error. this test is done to more grids running on 0.8 osgrid, metropolis, own grid, and 2 grids from friends. the results are everytime the same. no attachm,ents visible from guests.<br /> <br /> This a really urgent bug and need to be fixt with new 0.8 release.
Categories: OpenSim Bugs

0007283: Wiki should be updated to indicate that Get/Set primitive params is currently not fully implemented

Mon, 2014-07-28 17:40
For the influx of new "SL refugees" who don't watch or know to search Mantis, the Opensim Wiki page for current function status should be updated to reflect only partial implementation of the various get/set primitive params functions which do not yet support advanced materials.<br /> <br /> Page: <a href="http://opensimulator.org/wiki/LSL_Status/Functions">http://opensimulator.org/wiki/LSL_Status/Functions</a> [<a href="http://opensimulator.org/wiki/LSL_Status/Functions" target="_blank">^</a>]<br /> Functions affected:<br /> llGetLinkPrimitiveParams()<br /> llGetPrimitiveParams()<br /> llSetLinkPrimitiveParams()<br /> llSetLinkPrimitivieParamsFast()<br /> llSetPrimitiveParams()
Categories: OpenSim Bugs

0006977: Limit see and chat with avatars of others parcels do not work

Sun, 2014-07-27 13:21
In option About Land/Options/"The avatars of other parcels can see and chat with the avatars of this parcel"<br /> <br /> The box remains grayed out, it is not checkable/uncheckable.<br /> <br /> Normally it should be clickable to limit the chat and the avatar cam ... and probably too with scripts functions (llSay etc ...).<br /> <br /> Tested with Singularity, Firestrom, Kokua.<br /> <br /> NB: The voice parcel limitation work fine.
Categories: OpenSim Bugs

0006789: BulletSim: Consuming vast amounts of CPU

Sun, 2014-07-27 09:57
I have been testing BulletSim physics on a separate computer connected to our grid. Finding it stable enough, at least on 0.7.6 Dev (fc4f86a), I've decided to run it on our "main" grid (running Ubuntu 10.04 and Mono 2.10.8.1).<br /> <br /> I was astonished at the amount of CPU that this is currently consuming. Usually, I can easily run 6 instances on this old server, each with about 100.000 prims on several regions, and, when idle, CPU consumption is around 2%, peaking to 10% occasionally (e.g. when saving snapshots or doing something), but, of course, when avatars are around, the load increases when the avatar just logs in. The server has 6 GBytes of memory and rarely ever consumes more than 3-4.<br /> <br /> When switching to BulletSim, memory consumption went to twice normal (see resolved issue <a href="http://opensimulator.org/mantis/view.php?id=6599">http://opensimulator.org/mantis/view.php?id=6599</a> [<a href="http://opensimulator.org/mantis/view.php?id=6599" target="_blank">^</a>]) but CPU skyrocketed. Idle instances are routinely consuming 40-60% of all CPU — each. Which, of course, brings the server to its knees, and logging in, while it allows everything to be loaded relatively quickly, avatar movement is next to impossible.<br /> <br /> Switching back to ODE restores the server to its usual low CPU consumption.<br /> <br /> Now I understand that this might be just related to BulletSim parameters, with which I'm not familiar (yet). Maybe there is a recommended set of parameters to keep CPU consumption as low as under ODE?
Categories: OpenSim Bugs

0006496: BulletSim -- Collision events not being activated all the time when prims collide with bullets.

Sat, 2014-07-26 23:12
When bullets are fired at the face of a prim some go through and some bounce off, in both the go through case and the bounce off case getting a collision_start and collision event activated is rare.
Categories: OpenSim Bugs

0007226: [PATCH]Bulletsim-- Implement Vehicle Reference Frame.

Sat, 2014-07-26 23:11
This has not been working before but this small tweak allows you to use it for vehicles.
Categories: OpenSim Bugs

0007147: Texture offset does not work properly in a linkset

Sat, 2014-07-26 19:53
Texture offset work perfectly in a single prim but doesn't work properly in a linkset.<br /> <br /> Tested with:<br /> <br /> llOffsetTexture<br /> osSetPrimitiveParams<br /> llSetPrimitiveParams<br /> llSetLinkPrimitiveParamsFast
Categories: OpenSim Bugs

0006855: [SCRIPT] llDetectedLinkNumber broken with collision in a link set

Sat, 2014-07-26 11:45
llDetectedLinkNumber don't work with collision event in a link set ...<br /> That work fine in SL, i have tested with the script below.
Categories: OpenSim Bugs

0007157: llGetAgentLanguage(llDetectedKey(0)) return always en-us

Sat, 2014-07-26 11:44
llGetAgentLanguage(llDetectedKey(0)) return always en-us with singularity (and with Firestorm too)
Categories: OpenSim Bugs

0006880: Print Notecard on Prim (MOAP)

Sat, 2014-07-26 11:43
I tried several methods to display the contents of a notecard on a prim with MOAP<br /> <br /> - Direct printing<br /> - With Javascript and HTML<br /> - With RequestURL and display html page<br /> - Change Chartset (iso and utf-8)<br /> <br /> After all these tests I still see the same problem, special characters are not displayed correctly (é, à, è, ...).<br /> <br /> I think Opensim do not like the French ...<br /> <br /> Thank you in advance.
Categories: OpenSim Bugs

0007209: [Script] PRIM_OMEGA return no values

Sat, 2014-07-26 11:36
PRIM_OMEGA return no values.<br /> <br /> Tested with:<br /> llGetPrimitiveParams([PRIM_OMEGA]);<br /> <br /> and with:<br /> llGetLinkPrimitiveParams(LINK_ROOT, [PRIM_OMEGA]);
Categories: OpenSim Bugs

0007214: [SCRIPT] PRIM_MEDIA_AUTO_PLAY TRUE does not work with llSetLinkMedia

Sat, 2014-07-26 11:36
I see PRIM_MEDIA_AUTO_PLAY, TRUE does not work when I use it in the llSetLinkMedia function. I have to click a second time to display the content. The content is not displayed automatically.
Categories: OpenSim Bugs

0007273: Territory conflicts with varregions

Fri, 2014-07-25 21:48
If a person uses the north east coordinate of your var region to put their new regular region it trumps your var and gives that corner to the interloper (even tho your var was up and running) rendering the whole var unreachable, you can however tp to the unwary squatters region and see it's name on the map, etc.<br /> <br /> One reason this happens is the Grid map on the website shows varregions as one regular 256 region instead of it's real 768, 1024 etc size. We need the grid map fixed to avoid the conflict but more important than that we need to prevent people from setting up on coordinates that are already in use.
Categories: OpenSim Bugs

0007276: Can no longer login direct, or HG to a variable-sized (>256) region.

Tue, 2014-07-22 13:22
Issue with commit r/24977 (3c6bec)'On login and first HG entrance to a foreign grid, perform query access checks before proceeding.'<br /> <br /> Attempt login or HG teleport to a variable-sized-region (larger than 256) fails with Viewer Dialogue: 'Teleport failed. Destination is a variable-sized region, and source is an old simulator. Consider upgrading.'<br /> <br /> Teleport to a variable-sized region within the same grid does not exhibit this issue.
Categories: OpenSim Bugs

0007274: Users added to parcel & estate ban list are still able to go to a var and stay as long as they want. Have not tested on non var

Tue, 2014-07-22 03:47
Users that have been added to both the parcel and estate ban lists can still enter into the var area with no problem and stay as long as they like. I assume the ban list is supposed to work on a var, but it appears to not be working.
Categories: OpenSim Bugs

0007230: Teleport into SW 256x256 area of a var causes terrain to load reverse order than normal.

Tue, 2014-07-22 02:45
When I teleport into a var region and the var has the landing point set to the far SW sim 256x256 area, the terrain starts loading with the far NE corner of the var first and loads the spot where the AV is standing last. This is reverse of what it should be doing. If the AV flies to the center of the var and logs off, then logs back in to the last location in the var middle, the terrain loads correctly starting at the spot where the av is located and out from there. The load order is hard to see on really fast connections.<br /> <br /> This is repeatable 100% of the time under these conditions with SendTerrainUpdatesByViewDistance = true
Categories: OpenSim Bugs

0007270: Exception when contacting presence server (not enough free sockets?)

Mon, 2014-07-21 23:29
This might not be strictly a bug, but merely a configuration issue — either at the OS level or at the ROBUST/simulator level.<br /> <br /> I've noticed that in a region that makes frequent HTTP calls, at some point, the server starts throwing exceptions, both on outgoing calls, as well as HTTP calls to the ROBUST server. As a result, the region stops responding as it needs HTTP calls for some critical functions. Moving around, as long as no HTTP calls are needed, still works.<br /> <br /> This hasn't been easy to pinpoint. Typical errors occur only after several hours (and probably thousands of HTTP calls). Here is a sample (my.robust.server.tld is a fake name for the purposes of this log):<br /> <br /> 2014-07-16 14:29:39,218 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:29:39,218 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:29:49,318 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP cf6ca37f-6cbd-4039-9d70-58a2919f7322 in prim My Online Status Indicator, localID 2267576109, timeout was 100 ms<br /> 2014-07-16 14:29:49,320 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:29:49,321 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:30:39,432 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP 03a9b966-0320-41df-bba6-2663a69b36c8 in prim My Online Status Indicator 2, localID 2267576108, timeout was 100 ms<br /> 2014-07-16 14:30:39,434 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:30:39,435 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:30:49,534 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP cf6ca37f-6cbd-4039-9d70-58a2919f7322 in prim My Online Status Indicator, localID 2267576109, timeout was 100 ms<br /> 2014-07-16 14:30:49,535 INFO - OpenSim.Framework.SynchronousRestFormsRequester [FORMS]: Error sending request to <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted. Request: VERSIONMIN=0&VERSIONMAX=0&METHOD=getagents&uuids[]=35c965ac-0b37-4b36-968a-6dbdc127a544<br /> 2014-07-16 14:30:49,537 DEBUG - OpenSim.Services.Connectors.PresenceServicesConnector [PRESENCE CONNECTOR]: Exception when contacting presence server at <a href="http://my.robust.server.tld:8003/presence:">http://my.robust.server.tld:8003/presence:</a> [<a href="http://my.robust.server.tld:8003/presence:" target="_blank">^</a>] Thread was being aborted<br /> 2014-07-16 14:31:39,636 DEBUG - OpenSim.Region.ScriptEngine.Shared.Instance.ScriptInstance [SCRIPT INSTANCE]: Aborting unstopped script Online status indicator for WP 03a9b966-0320-41df-bba6-2663a69b36c8 in prim My Online Status Indicator 2, localID 2267576108, timeout was 100 ms<br /> <br /> While the above logs seem to be limited specifically to presence calls, this is not the case. Objects routinely making external HTTP calls will be affected as well. At some point, the simulator will prevent them from make any further calls and shut the scripts down. The above errors come mostly from an in-world script which was not aborted for some reason.<br /> <br /> A few tests have been made to try to isolate this issue. The first change involved tweaking several parameters at the OS level. Current sysctl.conf is:<br /> <br /> net.ipv4.conf.default.rp_filter = 1<br /> net.ipv4.conf.all.rp_filter = 1<br /> net.ipv4.tcp_syncookies = 1<br /> net.ipv4.conf.all.send_redirects = 0<br /> net.ipv4.conf.all.accept_source_route = 0<br /> net.ipv6.conf.all.accept_source_route = 0<br /> net.ipv6.conf.all.autoconf = 0<br /> net.ipv6.conf.default.autoconf = 0<br /> net.ipv6.conf.eth0.autoconf = 0<br /> net.ipv6.conf.all.accept_ra = 0<br /> net.ipv6.conf.default.accept_ra = 0<br /> net.ipv6.conf.eth0.accept_ra = 0<br /> net.core.rmem_default = 524288<br /> net.core.rmem_max = 16777216<br /> net.core.wmem_default = 524288<br /> net.core.wmem_max = 16777216<br /> net.ipv4.tcp_max_syn_backlog = 2048<br /> net.ipv4.tcp_rmem = 10240 87380 16777216<br /> net.ipv4.tcp_wmem = 10240 87380 16777216<br /> net.ipv4.tcp_no_metrics_save = 1<br /> net.ipv4.tcp_mem = 524288 524288 524288<br /> net.ipv4.tcp_rfc1337 = 1<br /> net.ipv4.ip_no_pmtu_disc = 0<br /> net.ipv4.tcp_sack = 1<br /> net.ipv4.tcp_fack = 1<br /> net.ipv4.tcp_window_scaling = 1<br /> net.ipv4.tcp_timestamps = 1<br /> net.ipv4.tcp_ecn = 0<br /> net.ipv4.route.flush = 1<br /> fs.file-max = 2097152<br /> vm.swappiness = 10<br /> vm.dirty_ratio = 60<br /> vm.dirty_background_ratio = 2<br /> net.ipv4.tcp_synack_retries = 2<br /> net.core.somaxconn = 65535<br /> net.core.netdev_max_backlog = 65536<br /> net.core.optmem_max = 25165824<br /> net.ipv4.udp_mem = 65536 131072 262144<br /> net.ipv4.tcp_max_tw_buckets = 1440000<br /> net.ipv4.tcp_tw_recycle = 1<br /> net.ipv4.tcp_tw_reuse = 1<br /> <br /> (based on several suggestions, including <a href="https://rtcamp.com/tutorials/linux/sysctl-conf/">https://rtcamp.com/tutorials/linux/sysctl-conf/</a> [<a href="https://rtcamp.com/tutorials/linux/sysctl-conf/" target="_blank">^</a>])<br /> <br /> The server in question has lots of spare memory, thus creating larger buffers, more sockets, and diminishing swapping is perfectly acceptable. It runs ROBUST, 6 simulator instance (running some 20 regions), and nginx + php5-fpm + MySQL, and still only consumes about 3 out of 6 GBytes of RAM.<br /> <br /> A few optimizations have been made. The first was to ensure that all scripts who use outgoing calls release acquired URLs (e.g. call llReleaseURL() if a URL acquired via llRequestURL() is not needed any more). This substantially improved, but not removed, the issue. Then possible timeouts calling the nginx server (which runs not only several external modules for the core services, but also a complex application which several in-world items contact frequently) were investigated; nginx was using a Unix socket configuration to communicate with php5-fpm (good for low-traffic solutions), and this was moved to a more standard TCP socket communication instead (which allegedly is better for dealing with high-traffic solutions). While this is by no means an exhaustive way of eliminating any issues on the operating system side, it was important for me to make sure that the problem is not simply a bad server configuration.<br /> <br /> When the application is fully operational, this results in (possibly) hundreds of HTTP calls per minute, made from several in-world objects, some running inside avatar attachments on NPCs. Hitting internal limits is a strong possibility, but it would be expected that some console errors would pop up (e.g. alerts about culling the amount of HTTP calls being made). However, this is not the case. Objects which merely contact a webserver once per minute, left running several hours, will start throwing the aforementioned errors.<br /> <br /> It's unclear if the errors happen at the ROBUST side as well as at the simulator side. ROBUST doesn't throw any errors, neither at the console level, nor at the logging level. Nevertheless, the simulator complains about not being able to contact ROBUST. This seems to be strictly tied to the single simulator running those objects making HTTP calls; other simulator instances do not show any errors.<br /> <br /> OpenSim.ini has the following network- and script-related configurations:<br /> <br /> [ClientStack.LindenUDP]<br /> client_socket_rcvbuf_size = 12582912<br /> AckTimeout = 180<br /> <br /> [XEngine]<br /> Enabled = true<br /> MinThreads = 2<br /> MaxThreads = 100<br /> IdleTimeout = 60<br /> Priority = "BelowNormal"<br /> MaxScriptEventQueue = 300<br /> ThreadStackSize = 262144<br /> AppDomainLoading = true<br /> DeleteScriptsOnStartup = true<br /> DefaultCompileLanguage = "lsl"<br /> AllowedCompilers = "lsl,cs,js,vb"<br /> CompileWithDebugInformation = true<br /> AllowMODFunctions = false<br /> AllowOSFunctions = true<br /> AllowLightShareFunctions = true<br /> OSFunctionThreatLevel = Low<br /> EventLimit = 30<br /> KillTimedOutScripts = false<br /> ScriptDelayFactor = 1.0<br /> ScriptDistanceLimitFactor = 1.0<br /> SensorMaxRange = 96.0<br /> SensorMaxResults = 16<br /> <br /> Simulators are also checked for 'health' via monit, by calling <a href="http://localhost:XXXX/jsonSimStats/">http://localhost:XXXX/jsonSimStats/</a> [<a href="http://localhost:XXXX/jsonSimStats/" target="_blank">^</a>] (XXXX varies for each instance) every cycle. WebStats are also enabled.<br /> <br /> Currently, my 'prime suspect' is an object that checks if an avatar is online every minute and sends the reply to an external webserver. Similar scripts abound in Second Life (where I have some of them running for 7 or 8 years...), and I have been running them on OpenSimulator for a couple of years at least. It's only on the latest versions (0.8.0 Dev) that I have encountered this issue.<br /> <br /> While this might not be an OpenSimulator 'bug' (I kept the severity as minor and priority as low on this report), but merely a misconfiguration of either ROBUST, OpenSim.ini, or the underlying server, any help in fixing this might be useful in the future for anyone who might have the same problem.
Categories: OpenSim Bugs