Server Bugs

• Use concise, precise descriptions
• Do not include sensitive information.
• Create a support ticket at https://support.secondlife.com for individual account issues or sensitive information.
"Too many objects with large inventory are selected. Please select fewer objects and try again." gets triggered easily while returning, taking combined and deleting objects like furniture sets
It is quite understandable if the 10,000 limit applies to the objects we are taking combined/deleting/returning as we might rezz the same at some point and cause overload to the server but applying 10K limit to the content of the objects is quite hard to work around, especially when we are dealing with objects with large content. I had noticed this error appearing but I never really thought about finding the limit till yesterday. When I was trying to return a house, including its furniture, so it would be easier to rezz at the new spot, I had to keep reducing my selection until it was down to 12 objects! It was then I felt doubt; it's probably not the objects themselves but the content of the objects that is causing this issue, as I was able to select almost everything else worth thousands of prims at once and return. Upon further testing, I found that the furniture pieces I was trying to return had approximately 800-1000 animations in their content. As we all know, there are many furniture creators who include thousands of animations in their products and with this limit it would be almost impossible to delete/take/copy a bunch of furniture at once. I am aware of the possibility of using the return option with both land and region tools to avoid this limitation. However, when we wish to rebuild something at a different location or create a backup there is no real alternative in this situation. I kindly request LL to bless us with a workaround or reconsider how the limit is applied to make things easier for serious builders and those in service sector. Thank you for your time and attention
0
terrain export is badly encoded/quantised leading to significant resolution loss
See blog post https://www.blogger.com/blog/posts/8863246996882687669 for a longer write up. tl;dr version is... The terrrain files produced by the SL server when exporting terrain are not properly encoding the height, resulting in coarse quantised terrain. It would appear to choose to encode only the height value (R channel) leaving the G channel untouched. This means that the resolution of the land exported is limited to whatever value happened to be in the G channel at the time of creation/import. Untested repro steps, as I have no access to SL regions with terrain rights. My terrain tools should be usable but they do try to minimise the G value for any given height. The attached 20m-Q4 file is encoded to R=80, G=32, meaning that the minimum G step is in their 1/4 metre, so it should still be visible with a sharp gradient. 1 start with an empty region 2 load a flat terrain RAW file, if possible use one with a G channel suitably high to demonstrate the issue, 120 would be a good starting point. 3 in SL manipulate the terrain using the inworld tools, adjus the strength of the tools. 4 create a mount with a slow smoother gradient that is shallow enough and wide enough that the stepping should be obvious. For a G value of 120 a smooth mound of diamater 10m and height 10m should give ample evidence 5 see the smooth land in SL 6 bake and export 7 re-import explected results a stepped pyramid instead of a smooth mound.
6
·
tracked
Script Emailing is failing with an SQL Server Bug
Sim to Sim / Script to Script Emailing is failing with this error: mailtolsl@mail-in-agni-2.secondlife.io > (expanded from < 5243fc88-9820-3f0a-649c-eb5d4f803003@lsl.secondlife.com >): Command died with status 11: "/opt/linden/indra/tools/mailglue/mailglue --grid=agni --system=lsl". Command output: DBD::mysql::db do failed: Data too long for column 'script_id' at row 1 at /opt/linden/indra/tools/mailglue/mailglue line 492, <STDIN> line 136. DBD::mysql::db do failed: Data too long for column 'script_id' at row 1 at /opt/linden/indra/tools/mailglue/mailglue line 492, <STDIN> line 136. Unable to get task mail presence from http://localhost:12040/service-proxy/task/5243fc88-9820-3f0a-649c-eb5d4f803003 < 5243fc88-9820-3f0a-649c-eb5d4f803003@lsl.secondlife.com >/mailhost The email is a simple subject of: "123" to rule out any weird text strings or anything with no body text at all and sent to: 5243fc88-9820-3f0a-649c-eb5d4f803003@lsl.secondlife.com (prim key) The Servers should not be failing like this. AI Breakdown of the error: Breakdown of the error message DBD::mysql::db do failed: Data too long for column 'script_id' DBD::mysql: This refers to the Perl database driver for MySQL, a database Linden Lab uses for its services. Data too long for column 'script_id': This is the core problem. The email system tried to save a value into the script_id column of its database, but the value was too long for the column's defined size. at row 1: This indicates the error occurred on the first row of data it tried to write. Unable to get task mail presence from http://localhost:12040/service-proxy/task/ ... This is a secondary error resulting from the first one. Because the initial database write failed, the mail system couldn't get a confirmation (task mail presence) from the internal service running on localhost (the Second Life server itself). Thank you for looking into this. I really need LSL email to work for my system
7
·
tracked
Load More