Jump to content

Gwyneth Llewelyn

Resident
  • Posts

    134
  • Joined

  • Last visited

Everything posted by Gwyneth Llewelyn

  1. 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
  2. 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>
  3. @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?...
  4. 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
  5. @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.
  6. 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
  7. 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?
  8. 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.
  9. /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.
  10. ... 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).
  11. 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...
  12. 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?...
  13. 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...
  14. 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...
  15. 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
  16. Well, if I were even more sarcastic than usually, I could point out that in a year or so, we will have Second Life on some tablets. Which ones, you ask? Why, it's no secret that Apple (aye, the Evil Empire) is working fast & furiously on their 'all-embracing' OS, which would essentially run as well on the desktop as on the tablet — after all, both are designed to specs (no surprises for Apple developers) and now they share the same latest-generation Apple Silicon CPUs. The various OSes, at the low level, as well as at the programming level, were already quite similar. Unifying them into a single system should take Apple another year or two; Apple Silicon laptops can already run natively some iPad apps (probably just those that have been recently updated). The reverse, AFAIK, is not possible yet, but that's the way Apple is going. Thus, to get SL on an iPad, all you need is to wait another year or two So there — LL can do nothing and just claim that SL does run on some tablets. Very few for sure, but... that would be a truthful claim — 'Second Life is now able to run on some tablets'. When asked about an Android version LL could just dismiss it to 'someday in the future' and try to acquire Lumiya...
  17. Thank you! I was getting insane trying to figure out what had changed, because all of a sudden, tons of scripts I had created in inventory (loading them from an external editor) were being saved as LSL. Urgh! I thought that the default was supposed to be Mono — and that was a decade ago! However, the truth is that I spend way too much time on Firestorm (and my own OpenSim grid...), where I had checked that box for 'saving scripts as Mono...' a decade ago and then silently forgot all about that. Most likely, the official SL viewer had never changed that 'default' behaviour since Mono was introduced. The irony is that I've been searching on the LSL Wiki as well as on the Jira to see if any of this is mentioned. Aye, sure, there are more than a handful of 'requests' (made around 2010-2012) to add a checkbox, or a preference, or something like that — but all those Jira tickets, besides pointing to each other (sometimes it's circular!), never point to a 'fix'. Well, actually, I'm not being honest. There is an obscure reference to the days when LL was working on their Project Snowstorm viewer where supposedly this ticket had been 'fixed' and the chosen behaviour (Mono or LSL by default) could be selected 'under preferences'. I tried to figure out exactly where this used to be, but I couldn't. The Jira tickets from Project Snowstorm were merged with the 'regular' tickets (once Snowstorm became the official viewer, for all purposes), but they were given completely different numbers, and sort of mixed up between duplicates and so forth. What seemed to be an issue was that, in order to get the viewer to store inventory-created scripting assets as Mono-compiled bytecode, the viewer developer team at LL required some input/help/assistance from the server developer team. This doesn't seem to make any sense whatsoever until you consider that LSL complies to LSO bytecode in the viewer, but to Mono bytecode in the server (allegedly on the region where our avatar is at that moment). Thus, when saving a script in inventory, the viewer can automatically compile it to LSO bytecode, and store both; while getting a Mono bytecode compilation requires the server to do some work and report back to the viewer. This makes sense to me. However... Project Snowstorm is supposed to have fixed this issue by adding a 'preference' somewhere. Where is it, and where has it been placed on the current viewer? If it's not there — the question is why not? What happened during the merger of Snowstorm into the 'main' viewer code? My guess is that some bits were left over, or forgotten, or so terribly mislabeled that the developers thought they had fixed this pending issue, but actually nothing had been done. As mentioned, practically any third-party viewer out there supports compiling to Mono by default, and that has been the norm for many, many years. My guess is that the viewer team had requested some 'assistance' from the server team (as one can read on the Jira), who promptly made the necessary changes, and the viewer team proceeded to implement it on Snowstorm; this code was then forked and re-used on all 3rd party viewers since then. However, once LL merged Snowstorm into the mainline viewer, for some obscure reason, this change was not implemented at all, but rather just silently ignored in their internal workflow, with all interested parties checking this off on a list of support tickets; but, a the end of the day, the change was never implemented, LL just thinks it was! /me *sighs* Anyway, as said, thanks for your very helpful comment. I only wish I had read it several hours ago... instead of scorching the 'net in search of an answer that simply is not there.
  18. Bumping this just in case someone from LL is watching this thread: The Knowledge Base article with the instructions regarding how to set up teleporting in Estates/Regions is dated from February 2011. It seems to have been updated in mid-2021, but I have no idea what was changed. The truth is that things are way more complex (and fickle!) than what this KB article describes, even though @Jeremy Linden was candid in saying that some things may break... I've been having real trouble in setting a whole estate with a central telehub (works) which doesn't affect the teleport ability of group members (doesn't work). Although the KB article claims that Estate Owners, Estate Managers and members of the group the land is deeded to are not affected, this is not true. Only the Estate Owner & Manager have that ability. The role ability that allows them 'unlimited teleport' simply doesn't work (actually, the same happens to the 'fly anywhere' ability — it's simply ignores — but that's another story, for another thread). Whatever is set at the Estate/Region level overrides everything. However, when the Estate/Region telehub is active, but no landing points have been set, then group members can teleport Home, if they have set it to someplace else (i.e. not the telehub) and they have the 'unlimited teleport' ability granted through their group role. That's the silver lining... meaning that, at the very least, you can safely teleport home, you don't need to walk for that. I have only experimented with settings at the ground level (it's a no-fly region...), so things might be different up in the sky. Note: I'm old enough to remember when it wasn't possible to teleport 'anywhere' — there was no other option but to teleport from telehub to telehub, and walk the rest of the way. Linden Lab imagined that this would be a nice way to have 'gathering places' and some order in the region, as the telehub becomes the 'most important' spot in a region; residents wishing for a bit of peace of mind would rent places further away, while shops would gather around the telehub in the hope of catching prospective customers. This was before private land existed, of course. Eventually the fierce competition around the highly-priced land around telehubs became such a source of complaints that Linden Lab was pushed to allow people to teleport anywhere (in the mainland, which was all that existed). When private regions became available, LL gave region owners the ability to choose how they wished their land to be accessible. I can very well believe that most of the code dealing with the complexities of teleport routing come from that time in the remote past, and have not evolved much over the years (decades...). It also means that eventual bugs that have crept in might be hard to find, and, worse, because the original developer might have been gone from LL for years, it might be too tough to figure out how to fix that code — like so many other projects that LL abandoned because they lost the relevant programmer who was working on those features. Anyway, I'm ranting and digressing; I'll shut up for now.
  19. That's one of my pet projects. After a discussion on Hypergrid Business, I learned that the biggest issue is not really the technology, but rather the legal framework to exchange cryptocurrency for fiat currency. The rest, actually, are minor details. I'm still implementing a conceptual, proof-of-work system (not using NFTs, though, because of the legal issues...) in what passes for my 'spare time'... I expect that I will only have something to show in the next decade or so, though...
  20. Oh, I totally agree; there is merit in both approaches, and it's hardly guaranteed that a 'centralised' approach will always have good results! Sometimes it does... but that's not a given, which applies in all situations. Here's another good example. By now, we've almost forgotten the Great Recession. Around here in Europe, there was a 'centralised' approach to deal with a financial catastrophe, because, well, the European Union is rooted in all things economics, and these tend to work reasonably well at a supranational level. Because neoliberalism and technocracy were the driving forces back then in 2009/2010, the 'cure' for the Great Recession was — austerity. When things went from bad to worse, what was the solution? More austerity. That left the big thinking economic minds looking at their formulas and scratching their heads, because, well, economics is a science since at least Adam Smith, and it should work well to predict the future — notably, it should predict correctly the consequences of economic decisions. But clearly all that was failing. By contrast, the US opted for the exact opposite approach, meaning infusing the economy with 'free money'. That got the conservative Republicans into a frenzy, but it meant saving big corporations, whole industries, and millions of jobs, by simply putting more money in circulation, not less. And the result was that the US started recovering quickly... while Europe was in its biggest mess since WWII. (Hint: how did Europe recover from WWII? By having the US drop 'free money' on all countries affected by the war. The French still call the ensuring golden age The Glorious Thirty, in reference to the three decades of unmatched prosperity that followed WWII.) Eventually, what happened was that in most European countries, people voted to get new governments that were against austerity and proposed 'other ways' to deal with the economic crisis. One by one, countries independently started their own recovery programmes, uncoordinated among themselves, leaving 'austerity' behind, and dealing neoliberalism/technocracy a huge blow. In some cases, the solution was a turn to the left, in most it was a turn to the right, but all had in common the rejection of austerity that worked so well for the US — and, after a while, it was more than clear that it worked for Europe as well (why shouldn't it work?). With COVID-19, the approach was different. Because the EU is not very good at coordinating social issues, it didn't manage to do an unified approach to dealing with the pandemic: each member state adopted their own measures and their own strategy to deal with the pandemic. Some benefited from the experience of dealing with the H1N1 influenza pandemic of 2009/2010 and applied similar measures; others tried different approaches; all feared a total collapse of the economy (which, thankfully, did not happen, although it's more than obvious that hundred of millions lost their jobs world-wide — think about all tourism-related industries!). At the end of the day, it became rather clear that if there had been a coordinated effort among all countries (preferably world-wide... but at least per continent), we could have limited the spread much earlier and much better. Fortunately for Humankind, SARS-CoV-2 is a deadly virus, but not as deadly as, say, Ebola, or none of us would be around to tell the story... So, aye, sometimes central coordination is good; sometimes it just points everybody in the wrong direction. A mix of both seems to be able to avoid some pitfalls and allow the best choices to 'bubble up', as you so well put it. (Also note that my country is quite small — lots of geography packed in a small space, though — with a population of about 10 million, mostly spread among two very large urban areas where 70% of the people live. Centralisation at such a scale is much more practical. Nevertheless, the country is divided among 300 or so municipalities, each with its own locally elected government and representative assembly, and having a reasonable amount of autonomy, financially and administratively; but dealing with a global pandemic is beyond the resources of any of those municipalities, at least without substantial central support & organisation; still, there are differences among each of them, each having a reasonable large degree of autonomy, even when actually implementing a plan which had been centrally designed... this comes from historical reasons: almost all the municipalities have enjoyed a certain degree of self-rule for at least a thousand years — take a century or so — and even when there was a central ruler such as a King of the combined realm, he or she had to be acknowledged by the population in general, or, well, the monarch would never be respected or their orders executed... the clergy and nobility lived outside the towns and cities across the land and rarely had any authority over them. In fact, we have traditionally little inherent respect for any authority — they must earn the right to be respected in order to be obeyed. As the Romans said when they finally conquered this territory, two thousand years ago: 'a population which is unable to govern themselves but utterly refuses to be governed by others'. Lisbon, the capital, has had continuous self-rule for over three thousand years, being one of the oldest cities in Europe outside Greece — when Rome was still a village of fishermen, long before the mythical date of its foundation, Lisbon had already been around for centuries and was a major trading post between the Phoenicians and the Greek... so we view any 'external' authority with deep suspicion. Obviously, things change, and today we often boast that we're the 'most European member of the European Union', mostly because we do comply with all the silly rules, even against our own good, simply because we tend to believe in the overall grand project, irrespectively of current conditions and confusions...)
  21. For clarification, I should add that it's not a surprise that the influenza incidence is so low, since every precaution taken to reduce the risk of SARS-CoV-2 spread will also not only reduce dramatically the spread of viruses such as influenza, but also of the many strains of the rhinovirus as well as other (harmless) endemic human coronaviruses, which cause the common cold. As such, all the data related to the 'flu for the past season will be seriously skewed (worldwide): we'll have far, far, far less cases of all those respiratory diseases during the period that we're taking precautions against COVID-19.
  22. Sorry for interrupting, but I seriously doubt that. Where did you get that information from? The European CDC posts data about influenza regularly. If you select the 'flu data for Poland (or any other country, really) from this last season and compare with the previous one, you will see the dramatic difference — the ECDC claims that there have been 99% less cases of influenza detected in Europe. This is not surprising — masks, washing hands, and social distancing work as well for the influenza virus as for the coronavirus. Note that this also applies for a lot of other seasonal viruses — rhinovirus and the endemic human coronavirus that cause the common cold, for example — and this meant that, this past year, we all enjoyed a respite from the usual 'flu and common cold pandemics. The Polish government, via its National Institute of Public Health (PZH), also published similar findings. Note that the first graph, comparing incidence of influenza in the past seasons, is logarithimic, not linear! It actually shows that influenza-related incidence was only about 10% of the baseline of other years — or, if you prefer, ten times less. The ECDC also reports that the Polish laboratories which have been testing for the several strains of the influenza virus have received around 46.000 samples during the 2020/2021 season... and only found 47 positive cases. 47! Number of COVID-19 incidences and deaths for Europe, up to today: https://www.ecdc.europa.eu/en/cases-2019-ncov-eueea (Poland: around 2.9 million incidences; ±75.000 deaths) So, on one hand, you have 47 reported cases of influenza incidences in Poland (and zero deaths). On the other hand, you have 2.9 million reported cases of SARS-CoV-2 incidences in Poland, and roughly 75.000 deaths. Please explain to me how the 'flu causes more damage than COVID-19 in Poland.
  23. Hi from across the Atlantic Ocean 🙋‍♀️ Around here in Portugal we're a bit behind the US and the UK, but I've got my first Pfizer shot 3 weeks ago and I'm due to get the second one next week. Because we don't have our own vaccine yet (if at all...), every shot has to be accounted for, and properly registered in the national vaccination database. We all have our vaccines registered on that, but, as you can imagine, only doctors and nurses are allowed access to our medical data. This posed a problem with mass vaccination. Originally it was thought that we would also be able to get shots at the local pharmacy — which is a great way to mass-distribute vaccines. However, that raised the question about how to give pharmacists access to data that they are not supposed to be able to read. Also, for the same reason, pharmacies are not connected to the national health database systems — because they're not supposed to be able to read any of that data. In the end, there was just a legal way out: getting doctors and nurses to administer the vaccines. Most are volunteers working for the Civil Protection (the US equivalent would probably be FEMA) anyway — this is important because around here, after a lot of reorganisation (and quite a bit of polemic, too), the Civil Protection service is now a paramilitary operation, and the COVID-19 vaccine rollout was actually organised under the command of a Navy Admiral. This means that these people are used to complex organisation in the middle of an emergency — sure, many of the administrative staff (which take care of the endless paperwork until you actually are able to get a shot...) are volunteer 'civilians', but they have been trained by the Civil Protection to do their job under a paramilitary setup. Doctors on the vaccination sites actually do the registration (and do a very quick health check in the few minutes they talk to you) and then hand us over for a nurse to vaccinate. I have to say that this was the 'best' shot I have ever had — granted, the last one was eons ago, and, lately, I just need to take blood samples (but not inject anything), which, as you all know, requires a completely different technique. I'm one of the lucky ones who had not the slightest side-effect. After a few hours I could not even say for sure where the shot had been given; on the morning after, there was nothing to show that I had taken a shot. Not even the slightest bruise or redness. And I had absolutely zero side-effects from the vaccine. I'm curious about the 2nd shot — and I'll be complaining sarcastically that the first shot didn't count, since it clearly had been a placebo with just plain tap water in it 😂 — so I want something stronger this time! Jokes besides, my point is just that the vast majority of all people won't feel anything and have zero side-effects from taking a shot. If you're unlucky, you'll have some soreness and a small, localised rash; both will disappear within 48 hours, at worst, and you can put some ice on it to reduce the inflammation. Only a very, very small number of people have any symptoms. The sad thing is that if your shot was painful, you're highly likely to swamp your social media with your horrible experience. That's human nature — always eager to complain when we feel the slightest discomfort (and blame it on someone!), while 'feeling nothing' is not worth telling anyone. I did file an official compliment (also rare — complaints are legion, compliments are few), because all those people are doing an amazing job to get us all vaccinated... a task that I'm sure none of them envisioned that they'd be doing in their lifetimes.
  24. Indeed... that was everybody's expectations, back then. There was a code of conduct for the volunteers; there were weekly (I think) meetings with the Lindens responsible for community management which were free to attend (only a tiny, tiny fraction of the group — 5,000 strong at some point, if my memory doesn't fail me — would attend, though); there were even 'tutoring classes' for the volunteers, so that they could learn the code of conduct, and, naturally enough, how to tutor newbies in a consistent manner (in other words: learning how to answer the main questions in the same way, in order that if a newbie would ask a different tutor for something, they would receive a similarly worded answer). There were lots of available resources, including packs of freebies to be given out (everybody could give out even more than the 'common' pack, of course; but at least they'd all have, at least, the 'common' pack of goodies), as well as notecards with all sorts of FAQs and their answers, subdivided by topics/area of interest (e.g. clothing, inventory, in-world shopping, scripting, etc.), and pointers to places where more information was available; there were some online forums/communities for general discussion and sharing of resources; and the in-world group was thought to be a way to 'call' a volunteer when the volunteers needed help — for instance, if a newbie started asking questions on a subject that they weren't familiar with, or had a newbie who spoke a language they didn't speak themselves. Newbies were even encouraged to keep volunteers as friends so that they could still IM them afterwards if they had new questions to ask (this, of course, later became one of the main vectors for abuse...). So it was a pretty large organisation with a certain degree of complexity, but it gave newbies the impression that Second Life was super-organised by the residents themselves (it wasn't, but that's the first impression you had, and first impressions count...). There were even a few logos, especially when Linden Lab stopped the overall official programme, but many continued to do their volunteer work, even without Linden Lab's official blessing: But of course there was no mechanism of 'enforcement'. A rogue volunteer could only be expelled from the group by LL — tough to do, when you have just a handful of Lindens as community managers, and a population of 5,000 to 'police' — and nothing prevented those that were expelled to create a new group with a tag identical to LL's official group, so that newbies really didn't have a clue if they were talking with an 'officially-sanctioned tutor' or just someone abusing the system for their own profit. Obviously, if an official tutor caught one of these rogue ones, they would report them — but justice, in SL, is very slow, as you know, and it was more than likely that it took ages until anyone got 'caught' and potentially expelled. Also, it was not clear that the ToS explicitly forbade such type of behaviour — mostly exploiting the newbie's ignorance — so long as the 'rogue' volunteer was clever enough to disguise their scamming under the cover of actually helping newbies (which, to a degree, they also did). Here is a typical scenario which would be impossible to prevent, and that technically wasn't even against the ToS: a 'rogue' volunteer also owns a shoe shop, and is well aware that newbies would have some L$ to spend without really knowing how much their L$ are worth (or how to get more...). So they approach the newbie, introduce themselves as a 'volunteer tutor', and start helping them out, teaching them how to dress, how to use inventory, and so forth. They give the newbie a lot of the officially-sanctioned freebies, as well as many notecards with information, most of which coming from the official sources. Subtly, though, they shift the conversation towards the avatar appearance, telling the newbies that the freebies are not really very nice (they weren't, back then), and that the better-looking outfits would cost some L$ — such as the one that the rogue volunteer tutor was wearing, which would be 'designed to impress'. Or sometimes the newbie would innocently ask, 'how do I get such a nice outfit as yours?' and that would lead to a truthful answer by the rogue volunteer: 'well... these kinds of outfits are not free, they are sold for a few L$, if you wish I can teleport you to some shops where you can find such lovely outfits as mine.' This could be dropped matter-of-factly — all volunteers would naturally ask what the newbies were interested in, and have a ready-made list of popular spots — and it would be just a question of chance that they'd brought newbies to their own shop. In some cases, they would bring them to friend's shops — and get a commission on sales. Think about tourist guides in real life: they do exactly the same, and it's perfectly legal (moreover, tourists know this to be the case, unless they're also 'newbie tourists'...), and profusely done all over the world. So why not on SL as well? The problem back then was: where to draw the line? Just like real-world tourists are 'scammed' by tourist guides — but only to a degree! — and this is both expected and ubiquitous, it would be hard to start making judgements upon the rogue volunteers who just signed up to grab newbies and dump them at their own shop and the shops of their friends (some of which — like in real life! — had overpriced, low quality products, but these were still marginally better than the available freebies...). This was especially true if the rogue volunteer would also be very helpful with all other questions — i.e. they were actually helping them out, not merely herding them towards the shops! Wouldn't it be the most natural thing in the world to have newbies visit the shops of your best friends? Of course it would. Didn't everybody do the same, in one way or the other (even if most volunteers naturally didn't earn any commissions...)? Of course they did... to a degree at least. Eventually, the whole concept broke apart as the system was overabused, i.e. old volunteers would start to leave in protest, while the new sign-ups would be eager entrepreneurs, ready to spend all their time with newbies in order to get their L$ in various ways — some of which would be classified as extorsion or blackmail... and plainly ignore all codes of conducts or rules, never attending meetings, never bothering to chat on the in-world group or on the community forums (for them, a waste of time, since that meant spending less time 'hunting' for newbies...). I even saw cases of what could only be described as racketeering — newbies being 'forced' to shop at this or that location, 'or else' — and very scary scenes of alleged volunteers herding groups of newbies, making sure nobody could lure them away. Let's say that it became nasty at several levels — and that's not counting with what I have heard but of course didn't experience first-hand, so I'd be wary of reports such as forceful submission by volunteer dommes who claimed the newbies as their slaves — allegedly without the newbies' consent, who were lead to believe that this was 'expected' in SL, at least for a while, and later on they'd become dommes themselves... or some similar nonsense. And that meant that Linden Lab shut down the whole operation — or, rather, the Linden-sanctioned group. As said, many volunteer groups have kept up the spirit — although in much smaller sizes — without LL's official blessing (but they didn't mind that it happened spontaneously, so long as nobody claimed to be endorsed by LL). Then we got the private orientation islands and so forth, and this allowed several volunteer groups to remain around certain communities and keep helping newbies. But I'd be very hard pressed to believe that Linden Lab would be willing to resurrect this concept again. It's very hard to manage a vast group of volunteers, working for nothing, and keeping them all focused towards the same goal. While in real life many ONGs are most definitely able to manage that, they also have professional managers who have been trained to coach and encourage volunteers to work according strict rules and procedures 'coming from above' — while still keeping such volunteers happy about donating their time for the common good. This was clearly way beyond Linden Lab's community team. It's worth to add that they did their best — probably giving 120% of their effort towards the project, which they clearly loved — but they were also burned out by the end, when it was clear that the whole concept was backfiring, with several residents protesting against the 'special status' granted to so-called 'volunteers' — not everybody would be accepted, they had to be in good standing, etc., there were a few rules to evaluate one's submission as a volunteer, and many, many were kept away for various reasons, only known by the Lindens — who could have direct access to the 'source of money', i.e. clueless newbies with their bonus L$ package, while other legitimate entrepreneurs were not able to attract customers to their premises in such a straightforward way (and not everybody was willing to be part of the racketeering scheme of paying commissions for volunteers to bring groups of newbies to one's shop...). I'd say, in retrospective, that LL had no real choice in the subject. You can manage reasonably large communities even without 'carrot and stick' (the carrot meaning mostly money, or at least privilege; the stick being swift justice being administered to those breaking the rules), but it's not easy to do so, especially when the community grows too fast for the few 'overseers' who have some 'punishment' powers. The concept of self-governance fails when there is no effective form of actually enforcing the group's own rules. Expecting that people follow rules all the time 'for the common good' is actually a very naïve vision of the world — I know I've been repeating myself for the past 15 years or so, but it's always worth taking a look at Kohlberg's stages of moral development. They show quite clearly that the concept of acting for the common good is a lofty goal which is just followed by very few; although current real-world democratic societies are utopians-under-construction having that goal in mind — a society where everybody does whatever is best for the common good, without being asked to do so (much less coerced) — in the real-world governments know that most people are, at best, at levels 2-3 of their moral development, requiring strong rules and enforcement of those rules (with the threat of actual punishment) to get most people to comply with them. Second Life's resident population is not much different. One might be lead to believe that, due to its nature, SL would appeal to those on the highest moral stages of Kohlberg's hierarchy; but that's necessarily not true. It's true for a few — and those can most certainly be a part of a community-based effort for the common overall good — but it's not true for most. And to tie in with the original question on this thread... it's a very long one, showing exactly what I think about human nature. If we residents see ourselves as stakeholders in Second Life, as opposed to customers of Linden Lab, then it becomes apparent that, whatever effort we make to attract new residents and keep them happy, is an effort that is beneficial to the whole community of stakeholders. In other words: if we do LL's marketing, we benefit (because we get more happy people regularly using SL — and that has also some financial implications, i.e. more people consuming content and paying rent, bigger attendance on events, and so forth). It's true that LL also benefits — financially speaking — but that is secondary and irrelevant; you can see it as a positive side-effect from our collective work. It also has a non-negligible effect, of course: if LL makes more money, they're likely to be able to keep SL around for much longer. But the focus of those who see themselves as stakeholders in Second Life is the community of stakeholders — if LL benefits from the collective work of the stakeholders, more power to LL, but it doesn't concern us. We may just be happy about it :-) (or not!) By contrast, if we merely see ourselves as clients of Linden Lab, using a product for which we pay, then, obviously, it makes no sense to 'volunteer' for anything — neither for helping out newbies, nor for helping to spread information about SL by word-of-mouth or social media. That's up to the owners of Second Life to pay for; that's what the good money we pay them is to be used for. Granted, Second Life has a mix of both kinds of users (and perhaps even a few more types!), and that means that no answer can ever satisfy everyone. But that has been true of SL since its inception...
  25. The issue about 'we're not being paid to do LL's own marketing' (something that has been always discussed over and over again) reminded me of a current ad being ran by the German supermarket chain LIDL. Around here, they have recently launched a campaign under the slogan Nobody sells us like our customers — clearly pointing out that the best form of advertising a product or service is word-of-mouth (even though LIDL, naturally enough, uses all sorts of advertising, on both traditional and digital media). I find it amusing that a supermarket chain has no problem in engaging their customers as their 'best' evangelisers, while here at Second Life, we trust Linden Lab to do a better work than the residents...
×
×
  • Create New...