Oz Linden

A few of the features of LSL HTTP usage will be changing slightly as a part of the migration to using cloud hosted simulators. Our hope is that these changes will not cause any problems, but hope and testing are two different things, so... If you are the creator of LSL scripts that use any of the features discussed below, or you use scripts that rely on external HTTP services that were created by someone else, you should test them as soon as possible and report any problems in Jira. As sandboxes where you can test with these changes are deployed, we will post notices in this thread. Some of what is described below is pretty geeky - mostly that doesn't matter because if you can test your scripts and they work (on the new systems), then you didn't make any of the available mistakes and don't need changes. If you are not able to figure out why your scripts fail with these changes, file a Jira and we'll try to help. llHTTPRequest - Outbound HTTP The interface to this method is not changing (aside from one additional error check - see below), but some of its behavior on the network will change in ways that may confuse servers that are doing inappropriate checks. HTTP requests from LSL to external systems have always been routed through an HTTP proxy, and that will still be true, but in the past it was a proxy dedicated to each simulator host; now the proxy will be in a pool of separate servers as shown here: This means that: The IP address of the HTTP client from the HTTP server will not be the same as the IP address of the simulator that the request was sent from; the hostname returned by looking up the client (proxy) address will not be the simulator host. Some timeout behaviors for servers that do not respond quickly enough may change slightly. The body of some error responses from the proxies may change, including the content type. Different requests from a given simulator may be routed through different proxies, and requests from different simulators may go through the same proxy (potentially even on the same TCP connection). Scripts that make more than one HTTP request that overlap in time may see changes in the order that those requests arrive at the server and/or the order in which the responses are returned (ordering has never been guaranteed). The IP addresses for simulators will be in different ranges and unpredictable; if your server is checking whether or not requests are coming from the simulator addresses in our current datacenter, you will need to remove those checks. We will not be able to provide documentation of the IP addresses of simulators or the proxies. None of this should bother the use case of a script using HTTP to communicate with another script; those requests just loop through the same proxies even now, but note the llRequestURL section below. The llHTTPRequest parameter HTTP_CUSTOM_HEADER may not be used to set values for the 'Connection' or 'Host' headers; a check is being added so that any call that attempts to do so will throw an error and abort the request (at present these header names are allowed, but the values are usually not actually used or sent to the remote server, which is misleading). lRequestURL or llRequestSecureURL Note this earlier post on not checking the domain part of the URL allocated to your script. A hostname lookup for a simulator IP address will not return the same name that appears in URLs returned by these methods. That is - looking up the IP address for a simulator name will return the correct address for that simulator, but looking up the name for that address will return a different name. This sort of asymmetry is not unusual, and will be the norm for many of our services in the cloud.

Good idea. Done.

It will be enabled when it's ready; no predictions. We'll post a note to the scripting forum for that and any other script feature changes we need to make when they're available to test.

a, b, and d all probably contributed (the server is different, those are cloud servers, and Aditi does have less activity overall) c is actually backwards - we use a little more http than before (sorry to burst the anti-http bubbles) PLEASE try a large fleet cruise! Tell us how it goes.

If there were a prize, it would be for finding the most interesting reproducible bug

No. All one region and AZ for now.

Because we wanted to provide you with: A bunch of new environment parameters and capabilities (custom moons, etc) Support for customizable day lengths and offsets (sync your in-world environment to your real life) Parcel specific and Experience-mediated environments (that work for everyone, not just those on particular viewers) Sharing and selling environment settings as assets in short, making environments better.

@animats is right ... I'm not familiar with those packages, but if they could be made to use HTTP to pass events into SL objects or the SL objects could call out to get events it could probably be done (watch out for rate limits, though). Depending on the complexity of the simulation, you could also try to just implement it in LSL directly. I'm also curious about what you want to do?

There's no reason to be calling llDetectedKey and llDetectedName more than once each: default { touch_start(integer start_param) { key avatar = llDetectedKey(0); string name = llDetectedName(0); llSay(0,"Hello, your display name is " + llGetDisplayName(avatar) + " and your user name is " + name + "."); llSay(0, llGetDisplayName(avatar) + " touched the box."); llSay(0, name + " touched the box."); } }

Just your account name...no @ anything, and select the grid from the pull down

No, we did not assume you're all dead ... there are more of you than you'd probably think (and we're grateful to each and every one). You certainly should be able to use auctions; if you can't, please capture a screen shot of whatever error you get and file a Jira so that we can fix it.

Sorry, I build SL but don't know much about this forum software.

Sorry ... I'm going to assume that you actually meant '6.4.3' above, not '6.3.4', but since you didn't include the 4th number I can't actually tell what builds you had (the first 3 are not unique). Our viewer doesn't (deliberately) revert any of your settings on an update. One way that can happen is if something (including potentially a crash) corrupts your personal settings file.

The real solution is to download and install the Linden Lab root Certificate Authority certificate and add it to the CA store on your system. Simulator certificates are signed by our internal CA cert, which is included in the viewer. You can download it from https://bitbucket.org/lindenlab/llca/raw/master/LindenLab.crt

See

Apologies ... things were in flux a bit longer than usual and this got dropped. There will not be a main channel roll today. Wednesday we plan to roll all the major RCs to the same simulator maintenance build (assuming it passes QA ...still testing); release notes should be available soon..

Using llEmail to start the conversation does require that you know the object id of the object you want to communicate with, however (the email address of any object is its object-id@lsl.secondlife.com). Another alternative is to assign the scripts to an Experience, and then both will have access to the key-value store, which can be written and read by any script in the Experience. You can either poll it to see changes written by other objects, or use it to discover the current HTTP URLs for other objects and then communicate between them that way.

@Ardy Lay ... you should know better than to report bugs in the forums 🙂 I look forward to the Jira...

Can you be more specific about what "the thing" is? If it relies on Latif, then it probably no longer works, since they passed over 4 years ago

This is a heads-up for anyone who is using llRequestURL or llRequestSecureURL... It has come to our attention that some users may be validating that the returned URLs are in the domain they expect, presumably by matching them against something like 'sim.*\.agni\.lindenlab\.com'. These checks may have been inspired by simulator bugs that at one time or another have caused URLs to be returned that didn't work because some part of the domain name was missing. You should not attempt to validate the contents of the URL. The contents, including the domain name, returned by either of those methods will change when we begin using simulators in the cloud, and possibly sooner. The URLs returned will work (they already have for us in our own internal testing) but you should not assume anything about the URL contents - including the domain name, port number, or anything else. If you need to be sure that the URL as sent to some client is working, we suggest that you implement a simple health check capability in the handler for your inbound requests rather than attempting to predict whether or not through any examination of the URL contents. If you have URL content checks in your system now, we suggest that you remove them as soon as possible.

Done. and yes.

Things are still somewhat in flux, but if we do a full main channel roll on Wednesday it will use the usual Tuesday timing (3am SLT start).

No. Maintaining two completely different possibilities for environments would be confusing, inconsistent, a maintenance and a QA nightmare. You may find that some settings important for performance have been reset by your update; I suggest reviewing them.

EEP viewers obey the day length and offset configured by the region owner. Whether or not the day cycle causes the light and dark agree with the resulting region time depends on how the environment day cycle has been configured. pre-EEP viewers use the fixed default 4 hour SL "day" and the servers translation of the environment settings back to the nearest equivalent in the pre-EEP viewer capabilities, so it's not surprising if there are some discrepancies.

I wasn't subscribed to either list, and that question wasn't copied to me directly, so I'm afraid I never saw it. I had looked at the archives for both lists back a couple of years and seen almost no actual discussion; both had little more than the occasional post announcing upcoming conferences. There's a chance that I could restore those archives from backups and post them if they would be useful, but I'm skeptical that there was anything less than many years old that would be of current interest. My personal philosophy (not LL policy) is to create new forums/lists when a significant fraction of the traffic in a more general one shows that there's demand. I watch a bunch of the existing forums but not nearly all and I have not seen that (certainly the old mailing list didn't have it). If you think it would be actually used we can certainly look into creating it, but an empty forum doesn't help anyone. What do you think?