Monty Linden

Improved but not perfected. Would love to burn it down and start over.

Two(ish) attempts have been made. Third time's a charm. It's all bespoke back there right now.

"This page was last edited on 18 March 2011" and SHA-1 fingerprints. Yeah, something like this needs to happen. But there's more to it than just standing up a Jabber server implementation someone shoved up on github.

Literally true in my case.

Bugsplat is the crash reporting tool we use so you are getting hard crashes in your session (which you probably know well). Since this is recurring, I strongly recommend getting a support ticket going. These crashes may indicate a problem needing escalation. For yourself, you might find a hint as to what is going wrong at the very end of the viewer log file. And this may be a perfect opportunity to try out other viewers. The specific problem may not be present in other builds.

We ended up with forehead hair and nasal wrinkles so we're going to take another swing at it. Check back in in '25.

It may clear up after some time but a support ticket might move things along faster. But now you know it isn't the viewer.

Okay, that shows Akamai at work. This will often clear in a few hours but you can also file a support ticket, including that information, and things may improve more quickly.

The answer is likely in FS's log file but a quick visit to https://login.agni.lindenlab.com/cgi-bin/login.cgi in your browser may return an error page with a hint (Reference ID).

No interns can be blamed for this event.

That one. If you delete caches, you may have to revisit. A fix was deployed to several RC channels today so those are available as well.

No, just a transport problem. No inventory will be tweaked by this fix.

Well, now we know what was in the release: non-sparkling water.

Real fix is coming but if you teleport to the Debug1 or Debug2 regions, you should pick up and cache some textures that will fix it temporarily.

Believe the version on RCs is moving to main today. Will prod someone for an update.

Suspected I'd find these: https://jira.secondlife.com/browse/BUG-230173 https://jira.secondlife.com/browse/BUG-229070 https://jira.secondlife.com/browse/BUG-229022 https://jira.secondlife.com/browse/BUG-4706 Don't like where some of those ended up....

Probably best to start with a support ticket. There may be some ISP problems in .de.

Too late, we're doing this. NCML (Notecard Markup Language) with NCCSS (Notecard cascading style sheets). Might have to deal with 2K38 first... Humor aside, Markdown support is an interesting idea but might not have the power desired by the OP.

Thanks! The http-in really needs work. The text is left over from the development phase and I can actually hear the developers' specific voices when I read it.

The wiki needs love and a lot of it. The first two refer to http-out, the last to http-in. And the second is ambiguous. There are four bodies involved: http-in request, http-in response, http-out request, and http-out response. Six if you include xmlrpc but please don't. We are going to remove it someday. Those bodies have different limits on them and this information is not clearly presented. And then those limits double in number because we made the limits under mono slightly different than under lsl2.

Ah, that's http-in, a different pathway. Yes, that's limited to 2K request bodies. https://wiki.secondlife.com/wiki/LSL_HTTP_server#Other_Limitations

Since we're talking about request bodies, I modified the request: key make_request() { string payload = "1234567890" + llUnescapeURL("%0A") + "\n"; payload = payload + payload + payload + payload; // 48 payload = payload + payload + payload + payload; // 192 payload = payload + payload + payload + payload; // 768 payload = payload + payload + payload + payload; // 3072 payload = payload + payload + payload + payload; // 12288 return llHTTPRequest("http://www.example.com", [ HTTP_METHOD, "POST", //HTTP_MIMETYPE,"application/xhtml+xml", HTTP_MIMETYPE, "text/plain;charset=utf-8", // HTTP_BODY_MAXLENGTH, 4096, HTTP_BODY_MAXLENGTH, 16384, HTTP_VERIFY_CERT, FALSE, HTTP_VERBOSE_THROTTLE, FALSE, //HTTP_CUSTOM_HEADER,"","", HTTP_PRAGMA_NO_CACHE, TRUE ], payload); } And captured the outbound: POST http://www.example.com/ HTTP/1.1 Host: www.example.com ... more headers ... X-SecondLife-Owner-Name: Monty Linden X-SecondLife-Region: LindenWorld B (237824, 244224) X-SecondLife-Shard: Production Content-Length: 12288 1234567890 1234567890 1234567890 1234567890 1234567890 ...

There are two bodies in a POST: request and response. LSL itself is the cap for the request body, you get about 32K characters there. The response body size is limited by HTTP_BODY_MAXLENGTH whose maximum varies based on script VM. That second one appears to be working as spec'd. This script shows the 4K and 16K limits working and is based on your POST pattern: key make_request() { return llHTTPRequest("http://www.bing.com", [ HTTP_METHOD, "POST", HTTP_MIMETYPE, "text/plain;charset=utf-8", // HTTP_BODY_MAXLENGTH, 4096, HTTP_BODY_MAXLENGTH, 16384, HTTP_VERIFY_CERT, FALSE, HTTP_VERBOSE_THROTTLE, FALSE, HTTP_PRAGMA_NO_CACHE, TRUE ], ""); } default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(0, "Touched."); make_request(); } http_response(key id, integer status, list metadata, string body) { llSay(0, "Length of body: " + (string) llStringLength(body)); } } Look to your web server for likely reasons.

We use clusters of hamsters.

Not getting sufficiently specific information back on that error right now. So I'll have to give you a general guideline: there's often a time-based component to this that will clear eventually. The time isn't precise but is on the order of minutes-to-hours. If you can find an alternate path to log in to the web (e.g. cell/mobile, public wifi) and file a support ticket, that should be done.