Gwyneth Llewelyn

Look, the whole process of acquiring items for your avatar to wear is insane. It draws from so many different sources... For instance: as soon as LL comes up with some technical innovation, content creators turn it into fantastic things. However, that isn't always straightforward. In the ancient days, LL thought that they could get away with merely having painted textures on top of avatars. Okay, so, well, people wanted to wear jackets over T-shirts over their underwear... so, LL introduced many 'clothing layers' and changed the viewer technology to pre-bake your avatar's 'whole texture' (actually, three — head, top, bottom) and send it to everybody else, as opposed to sending all the textures separately, and allow each viewer to bake it independently (which didn't work that well). Then we started getting transparencies — of two different kinds. Then LL toyed with the idea of having materials (we had about a dozen or so) but abandoned the plan. By this time, people were already wearing prim shoes and prim hair — because you simply couldn't do anything very realistic by just painting textures over your body. Prim clothing brought a bit more tridimensionality to clothes, but it also meant that avatars were starting to wear things constantly, which was not quite what LL originally had in mind. Obviously, I don't know what these ideas were, but you can get some hints from very early movies of SL. It's clear that "valid attachments" were things like weapons or a jetpack or any kind of discardable items, to be used in some sort of "experience" or "adventure" or "game" or... whatever... but not exactly something that was supposed to be permanent. Still, that's what people started doing — 'permanent attachments' which were used, well, as part of your body or your clothing. Which, in turn, meant that you would now have items in your inventory that were yellow cubes but were not 'regular objects', but rather 'clothing' as well. That started to become... confusing. And from there, we jump to flexiprims, to rigid sculpties, to mesh (in its many variants!), and, ironically, 'bake on mesh', which is sort of how it all began... but on a completely different avatar body! All of that is now spread across over inventory, of course, and it's all small yellow cubes. You just need to figure out how to set them apart from, well, objects. It's a bit easier if you read & write English with some fluency, of course, since the vast majority of items will be labeled in English. Okay. Now that's the positive part, so to speak: content creators incorporating new technology into their creations, and doing more and more things that LL never even remotely dreamed about. Then we have the dark side. These are all the very complex tricks that content creators have to come up with to deal with technical limitations imposed by LL — for whatever reason — and figure out ways of working around those limitations. Here is an example: buying things. The way it was designed to work was simply to put your items inside a prim and set it to sell its contents on touch. Easy, right? The problem is that if you have dozens of items to sell — and each in different colours, too! — that's a lot of prims, and that's a lot of tier to be paid. Therefore, vendors became popular very early on, because you could just use 2-3 prims and let customers search through all your clothes. Unlike selling a prim's content — which does not require any scripting at all — vendors are slightly more complex items. They need a bit of scripting to shuffle textures around and deliver the item currently selected after receiving a confirmation of payment. And here the problems start: while, script-wise, you do get a special event confirming that a payment was made, as well as showing up on your transaction logs, and you can then proceed to send an item to the buyer (because you know you've received payment!), you cannot know if the item was ever delivered. In fact, once the item is sent to the buyer, you don't have any more information about what happened. The buyer might have crashed, and the payment went through — but they never received the item. Or they might have a very cluttered screen (most of us do), and fails to click on the dialogue box to accept the item (and it times out). Or you might simply click on the wrong button for whatever reason, cancelling the delivery. Or... well, you can see how tricky this is, so many things can go wrong. All that could have been avoided if LL added just a line of code to confirm that someone received the item! So, what did content creators do? They devised this two-step (and currently three-step) mechanism to guarantee that you really got the item. First, you receive a box, which started as being styled as a "gift box" which you dropped on the ground to unpack. Besides the cuteness of the experience, the important thing is that, once that gift box is rezzed, the script inside can immediately notify the merchant who sold it — they now know that their item was delivered, and was delivered to the right person, and they have it in their inventory (so, they can complain, but the merchant knows that they cannot complain that they didn't get anything!). Dropping boxes on the ground meant owning your own land, or using a public sandbox, or, well, some very brave merchants even allowed customers to temporarily rezz their boxes on the floor of their shops — but, naturally enough, griefers immediately abused that, by bringing their scripted griefing tools with them and creating havoc. So — either you had your own place (and that meant you couldn't even test whatever you've bought until much later...), or you went to a public sandbox, avoiding griefers left and right, just to get your little item out of the box. And at the end you'd get two yellow cubes in your inventory — one was the box, the other was the actual item you've bought. With luck, the content creator had thought well in advance and made it clear which is which. Some, however, just named the item inside with the same name as the gift box. Confusing. You'd delete the wrong one — or kept both, just in case, and were constantly attaching the box to your avatar's head, not the item you bought. So confusing! Later, this was slightly improved with the "shop bag" kind of idea, i.e. instead of rezzing a prim, you'd attach the prim to your avatar. That works as well (and technically you can even use the same script for both cases, so if someone rezzed the handbag in a sandbox instead of attaching it, they would still be able to get the item inside), but with two catches. Some misguided content creators required the "shop bag" to be touched to activate it (as opposed to immediately sending you the item when you attached it). This is usually okay... unless the item gets wrongly attached somehow, and you cannot see where the bag is (maybe it's upside down, floating over your head or under your feet, or even rezzed inside your avatar's body). You might now need to be an expert in turning the camera around just so in order to find where exactly the bag is and touch it on where it's supposed to be touched (sometimes it's just part of the bag that can be touched... it all depends on the content creator's whim). The second catch is that formerly you could just attach one item per attachment point, and that meant that if you were extremely unlucky with the choice of attachment points, you could wear the bag and lose your clothes — or part of them — and it wouldn't be immediately obvious what went wrong — or, worse, you might not even see what was 'displaced' by the bag and cannot remember what you had there before. Not to mention that, on laggy areas, buyers might not see the box or bag being rezzed, and so rightfully complained to the merchant, who had a confirmation of delivery and therefore might not be very willing to replace the item (or perhaps have no time to answer technical support questions related to the user interface...). Also... everybody would know what you have bought by just looking at the box or bag. That's fine if you buy a plain vanilla piece of clothing. But perhaps you're not that fond of showing off that you've just bought the latest 'sex toy' for your private dungeon. No privacy! Confusing? Aye, quite so. It only gets worse, of course. Content creators then realised that, in order to avoid boxes not being rezzed, the easiest way would be simply to send people a HUD, and — hopefully — add some short explanation of what to do with it (i.e. "wear me to unpack"). Cool — no more privacy issues for sure, and no need to worry about where that attachment went. But it also meant that, unless you know what to expect, all of a sudden you might get a huge prim blocking your view which you haven't a clue about (since content creators will use the highest-resolution textures they can, and that means these will take time to rezz — and be just a very blurry obstruction on your vision during that time). It might also displace one of your favourite HUDs, too, making things even more confusing. But now the horrible mess really starts. Very early on, content creators figured out that if they placed scripts in their items, these could be used to enable lots of interesting things. For example, heels could be scripted to play sounds; clothes could change colour; bracelets could be resized without the need for selling them with modify permissions. That was cool in itself, but what was even cooler, was the ability to also script the items to inform the merchant that they weren't merely delivered (which you got from the HUD attachment), but actually used (which you got when attaching the bought item to your avatar). Not to mention, of course, whatever other metrics the merchant would be interested in — but let's not go that way! Initially, those items would be programmed/configured using text chat commands — first in public chat (argh!), later on private channels — but they were sort of awkward to use (if I got L$1 for every time someone typed /ao on in public chat or even on group chat...). Content creators moved on to complex dialogue boxes instead, but, due to the extreme limitations (and awful aesthetics) of those, they quickly moved on to... HUDs. HUDs, mind you, are a tribute to the imagination, creativity, and technical prowess of content creators. Most of them (and there are tons of varieties!) work really well, they work all the time with next-to-zero bugs, and they get more complex every day. Some have extensive manuals and video tutorials, attempting to explain most of its features — a list that grows and grows, to the point that the most complex systems out there have multiple HUDs. I'm obviously talking about the crème de la crème items on the market — coming from the creators of Bento mesh bodies and especially heads — which sport the most complex and thorough set of configuration possibilities, literally layers upon layers of things you can do with your item, all of which fully scripted, and being able not only to interface with your HUD, but also with the HUDs of others — so long as you have them properly configured, of course. And some of them play nicely with your animation overriders, and vice-versa, animation overriders can also 'talk' to your items and 'make' them 'do things' (think couples dances, hugging & kissing, and so forth). The proliferation of different Bento mesh bodies & heads (even if there is a clear market dominance of a few) means that content creators working with apparel and avatar accessories will need to support all those different types — or, at least, all those who dominate the market. Shoppers, on the other hand, need to figure out which kind of content they're supposed to buy for their avatars — and understand why something designed specifically for one type of mesh body will very likely not work on a different type. You have to learn to deal with mesh, rigged mesh, and fitted mesh — and understand which one is appropriate for your particular mesh body. Also, you need to understand that most content creators will expect their customers to know what they're supposed to be buying. Fortunately for us consumers, it's customary to sell multiple meshes (for the different body types) as a single item, so that, when you switch mesh bodies, you can still continue to use your favourite item of clothing. But... sometimes, it's not obvious to figure out which is which. If a merchant sells an item labelled as "Maitreya only" what exactly does that mean? Oh wait, Maitreya just has one female body, right? Wait, no, there are two... there is Lara, and there is Lara Petite. Will they work with the same type of clothing? And now there is also a new Lara, Lara X, which is not compatible with the "old" Lara, but every existing Maitreya customer is entitled to get the Lara X for free, so the content creator can assume that "Maitreya" means "one of the two, just pick the correct body type when using this dress"? What about, uh, Lara X Petite? And there is also the free and open source Ruth 2.0 project, which nobody uses (except on OpenSimulator-based grids, where there is nothing else), but which is sort of compatible with the original Maitreya Lara, but not with the Lara X... That's cool — the content creator says — but you have a Lara mesh body, you also have a Lara X mesh body, so I only need to include one of those in my vendor. It's, well, just "Maitreya" for me. You, the buyer, just need to make sure you're using the right mesh body. Aye, that's all very fine, but what about all the former content which I have, predating the Lara X, and which will work only with the "original" Lara? Some apparel designers are kind and generous and willing to give you an additional Lara X-compatible version of their items, also for free — but this is neither widespread, nor even mandatory. The reverse, however, is not true, i.e. there are lots of content creators doing their designs only for the Lara X, and refuse to do it for the Lara (this has mostly to do with the style of their apparel, which will work only well with the oversized hips & bottom and those meshes that are specifically designed to allow them). Note that this "size mess" is not new. When mesh became popular, content creators sort of agreed to do five meshes in different sizes, so you could pick what would fit your avatar's shape best. Only, like in real life, the measurements were not really a standard, and each content creator had their own ideas of what a "size S" or "size XL" was. In most cases, since you got all five sizes packed into the delivery box or HUD, you could just experiment and see what fitted your avatar best — not unlike what we do iRL when we're unsure about the sizing used by a brand we're not familiar with. But, well, it wasn't exactly easy. With full Bento meshes, things are a bit easier in that regard — just to be more complex on other areas! I trace this whole sizing issue back to the days when Tinies began to be popular (requiring special skeleton-deforming animation overriders) — around 2005. It was conjectured that this "fad" would not last long, because all content had to be redesigned to fit Tinies. That, however, didn't happen. Famously talented top content creator Damien Fate launched their "Loco Pocos" line of cuddly Tinies, which were actually very reasonably priced (for the time), because he hoped to make some real money selling all the clothing and accessories that he made for those Tinies — and sold in (almost) exclusivity through his shop. Such concepts were seen as not having a future... but here we are, almost two decades later, and while "Loco Pocos" has been long gone from SL, Tinies continue to be around, have their own body meshes, and specialised clothing, furniture, vehicles, houses etc.— all made specifically for them. So, as a buyer, you have to be sure you get the content which is appropriate for your avatar, and learn (sometimes the hard way!) what kinds will not work together at all (or only very, very badly). All right. Anyone who is reading this is familiar with all the above, and much more. At the time of writing, Firestorm was still alpha-testing the new renderer (the one that works with PBR Materials), and since that's the most-used viewer to connect to the SL Grid, content creators have been reluctantly releasing some of their more recent items with the ability of using PBR materials as well. Most SL residents cannot notice any difference — only those sticking to the Official SL Viewer will get that awesome experience — but it's fair to say that content creators have been preparing for this dramatic change since late summer 2023. And that, in turn, means new things to learn to configure; new HUD options or even new HUDs; new content overall, which might get revamped and more sophisticated, and more difficult to configure; and so forth. Consider all the above and think of all aspects of the daily usage of Second Life which consists in selecting the correct overall configuration for your avatar. I mean, it's not just point and click, or drag item X on top of your avatar — as we used to do when clothes were just a texture, showing in Inventory with obvious, easy-to-identify, coloured icons. "Configuring your avatar" — playing dress up, if you wish — is, today, an exercise in complexity beyond belief, and it just gets worse and worse with each new generation of content that gets released. ... and you're still questioning why new residents "don't get" the inventory...? Second Life, these days, has very likely the most complex user interface ever designed for a 3D virtual world environment — a design which Is not "imposed" upon us by Linden Lab, but rather by the community of residents themselves. LL is to blame for many things (notably for the way they do not allow us to change the item'd ico

All I can say is that I seriously hope that, once the closed alpha testing with Premium Pro residents is deemed to be finished, there is a closed beta testing with regular Premium residents 🤣 Especially those who have been faithfully paying for their Premium account for the past twenty years (well, 19½...). <hint, hint>

@Marcthur Goosson as mentioned briefly by @arton Rotaru, the extra blue is kind of a "feature" in the sense that it's a "well-known" issue, fully documented on the SL Wiki by the Lindens themselves, and I quote: So, essentially, the blue sky tints everything blue, because... the sky is blue 🙂 One wonders if you could somehow compensate it with a local orange light (being the complementary colour of blue). Or maybe by tinting the sun orange?...

Aye, two excellent reasons for allowing video uploads 🙂 After all, LL already limits uploads to 4.88 MB (at the time of writing) — this would be a good way to minimize abuse and leave videos at a manageable size. Then again, I've noticed that, at the bottom of the screen, it now says: Accepted file types: gif, jpeg, jpe, jpg, png, webp Yay for including WebP (love the enhanced compression!), but there are so many more file types that would make a lot of sense (think HEIC or AVIF), now that we're starting to see HDR implemented in SL

@Nalates Urriah Honestly, I wish I still had the massive amount of free time I had in the olden days Where is all that free time gone, I ask myself?... Oh well. I guess it's just old age; I'm not 30-ish any longer... @Love Zhaoying naturally enough, you're right — there is not really a "standard" per se, and each community forum does things differently, and gives their users more or less formats that they can upload, within certain limits. I'm not questioning that. I was actually just asking if, by any chance, these community forums (and not any others) supported video uploading as opposed to merely embedding them.

This just shows why the next item in line for LL's rendering pipeline is... the terrain 🙂 I mean, to my untrained, un-artistic eye, the only thing I can say is that the SL item looks slightly more dull (but that can be due to the lighting, not how the material reacts). But the terrain — oh my. LL really, really needs to put some serious effort there! (Note: I'm well aware that they are working on PBR materials on the terrain as well) - Gwyn

I know, I know, I'm bumping an old thread, but I found this comment incredibly interesting! Not having taken a look at the viewer code (well, I just glimpsed a few lines here and there), I thought that the single-thread solution designed for single-core systems of the late 1990s had been deprecated... oh, at least when the SL Viewer was bumped to 2.0. We're now close to 7.0... and they're still on just one thread?! So, are there non-classic SL viewers then? Which ones?

There is a lot of things I resent on this thread! And to let you know how unhappy and angry I am, I will even be ironic, or perhaps even sarcastic You've been warned! 😠 Firstly... you can change your last name for a fee. In fact, this is a very old feature (use to be called "Vanity Names"), dating back to 2009 at least. For a long time, this was the only (expensive) option, depicted here on the SL Wiki: https://wiki.secondlife.com/wiki/Linden_Lab_Official:Custom_Name_Program (last updated on 2011) But nowadays it's much more cheaper and straightforward. There used to be huge advantages in limiting the choices of last names to a single integer, back in '02. Such advantages may not be so apparent today, but that doesn't mean that they're useless. With 64-65 million users registered on the SL database (which LL cannot simply dump off their database, as these might have content somewhere that require displaying the creator's name), having 2-4 bytes (I have no idea if they use 16-bit or 32-bit integers) instead of a dozen characters does make a difference. Well, at least, it did. And there were many other technical reasons for this, two decades ago. If I only could remember a few more, I would tell you so. No, just because my memory eludes me, doesn't mean that those reasons are not important! One of the cute ideas that LL had was that this allowed "families" to form — okay, so they were complete strangers to each other, right, but at least they would have something to break the ice — "hey, you've got the same last name as I do!". There were estill ven a few "aristocratic" families — last names used by very popular people (the Kardashians of SL!) and/or groups of powerful content creators, such as the Fairchilds (scripting, land baroning) or the Kunglers (fashion). There were surely more, but I don't remember them any more. Okay, so, I'm well aware that so few of those 64 million registered users are still around (just 1% of those still log in regularly, and 0.1% are online) that, these days, very old last names usually just have one or two members in it. Many have zero. But that's irrelevant since LL is not re-using old last names — unless, of course, you pay for them. Also, the "family thing" was as good an idea as Facebook's placing everybody living in the same city in the same group (aye, that's how they started). Neither idea caught on. Facebook has long abandoned theirs (why should you be in a group with 11 million fellow New Yorkers, with whom you don't identify with anyway?), and LL technically had... then reintroduced them again... uh. Right. Old last names are valuable to old residents! SL is now a vintage product! (It is more than 20 years old = vintage, per definition [never mind that this article feels like it was written by ChatGPT]) That means that these old last names are part of our identity, and we all know — or should know — that Second Life is essentially about identity (even if you change avatars several times per day, or have an array of alts to log in with, that's irrelevant — "identity", in this context, does not mean "unique" or "just that one", but rather the relationship between what you call your self and your visual representation of it as a SL avatar, which is not limited artificially with things like "you can just have one avatar to identify with" or "you have to always look like yourself" or any such irrational limitations which make no sense in a synthetic 3D environment). Oh, and I have turned the sarcasm mode off for this parenthesis. Or perhaps not. You decide!) Having silly Unicode-based Display Names that are impossible to pronounce is part of our identity. They serve no other practical purpose except, well, look weird. Or ugly. Or funny. Soon they'll even have emojis in them! Well, see the point above: it's just another thing that is related to identity. The same applies to fancy group titles too, of course. None of these are important for technical reasons, but they are important for expressing our identity online., Also, if Elon Musk is allowed to name three of his children X Æ A-Xii, Exa Dark Sideræl Musk, and Tau Techno Mechanicus (and you should look up how their mother — his former partner, Grimes — signs her name on 𝕏/Twitter...), why shouldn't I name myself ɥʇǝuʎʍƃ, 已丗ㄚ几㠪十卅, 𒋝𒉼𒌨𒐖𒀼𒈦𒀂, ꗱⱲꔇꖦꗍꖡꖾ, or ᘜᗐᖿᐱᗕᐪᕼ? (note: all are pronounced [ˈɡwɨ̞nɛθ]; use the Welsh voice to test it out). I hardly understand why some of you are complaining that "other environments have user IDs, SL just has user names, and that's a mess". Uh... say what? Last time I checked, my avatar's user ID was still d2cdf457-5027-4887-abd8-573c62a85226. That UUID is, indeed, unique, and my avatar's exclusive ID forever. The avatar name, well, that can change. Or maybe not (I'm not interested). But it's exactly like most environments out there: your avatar has an UUID, also known as "avatar key", and that's what matters for the (many) databases. The name is just, well, incidental. If you're still skeptic, consider this: any LSL script can very easily retrieve an avatar's UUID. But if you want to get the avatar's name, that's another story. Most scripts can get the avatar name reasonably quickly if the avatar is inside the same region, because, well, then it's already on the simulator's cache. And while there are LSL functions to retrieve the avatar name directly from the databases, when such a name is not locally cached, there is a perceptible delay in retrieving it (and the operation can even fail, although, these days, the servers are waaaay more robust). I mean, it's not that often that you get an object where the creator name is (Loading...) or ????. It still happens, once in a while, especially in very, very old and little used objects which have to be retrieved from the "deep storage" — especially when on a very laggy region. But these were quite common in the days of olde. Whereas avatar keys — their UUIDs — would be gathered instantaneously. So: get your facts right, fellow residents! SL has IDs (quite a lot of those, in fact), and avatar names are indexed by UUID. It's actually some things out there that use email addresses (which are unique per definition!) as a way to represent a unique key. That's a possibility which was quite uncommon in the early 2000s, mostly because UUIDs are just numbers with 128 bits (no matter if they have a fancy, textual representation), which, granted, is not enough the total particles in the universe (328,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000), or even atoms on Earth (130,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000) but it allows for us to get 340,282,366,920,938,463,463,374,607,431,768,211,456 distinct avatars, which should be plenty enough for the years to come. Last but not least... I'm a bit tired of those who claim that LL was "clueless" back in the early 2000s and therefore "did it all wrong". I'm sorry, I've heard that being repeated year after year after year; 99% of those who were so fond at Linden-dev-bashing are, fortunately, gone (many, long ago, and they're not dearly missed). It is always claimed that LL ought to have hired a few talented, real game designers, used whatever 3D rendering engine was popular back then (possibly the Unreal engine), and applied whatever techniques are common for 3D FPS Triple-A console games. That is all very fun and nice to say, but... Second Life is hardly build (conceptually speaking) as a "3D FPS game", even if it looks like one. Rather, it is much more akin a shared Maya/Blender experience, using lossy datagram transmission between what-used-to-be-medium-end (or even lower) machines. We have a few words to describe what this is today: some call it collaborative computer-assisted design; in RL architecture, the closest we have are tools for sharing a common environment using Building Information Modeling (BIM). Some of those tools, in 2023, are even able to manipulate 3D content in almost-real-time, shared by a (small) group of engineers and architects placed on their internal 100 GBps Ethernet network; most of the time, however, "batches" of changes are exchanged using a quasi-standard file format, which is sent to a central database and then retrieved individually by each workstation, and the 3D model updated. One might argue that this is orders of magnitude more complex than Second Life. Well, of course it is; people design, monitor, and do maintenance on airports and hospitals using this technology; and to get real-time updates, well, you need to have a server farm provided by Nvidia, since they pretty much "invented" what they call "Digital Twins" (aye, avatars are included), and they call the technology behind it "Omniverse" (users are called "Omnivores"...really... ha ha?). You can watch the videos of this amazing technology, but be warned... you won't really be much impressed (a digital twin of a factory with thousands of assets? Why, we do that kind of thing routinely on every region of Second Life...): what they call "photorealistic assets" are not that much more advanced than what the best content creators can do in SL, and have been doing for the past decade or so. Any arguments regarding "oh, but this is another level of complexity we don't have, since each and every item on Nvidia's Omniverse is fully parameterizable and configurable in real time, and so forth". Really? So what? All objects in Second Life are parameterizable and scriptable. Granted, LSL is a kind-of-crappy programming language, compared to anything Nvidia might be using. But they have not been around in 2002 with their "Omniverse". Linden Lab was. And they didn't have the server farms that Nvidia has today. They just had a handful of run-of-the-mill co-located servers stashed somewhere in a data centre in San Francisco. And they did wonders back then. Arguably, they were twenty years ahead on what the state-of-the-art currently is. And that's no mean feat. Oh, you might argue that we had much better-looking FPS running on high-end consoles back then, with snappy 3D graphics and real-time multiplayer networking. Sure we did. But that wasn't a spectacular breakthrough — rather, just an evolution in terms of what graphic cards could do in the 2000s which was impossible in the early 1990s. Sure, Nvidia was one of the major players that also drove the tech to do amazing things even on a lowly desktop PC. Sure, Philip "Linden" Rosedale is even humble enough to admit that the reason why he founded LL in 1999 and not in 1989 or 1979 was that simply the kind of hardware allowing SL to be possible didn't exist back then; it was just around the end of the millennium that, thanks to Nvidia & AMD (and later Intel...), consumer-grade graphics cards were able to deliver the kind of sheer GPU power for that kind of environment. And in case you've already forgotten, the technological breakthrough wasn't even the renderer, which, arguably, by that time, was already a bit dated compared to the "competition". But that's because this so-called "competition" simply worked with pre-generated scenes and content stored in the local disk, having been previously downloaded (or copied from a DVD). That's what allowed "instant", real-time scenes with avatars running around shooting at each other — in glorious 60 FPS. Second Life would take years until it managed to do something even remotely like that. But they were unbeatable in terms of simultaneous collaborative 3D user-generated content in a visually contiguous environment where everything was created by the users and could not be downloaded in full before a scene was generated. The breakthrough, indeed, was 3D content streaming — something that nobody did at the time (because you would have to be suicidal to do that in the middle of a fast-pasted multiplayer FPS). Keeping players in sync with each other was tough enough (it still is!); nobody had a technology allowing the content to be downloaded-on-demand, and nobody even thought this could be a good idea. Philip thought otherwise because, well, he was a pioneer (one might even call him the inventor) of audio streaming solutions for low-end networks. Since the only way to achieve the kind of collaborative environment that LL had in mind required dealing with unreliable connections and partial content — for which a streaming solution is perfectly adequate, because that was being used already, just not for 3D collaborative platforms (because they didn't exist... yet!). One of the many reasons why the SL renderer is such a legacy quirk from the olden days of yesteryore is because it's the only renderer available in the market that was deigned to work with incomplete data and nevertheless render whatever it managed to download as soon (and as quickly) as possible … ideally, a full scene minus highly-detailed textures and other assets (such as sound, for instance). Back then there weren't even any other serious contenders. There was Active Worlds (still around) and things like there.com (not around any more). None were really a "replacement" for Second Life (at least not in the sense that they could perfectly and flawlessly emulate what SL was already able to do back then). Later we had Croquet and OpenCroquet and a few more, all struggling to offer something similar to the kind of experience you could get in SL. It wasn't easy. It was even harder to find a business model for the long term (assuming, that is, that they expected a return in the financial investment made in the development of such platforms); none found that in a reasonable amount of time and ultimately disappeared from the market... In conclusion... The idea that SL is sloppily programmed "by people who had no clue about what they were doing" is, well, just a myth. An urban legend which got spread across several different paths in SL; a meme. We should be wary of considering all Lindens, at all times since LL's founding date, a "bunch of incompetent idiots". There have been a few, sure, now and then. It's also important to take into account the enormous difficulty of trying to hire a minimally-competent 3D content creator in the San Francisco area — where rents are sky-rocket high — who isn't already working for Big Tech in neighbouring Silicon Valley. I mean, if you're already working on high-end graphics engines at a much more prestigious tech company than Linden Lab, who nobody really knows. It won't be merely a question of paying better salaries. For a top programmer, it's also fundamental to have a history of having worked for industry leaders in the field... not for former VC-funded startups with little recognition in the overall market.

/me *blushes* ... well, that's what we are. In a way. Not so seriously as it sounds! And, in the good democratic spirit, the name was chosen from several others through a referendum. I remember distinctly voting against this proposal. Alas! The name stuck, 15 years ago, and now I guess it's way too late to change it, anyway.

... but even your ISP cannot tap into a connection to the SL forums, which is encrypted. :-) So you don't need to worry when posting here. Mind you, your ISP might be able to see something of what you do in SL, because not all communications between your viewer and the grid are fully encrypted. Most are (like downloading assets, such as mesh, textures, sound...) but I'm not 100% sure that everything is fully encrypted end-to-end — most notably, my guess is that positional information of your avatar within a region might be 'grabbable' by your ISP. Assuming, that is, that they knew what they were after — it's not that easy to understand the SL communications protocol just by looking at it, if your ISP's techs never heard of SL before — and that they were willing to spend a considerable amount of time doing so. Why they would ever bother doing that is wildly beyond my ability to imagine. I suppose that if they had been contacted by the local authorities to investigate your account, because you're the subject of a criminal investigation, well, in that case, I'd guess they might be coerced to do that if they were served a warrant — again, assuming you live in a country where there is a Rule of Law and a general following of the Universal Declaration of Human Rights (if you don't, all bets are off!). So, the likelihood of your ISP having the option of monitoring and filtering your connection is next to zero (or about the same chance of getting hit by a micrometeorite while being on an airplane kidnapped by terrorists which is heading towards a city without vowels in its name on Friday the 13th at precisely 21:04 local time — which does not have a zero chance of happening, but so close to it that it becomes irrelevant). Also, just because something is technically possible, it doesn't mean that it is actually commonly done. Here is a good example: it's 'technically possible' to try to break into your account by randomly guessing your password, using a brute-force attempt — basically, a long list of common passwords and their variations. However, this could require billions or trillions of attempts, some of which might take as little as a second each, but still... a trillion seconds is 31,710 years. So, while technically possible, it's hardly likely that anyone would bother to do that (and wait 31,710 years to find a match), unless they had exceptionally good reasons for doing so. (And in any case your login would get quickly blocked after a few false attempts, thus spoiling any chance of success).

All of the above makes sense, sure, but, in that case, we'd like to have at least some basic formatting options on the profile. The basics — bold, italics, bullet lists, and external links. Because doing a full-blown WYSIWYG editor in pure OpenGL (as LL is so fond of doing...) is a lot of work, they could stick to good old Markdown instead — which would be perfectly adequate for most purposes...

Hi! I've been experimenting with a few file formats that can be attached to the SL Community forums. We all know about JPEG and GIF. However, these days, there are a gazillion more (and better!) formats. For instance, this is a file uploaded in Animated PNG (APNG) format, which is allegedly supported on almost every browser except IE (if you just see a static image, it means your browser doesn't support APNG): Naturally enough, there is no documentation about the support of APNG. This is not very surprising: after all, APNG files use the very same .png extension (and graciously fall back to the first frame...). Thus, APNG should work on any website that doesn't resize the image or convert it to an 'internal' format. There are some exceptions, depending on the kind of backend is used. For instance, if phpBB is installed with ImageMagick as the resizing engine, ImageMagick will have no issue with dealing with APNG correctly. Other graphical backends may simply not support anything beyond the first frame (while happily accepting GIFs — others will not even allow that, of course). The trend, however, is not only to resize images (sometimes on the fly, for the benefit of mobile users), but to convert it to a completely different format, thus destroying the original image in the process, and whatever 'special features' it might have included at some point. The reasoning behind this is the fear of hackers surreptitiously exploring some bugs (usually memory buffer allocation) in order to trick the webserver to run some sort of malicious software. While this is harder to accomplish than one might think, the truth is that image resizing and/or format conversion will get rid of any malicious code (possibly trashing the image in the process, but hey, that's what you deserve if you're attempting to crack a system...). Thus, restricting image file formats to just a few, or allowing a few more but ultimately converting everything to a single format (such as plain, old, boring, inefficient JPEG...), is a simple (but reasonably effective) method for virus & malware destruction. Sadly, it also means that the options given to users is limited. JPEG, GIF and even PNG are ancient, obsolete formats. They just have the advantage of being widespread. Nowadays, however, we have far better encoding systems. Just try to convert a WebP or HEIF image to PNG, and watch how much the file size will grow. Reversely, convert an image (even a PNG already minified by TinyPNG) to WebP or HEIF (or even to the venerable JPEG2000 — used internally by Second Life itself!), and you see how much you can save that way — which is a reason why those formats were designed in the first place, namely, to address ever-growing image resolution sizes. And what about vector images? SVG, a standard for over twenty years, is supported by all browsers — but almost no applications. Why? Very early implementations of SVG — which has the ability to run JavaScript or other embedded code) — were deemed 'dangerous' (because, indeed, some people have managed to take over systems by merely uploading a SVG), and so, it's rare to find a software that supports it from scratch (even WordPress doesn't support SVG by default, although there are tricks to allow it to do so). Again, the 'danger' comes from an excess of caution. Because SVG is a text format (more precisely, it's a XML file, conforming to its standards), it can very easily be parsed for any embedded code, which can be stripped out, at absolutely no loss in functionality or quality. SVG is also an animation format: you can do pretty complex animations inside SVG, without the need for anything else, and let the browser render it pixel-perfectly at whatever resolution the user wants — that's the beauty of vector images! But... well, because it was felt to be 'dangerous', this simple, compact, efficient and extremely powerful file format is usually 'banned' from being uploaded to most software out there :-( And what about video? Well, I can imagine that the major problem with video is its size. That's especially true with the most universal of all formats, MPEG4. On sites supporting it — not the case of the SL Community forums! — videos tend to get re-dimensioned during upload, and automatically converted to MPEG4 (this is how YouTube used to work, for example). That's all very nice, but there are far better formats, both in terms of what they can support (e.g. Matroska containers can have several audio and subtitle channels, automatically selected to match the browser's language settings), and in how well they can compress video (such as Theora or WebM), even with lossy quality, but giving much better results than Plain Old MPEG4. LL's limitation on 4.88 MBytes for the file size is not really much for MPEG4, but it goes a long way with the more contemporary formats — you can both get better quality and longer videos on Theora/WebM/H.265, etc.) It's incredibly rare to find video support to anything else besides MPEG4 — if at all — and when it is supported, it just goes into a queue, scheduled for internal conversion to... MPEG4, thus losing all the savings made in the first place! I couldn't figure out how to upload any video file format to the SL Community Forums. I wonder if there is an (undocumented) 'trick' to make it work? AFAICS, the answer is 'no'. An alternative, of course, is to embed a link to YouTube (that works at the cost of not having autoplay...): The same approach apparently also works for Vimeo: ... and possibly a few more popular sites. However, if you wish to embed your own video... there seems to be no simple way to accomplish that, unless you use one of the 'supported' providers. Anyway, this was just a rant... a friend asked me what kids of file formats the SL Community Forums supported. 'Not many', it seems. That's why I seriously suspect that she'll just stick to the plain old (animated) GIF format to upload small-ish 'videos'... Unless anyone could point me to an up-to-date list of supported image and video formats?...

There are the original winter regions — seriously! Back in 2004, Linden Lab has just invented the concept of 'snow regions', and launched a challenge: come up with a novel idea to use these brand-new winter-themed regions! The original founders of the CDS accepted the challenge, and the return was the city of Neufreistadt — now one of the full regions in the CDS. The incredible height of the mountains are a flawless copy of one of the original Linden Lab 'winter regions' — a copy made back then by the 'Lab themselves — and therefore sports one of the highest mountains in Second Life, on top of which is a medieval city (with some post-modern buildings) above the (old) cloud layer. Now close to the Eduverse cluster of islands — where academics and educators showcase their training and informational projects in SL — the CDS has something unique to offer (besides cheap plots and its community!): Democracy. Much neglected these days, the CDS showed that you can create long-lived projects, remaining around the grid, uninterrupted, even long, long after their original founders (well... except for one) have left. The secret for that longevity? Representative democracy and the peaceful transfer of power: every six months, we elect our officials that run the CDS, within a system with bounds and checks. There is no 'owner' setting the rules, nor even a 'friendly gang of oligarchs', nor even a 'benevolent dictator' who only wants the best for their tier-paying customers. Instead, the community elects their own representatives and make their own rules (so long as they abide by the Linden Lab ToS, obviously). If someone doesn't like them, or disagrees with the way things are done, they don't even need to go away and grumble in protest: instead, they can run for the next elections, gather a majority of votes, and run the regions as they see fit! (There are term limits, too, because we all know the old adage that power corrupts, and absolute power corrupts absolutely... so, aye, there is always a degree of rotativity among the community's elected officials) There are no 'perfect' forms of government — we all know that from real life, and Second Life obviously isn't different, since, after all, we're all humans, no matter how our avatar looks like. However, just like in real life, we have shown that a representative democracy with a peaceful transfer of power is the 'best' of all the 'bad systems' to run a long-lived community — if, of course, we want to have everybody's interest into account, while still giving us enough flexibility to change the rules to better fit with the ever-changing nature of SL (and RL!). That is true of the real world as well, and there is no reason to believe that it shouldn't work in Second Life. Well, the CDS is still around — even beyond their founders' wildest dreams, who would gladly have settled for 'just ten years' of uninterrupted existence. We're now close to our second decade, and the democratic model — which naturally enough has changed over time! — still shows that it has the ability to adapt itself to whatever the present (or the future!) might throw at us! On the other hand, one of the founder's plans to take over the (virtual) world didn't work out :-) The CDS grows as slowly as SL itself (perhaps even slower!) and is always operating within a very constrained budget — at the current prices, there is no much margin left. But on the other hand, the CDS is not around to make a landowner rich — there are plenty of other for-profit communities around. Rather, we're happy if we can pay all tier to Linden Lab and save a little bit every month to pay for events and improvements for the community, and, with luck, stash away a few US$ to think about whatever might be next region... Oh, and for many weird and historic reasons, each region is themed slightly differently. From the Alpine heights of cold Neufreistadt to the pleasant beaches of Locus Amoenus, the CDS offers different views, different styles of buildings, an ever-changing landscape, adequate for different styles of users — from those requiring just a far-away remote place with a gorgeous vista, where they can be left alone to their building or scripting tasks, to those who prefer the wild and crazy urban life in densely-packed neighbourhoods — or anything in between. The themes and styles have not been 'written in stone' by some Higher Authority: they are subject to revision and change by the community itself (and, indeed, they tend to get adapted over the years, as the population changes, new citizens come up with their own ideas and projects and get them voted upon, and so forth). It just happens that change is not drastic. Democracy, after all, is more about Evolution than Revolution: things change, subtly and over time, but you can literally wake up the next day knowing that the sun will rise from the same spot as the day before. Unless, of course, the community voted to change that — but it won't come as a surprise: you'd have been given lots of opportunities to discuss, both spontaneously in public, during in-world meetings, and on the official CDS forums. Like in real life, democracy is not fast-paced, giving everybody the time they need to adapt to changes, if those are forthcoming...

The 499 error is LL's own 'fake' internal error and (mostly) means that something went wrong on LL's end (see https://wiki.secondlife.com/wiki/Http_response#Status_499). I have encountered this error often when my own scripts hit the simulator's limit in outgoing HTTP requests (a tell-tale sign to throttle down the number of requests), although LL lists that that the 'appropriate' error code would be 420 ('Enhance Your Calm' — a non-standard code number allegedly introduced by Twitter). This doesn't seem to be your case, since your scripts clearly worked before, and you get a 499, not a 420. Did you try to get the so-called extended errors, using JSON? These might show a little more insight in what is going on. It's conceivable that LL does use a third-party blacklist database and automatically feeds its own firewalls with IP addresses found on those databases, but a quick search through public databases does not show any of Dreamhost's IP addresses having been placed into a blacklist. Granted, I just use a few of those (most notably AbuseIPDB), so I might simply not have searched on whatever LL might be using. The same applies to wherever LL is hosting simulators these days — if on AWS, it's not impossible that Amazon might be blocking incoming traffic from Dreamhost for some reason. Because Dreamhost is so cheap and popular, it's often used by hackers, spammers and scammers — which will get parts of Dreamhost's network to get blacklisted for a while. The same happens to lots of others, obviously, and that includes the 'big' providers such as Amazon themselves. All this is just speculation, based on: All your scripts worked flawlessly before Accessing your server-side software via the same API endpoints will show everything is operational; it's just from within SL that nothing works Both https://status.secondlifegrid.net/ and https://www.dreamhoststatus.com/ do not show any problem Your scripts already check for the internal limits (see https://wiki.secondlife.com/wiki/LlHTTPRequest#Throttles) in some way, so that particular scenario is not likely Of course, it could also be the case that LL's own addresses are being blacklisted by Dreamhost. This is not so unusual as it might sound: aye, some residents think they're clever and have abused LL's simulator server as a tool for attacks on external servers... this is unlikely, but you can always check for your current simulator's IP address from About > Second Life and check it on popular blacklists to see if it's there. It would also be helpful if you could figure out if this affects any simulator on the grid or just some simulators. I had a Dreamhost account for well over a decade — and I also did test it out with Go as @animats did, which was way cool — but not anymore, so I cannot make any tests myself...

I realise that this tread is ancient, bu I'd say that these days, it's stupid to reinvent Yet Another Chat Protocol; instead, the W3 standard for ActivityStreams/ActivityPub should be the preferred solution: https://www.w3.org/TR/activitystreams-core/ This protocol is much better designed from scratch to address issues such as future scalability and (current) performance. Encapsulating all communications around ActivityStreams/ActivityPub would ensure a long-term solution for LL's chat systems (that would include Group chat, too) — and, in the short term, it would (theoretically) allow SL chat to be connected to a plethora of end-user apps — including so-called 'federated' networks, such as Mastodon's (which is just one of so many solutions running on top of ActivityStreams/ActivityPub). But of course I expect LL do reinvent the wheel, as they almost always do