Jenna Huntsman

In theory, yes - but sometimes, if you're requesting data from an API, it might include header data which you don't need. More often than not, people increase HTTP_BODY_MAXLENGTH to get around this, but that's a bad solution. For example, if I was requesting weather, the API might respond: <?xml version="1.0" encoding="UTF-8"?> <header> <server>Nginx</server> <date>curDate</date> <shard>shardID</shard> <requestUUID>reqUid</requestUUID> </header> <result>Weather in Vancouver - Sunny, 22degrees, Wind 7kph NE</result> The only thing I actually need from that result is the content within <result>, so I could use Content-Range to tell the server to only send the last x amount of bytes of the page, which contains <result>.

Timed demos are the worst. The only thing they do is annoy your potential customers. Do what most major creators do - add an additional prim to the linkset that has the word "DEMO" on it and then position it in a way that it's intrusive enough to make the demo unsuitable for daily use (for example, for clothing this usually involves putting the DEMO box around the avatar's head), but not covering the product. Some creators also watermark their textures with demo, which I think is fine, so long as I can still demo each colour an item is available in. Demo items SHOULD BE FREE! Not this 1L$ crap. The reason why this is done is so that a demo is eligible for redelivery, but IT'S A DEMO - I can go to the store and get another one; which drives traffic to the store, which is what you want! (This isn't a valid reason for timed demos either, mainly if I bin a demo but then have second thoughts, or lose it in inventory, etc). Unpackers: Only for purchased products, not demo items. Use a single script. Don't put about 3 scripts in your unpacker, to poke the user to subscribe to a mailing list or to join a group. If you want to include that stuff, fine, but do it all within the unpacker script itself. That way, we know that the annoying prompt isn't going to interfere with the functionality of the unpacker. Should not have any kind of "loading" or "progress" bar. There's no reason for them, and just waste resources. Should not give the folder with suffixes. This is because I see loads of folders which have suffixes like "(boxed) (unpacked)". Having a suffix to say something is boxed is fine, but when it's unpacked, get rid of it. Detect if added, or rezzed. This is so that we know to either use the script to send the folder (when added), or to set the appropriate touch action, rename the object and delete the script (if rezzed). SL already has a UI for unpacking boxed items, so use that! Use a single texture, no larger than 512px (Use a texture atlas!!). This is so the user isn't stuck waiting for the texture to load to see what is a "Join group" button or the actual "Unpack" button. Ideally, should give the folder to the user IMMEDIATELY upon attaching. Again, so we aren't stuck waiting for the texture to load. Sounds: If you want them, fine, but don't play the sound above about ~30% volume. "Anti-Rezz" scripts are USELESS. Don't use them. They waste resources, don't "protect your content" and mostly serve to annoy users who might be trying to debug fitment issues. That's about all I can think of right now, but I'm sure I'll think of more.

This - but I'd be careful about the 100% transparency part, as newer viewers (port-Performance Improvements) will often discard objects which are 100% transparent (Touch events I believe are still passed, but something to think about!) The method I came up to get around this is to set the touch target to 99% transparent, then apply a half-transparent texture atop that (ideally, with the edge of the texture fully transparent so the edges of the touch target are invisible) - the result will be a touch target that you cannot see, but can always reliably click on to fire touch events.

You may wish to add a "Content-Range" header to your llHTTPRequest to ensure that if the server for whatever reason encounters an error, that it doesn't then send you a large error page (causing the script to crash). Some applications will respond with a 200 status code, even if they were unable to complete the request (instead, sending the user to an error page).

The ZHAO and OC (actually, LockMeister) stuff in the bridge I believe gets used to integrate the built-in AO with common AO-contoller protocols. ZHAO has their control protocol, and LockMeister (now part of OpenCollar) has theirs. Both do the same thing (allow external sources, eg. furniture, to switch off or on your AO).

Yes and no. For most practical purposes, appliers have been superceded by BoM, however, BoM doesn't support material maps. So if you're planning on creating something that incorporates changes to a body's material maps, then you need to use an applier.

That does assume the level of blur being applied is a large amount - note that I did specify the specific DoF settings I use, and noted that I use them with the aperture set to 16 - which amounts to a small amount of softening at objects in the distance, similar to the softening that happens IRL (due to atmosphere conditions, defects in the eye, etc). The settings I'm using make for a more natural image, not a stylistic blur as is seen in most photography (although, will make that style of blur if set to lower aperture values, or zoom in close on an object).

Humans definitely do perceive DoF, however our eyes are very good at keeping our central vision in-focus. If you pay attention to your peripheral vision (especially if you're looking at an object close to you), then you can see objects in your peripheral vision are likely out-of-focus (* normal lens rules apply, objects in your peripheral at the same distance (relative to the eye) to the object in focus will also be in focus). As for performance impact, it's really not bad. SL's DoF isn't photo-accurate in order to be fast enough to be left on, to quote Runitai Linden (graphics engineer) - Another note regarding it's inaccuracy, again from Runitai - And finally - It was also acknowledged that the above performance hit is imperceptible (on most hardware configs) in current viewer versions due to bottlenecks elsewhere. YMMV though.

I've modified my default camera position to be a more modern Over-the-Shoulder style camera rather than the Linden default mile-high camera (lol). My position settings: Debug setting Value CameraOffsetRearView X: -3 Y: -1.65 Z: -0.5 FocusOffsetRearView X: 3 Y: -1.65 Z: 0.25 I also leave DoF enabled, following my 31mm Lens settings with my aperture (f number) set to 16. https://wiki.secondlife.com/wiki/User:Jenna_Huntsman/CameraLensPresets For some extra fun, you can also change CameraPositionSmoothing to say, 2 for smoother movements. (You can go higher, but some people may get motion sickness from doing so)

You can dump the result into the DEBUG_CHANNEL, which will make the result appear in the "Script Error" window, which doesn't have timestamps on most viewers (Except Firestorm)

Any item that makes use of the [Black Tulip] facial animation script. The animations are still present and work fine if played manually, but the script that interfaces with AVSitter borks frequently due to this reliance on an external service.

That error is related to the facial plugin, which (I believe) pings an external server (which, isn't always up). The animations are still present, but the plugin script may or may not work. In my experience, it's not that reliable even when it was working properly!

IMO, the answer is: Maybe, but probably not. It's worth noting that functions like llGenerateKey (likely) doesn't generate unique keys, so if you're using a generated key, then it's 100% possible that the last 4 digits could match, while being a different key. I'd probably look into using a key compression algorithm to leverage more UTF characters to compress a full key, which can be decompressed later if needed. (This thread may be of use, although you may want to replace Ord with llOrd )

Another vote for switching to Alpha Masking. Alpha blending, in addition to the frequent alpha-sorting issues, also does not receive lighting correctly, so more often than not blended hair looks awful in photos as the lighting does not match the scene (think of a really bad photoshop job, aside from it's always attached to your avatar and in realtime!). More often than not, Masking can look just as good (if not better!) than blending for hair, but does require some time to make the tweaks to get it looking just right. But once you get a feeling for how masking works, you won't look back.

To me, it seemed very out-of-character for LL to endorse (even indirectly) these brand-name bodies, as they've been very hesitant to do so previously. Even features which would benefit the userbase as a whole were rejected in-case they "were seen as promoting bodies from x brand(s)". (E.g. adding the ability to filter by compatible body type to MP search). Either they start adding in these usability features, OR they should rethink the SL University program. They can't have it both ways.

The chances are that if that works now, there's no guarantee that it would work in future viewer versions (for example, viewers that implement MeshOptimizer may strip out degenerate triangles completely). To put it in the words of LL engineers: "tweaking the dial until it works" isn't seen as content worth maintaining. There is work going towards implementing custom pivot points, although I'm not sure where that project is, but has been mentioned a couple times as of late. That is the safest bet for what you're going for.

Happy to hear it's back working for you! Yeah, llRequestSecureURL is a pain to work with as you need to ensure that the remote is set up to accept the LL CA, as by default it won't be, thus, requests will bounce at some point in the process whenever the cert is checked.

Yeah, I see that too but all of my in-world object using URLs are just fine, and I can still ping them even with fresh URLs. Might just be limited to requests on port :80 / 443, or requests not going to a specific simulator (i.e. no prefix)

Hmm. Have you tried using an insecure URL instead of a secure URL? (Thinking this as the secure URL uses a self-signed cert from LL, which isn't liked if the cert is checked)

This might be a silly question, but have you verified that the object in-world has been assigned a URL? And that the assigned URL is being pointed to by your PHP scripts? (Thinking this as URLs aren't permanent, which could explain breakage if a different URL is assigned)

Have you tried the other PHP example you mentioned from the Wiki on the other thread? That would at least give us a better idea of where the request is failing (failing at webhost, failing in transit, fail once it reaches LL, etc).

That isn't how "copybotting" works. TLDR: "Copybotting" pretty much anything (except scripts) is possible, regardless of the perms on the item, if it's rezzed or worn, etc.

That seems like a really weird omission, I would have expected that to be included! 🙃

I've just dropped by the location in that LM - I notice that the object in question is scripted - for the sake of argument, have you tried removing the script from one of those problematic objects and see if the problem reoccurs?

The chances are that your webhost may have disabled port 12043, you might want to file a ticket with them to confirm if that port is open for incoming data.