OpenSim Core Bugs

Syndicate content MantisBT - Issues - (rdcdev)
MantisBT - Issues - (rdcdev)
Updated: 50 min 18 sec ago

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

0007275: [XBakes] read, store, read, store, read for unchanged avatar on every login

Mon, 2014-07-21 15:29
With improved XBakes console logging in r/24973 (for example) for each avatar login - not just the first time - I see the expected read followed immediately by TWO further store/read cycles on the baked textures. I would expect just a SINGLE read I would think? No change at all has taken place, no other avatars on the test grid, and the relog attempt immediately followed a log off.<br /> <br /> 15:00:56 - [XBakes]: read 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:56 - [AVFACTORY]: Received texture update for Ai Austin e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:56 - [XBakes]: stored 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:57 - [XBakes]: read 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> <br /> 15:00:58 - [AVFACTORY]: Received texture update for Ai Austin e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:58 - [XBakes]: stored 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> 15:00:58 - [XBakes]: read 5 textures for user e24a9015-f5ca-452b-8c95-d32e34cb9d64<br /> <br /> <br /> Tested on default ./bakes directory and custom directory.
Categories: OpenSim Bugs

0007067: Avatars highly distanced from the ground

Mon, 2014-07-21 12:34
Avatars appear to float much higher above the ground than they should. Even when wearing multiple shapes, my feet are way above the floor of a simple cube. For some reason, avatar collisions might not be properly detected. Screenshot attached.
Categories: OpenSim Bugs

0007063: xbakes Robust.[HG].ini.example BaseDirectory = "/data/bakes" issue

Mon, 2014-07-21 12:33
When xbakes was added.. the example given in Robust.ini.example and Robust.HG.ini.example for the BaseDirectory used a non-standard area that is set to a root (/) based file. I assume this is not usual and probably only relevant for Unix users?<br /> <br /> [BakedTextureService]<br /> LocalServiceModule = "OpenSim.Server.Handlers.dll:XBakes"<br /> ;; This directory must exist and be writable for the user ROBUST runs as<br /> ; BaseDirectory = "/data/bakes"<br /> <br /> I think that should be "./data/bakes" or just "./bakes"? i.e. its relative to be below "bin" as is usual for all sorts of such caches and maptiles, etc.<br /> <br /> Also... I am not sure if the directory has to pre-exist as the comment implies or if its created when not already there... which is usual for such things in OpenSim.
Categories: OpenSim Bugs

0007023: Warp3d errors when (RenderMeshes = true) in [Map] section of OpenSim.ini

Mon, 2014-07-21 12:02
when RenderMeshes = true is set in [Map] section of OpenSim.ini I get the following spew on region startup<br /> <br /> 12:51:30 - Failed to decode mesh asset: Could not load type 'zlib.ZOutputStream' from assembly 'zlib.net, Version=1.0.3.0, Culture=neutral, PublicKeyToken=47d7877cb3620160'.<br /> <br /> and no mesh objects render on tiles, they just appear as a cut and hollow cube.
Categories: OpenSim Bugs

0007033: Warp3D [Map] section entries in OpenSim.ini.example needed for RenderMeshes (and possibly UseAntiAliasing)

Mon, 2014-07-21 11:53
Commit "54a4b9" r/24228 on 2014-01-19 introduced a new [Map] section parameter "RenderMeshes" (default false) in OpenSimDefaults.ini but this was not added to OpenSim.ini.example<br /> <br /> Also the code introduced a parameter UseAntiAliasing in the same section but this is not present in OpenSimDefaults.ini or OpenSim.ini.example<br /> <br /> <a href="http://opensimulator.org/viewgit/a=commit&p=opensim&h=54a4b9eab4009711f574fe744e2dd82373c971c9">http://opensimulator.org/viewgit/a=commit&p=opensim&h=54a4b9eab4009711f574fe744e2dd82373c971c9</a> [<a href="http://opensimulator.org/viewgit/a=commit&p=opensim&h=54a4b9eab4009711f574fe744e2dd82373c971c9" target="_blank">^</a>]
Categories: OpenSim Bugs

0007127: [HELO SERVICE]: Unable to perform HELO request to http://inventory.ossgrid.org:80/helo/: Remote server returned an error: (404)

Sun, 2014-07-20 21:30
OSGrid to Foreign Grid (Openvue) transfer shows this console message on the incoming region server for the foreign grid...<br /> <br /> 16:50:41 - [HG INVENTORY CONNECTOR]: Added <a href="http://inventory.osgrid.org:80">http://inventory.osgrid.org:80</a> [<a href="http://inventory.osgrid.org:80" target="_blank">^</a>] to the cache of inventory URLs<br /> 16:50:41 - [HELO SERVICE]: Unable to perform HELO request to <a href="http://inventory.osgrid.org:80/helo/:">http://inventory.osgrid.org:80/helo/:</a> [<a href="http://inventory.osgrid.org:80/helo/:" target="_blank">^</a>] The remote server returned an error: (404) Not Found.<br /> 16:50:41 - [HG INVENTORY SERVICE]: HELO returned
Categories: OpenSim Bugs

0007235: [PATCH]Bulletsim-- Implement VEHICLE_FLAG_LIMIT_ROLL_ONLY into the first and default Vertical Attractor.

Sat, 2014-07-19 02:08
In the interest of testing kept the vertical attractor simple in all the formulas. This patch brings the first formula to feature complete status with adding into a flag that limits its behavior.
Categories: OpenSim Bugs

0006020: Failed logins with "did not accept compressed transfer" message

Sat, 2014-07-19 01:01
When some OpenSim regions run for a about 24 hours, the following error message is shown when a user tries to log in and the login procedure fails. A region restart is required to fix that issue.<br /> <br /> WARN - OpenSim.Services.Connectors.Simulation.SimulationServiceConnector [REMOTE SIMULATION CONNECTOR]: Remote simulator X did not accept compressed transfer, suggest updating it.<br /> <br /> I read that Diva did fix that issue for HyperGrid logins on May 11, 2011. Probably this bug is very similar.<br /> <br /> It is strange that only a small number of regions experiences this. All of them run standalone OpenSim regions with multiple regions running on the same OpenSim process.
Categories: OpenSim Bugs

0005003: "Jump and then Forward key" works only if facing to North & East

Fri, 2014-07-18 17:16
Jump and then Forward key works only if facing to North or East, and<br /> doesnt work Jump and Backward.<br /> <br /> facing to South and West Jump and backward works but not to forward.
Categories: OpenSim Bugs