Gwyneth Llewelyn

June 5, 2021

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...

June 5, 2021

14 hours ago, Kittie Hexem said:

I would also happily participate in an "adopt a newbie" type of thing to help new players get oriented.

Actually, that used to be the case... we'd have personal tutors (volunteers), and, over time, we'd become tutors for newbies. That system was stopped when it became clear that some unscrupulous tutors were just interested in having newbies in order to sell them their content (newbies used to come in to SL very rich and not really knowing how much things costed...)

The idea has its merits; the problem is always the same: how to 'police' volunteers to make sure they behave according to a strict Code of Conduct?...

June 2, 2021

On 5/31/2021 at 7:47 AM, Coffee Pancake said:

[...]

I want a modern multi threaded render pipeline. I want automatic on the fly LOD generation. I want global illumination and RTX lighting. I want building in SL to be a viable way to create content. Modern communications and collaboration tools. A mobile client that gives telegram or discord a run for it's money with a full fat metaverse waiting for when I get home. A smart animation system with the kind of situational inverse kinematics hobbyist indie games take for granted. No more region borders ever again. Client side responsive physics. LSO scripts in the trash forever. Sculpts too! A switch from the shared experience to a focused user experience. A new set of system avatars that replaces 3rd party bodies & heads and content creators can target. New users not having buy a socially acceptable avatar at great expense. Tools that let us build narrative interactive experience that scales to multiple users at multiple stages of play. The capability to prototype and build actual games in SL, with all the god-tier capabilities that would require. Instanced content. Bubble universes. Boss fights. 300 people in a club at the same time. Licensed & franchise content. Console ports. Merchandise. Literal Magic.

In other words: you want something like Sansar Plus

I don't disagree with you, Coffee. I believe you're right. The real issue with Sansar was that — for obvious reasons — it was impossible to upload one's SL avatar and inventory to Sansar and have it there. This will always be a thorn on LL's side: how to dramatically improve SL while keeping the same content around? (And, of course, within a reasonable budget — you shouldn't need to mortgage Amazon to get enough money to do such a project)

Their first serious attempt at 'dramatic improvement' was, well, Sansar. But for that to work, they had to drop SL compatibility. Big mistake. It's not that SL hasn't got any 'real' competition; it's just that SL seems to be an unicorn — there is only one, it works (sort of), it makes money (sort of), it has its user base (which does not grow much). And it has a business model that is impossible to replicate. Not even by Linden Lab themselves! Not even by Philip, as he found out the hard way.

That still doesn't mean that SL is doomed to remain at its current, already outdated technical level. It just means that every year that passes makes it harder to close the gap. This was as true as of 2003 as it is today. It's partially a 'money problem', but, as others have mention, also a developer problem: LL might have been able to attract a few developers back in 2003, just because of the novelty issue, but these quickly found out that they were stuck with a platform that is anything but easy to dramatically upgrade — except for starting from scratch — which LL did try... and fail.

Where LL did manage to make dramatic changes was on the server infrastructure (aye, I know, more could be done, and I guess that now that the pressure of constantly having to buy new and faster hardware is eased — since they can just instantaneously order whatever amount of cloud-based units of computing they need from AWS — they can have their system developers tinkering with things without the fear of breaking everything). By contrast, the viewer gets harder and harder to change, even though — let's be honest! — they have done a lot in the past few years. Well, past decade — that's when meshes were introduced.

What I think is that they could start working on the opposite end. Instead of starting with the current viewer and tinker with it until it becomes 'better', they could just license a modern 3D rendering engine to start with (say, Unity, for the sake of the argument). Then they would need to communicate with the existing servers. All right, start with baby steps. First you need meshes and textures to play with. That's easy enough. Oh, they found a limitation at the server level? There is some format that Unity specifically requires that the SL simulator software cannot export? Fine! Get the system developers to create a thin layer enveloping the communication protocol — now designed to take the cloud environment into account and leverage on it — and export it to the Unity-based viewer. Suddenly that makes everything slower? No problem — we have lots of ways to cache and proxy content, and unlimited bandwidth, CPU, and disk space on AWS. So, if that means you have to replicate much of the current servers' content — that's not really an issue nowadays. And you can do it incrementally — warming up those caches, so to speak.

Great, now we have avatars, and we have meshed content. It's time to look at the inventory and the permissions system. Again, there will be some things easier than others, and it might require changing communication protocols, proxying them, creating a whole 'virtual SL' enveloping the current environment. All that takes time, patience, and lots of developers.

That's still ok. Once you use an off-the-shelf 3D engine, that means that a whole number of issues simply disappear. No more worries about maintaining the engine — that's for the Unity engineers to deal with, not LL. Found a bug? No problem — it's Unity that will fix it, not LL's developers. Mesh looking wrong from a certain angle because there is a rendering issue? Meh. That's #NotOurProblem any longer. (But at the other end of things — the server side — things also get simplified. Instead of developing a whole ecosystem from scratch, using unique protocols that no one else in the world uses, and lots of hacks and weird ideas to squeeze a bit more performance from what still seems to be a conceptual system, not a production one — they can fall back to modern paradigms (say, gRPC) and use standard tools. Need a fast way to store the relationship between avatar keys [UUIDs] and avatar names? Do not reinvent the wheel: use Redis, memcached, Bolt, whatever rocks your boat and can be deployed on AWS by clicking on a checkbox. Cannot hire enough developers proficient in C and Assembly code (because they're all working for AAA game companies)? That's too bad; encapsulate all the old server code with a layer of modern communication protocols and data representation (say, using protobuf or whatever is fashionable these days), and just expose an API which looks like any one of thousands of APIs out there. This, in turn, would allow potential developers to come to work for LL and actually hone their skills in developing software for massively deployed, distributed networks — not much different from anything else out there.

Granted, that wouldn't be the case on the viewer side; but picking an off-the-shelf, popular rendering engine would go a long way to attract programmers — because at least they could classify their work at LL as 'acquiring experience in Unity' or whatever they'd picked.

Is this so difficult to do? Well, maybe. The only thing we know for sure is that it is possible to step outside the Linden environment and still get a 'SL experience' just as before. Back in 2007, a group of curious programmers had some fun creating a 'SL Proxy' — intercepting the data streams coming from LL's servers to the viewer, and decoding the message protocol. That became the base of what is known today as libOpenMetaverse (currently code-frozen, but there is at least one popular fork which continues to get updated). This, in turn, allowed the development of third-party viewers that do not share code with LL's own viewers — such as the old Lumiya viewer (for Android devices) — and, conversely, it inspired a different group of people to create OpenSimulator — which, to this day, can replicate almost all the functionality of LL's own server software, in spite of being written in a completely different programming language and just using open-source libraries (thus, no Havok physics engine).

O-kay. Whew. That was a mouthful, even for me

TL;DR: Updating Second Life (viewer & servers) to the standards of the 2020s is possible. It just requires a slightly different approach. We know it's possible, because open-source developers pretty much did it.

Quote

But most of all I want some vision.

I want LL management to draw a bold line between where we are now and a brave new world that changes and challenges everything, and most importantly empowers us to be a part of that change. Not some crypto ntf hype bubble. Not by making something off on the side for new people who may or may not exist, but for us, the customers they have right now, the good the bad the sexy and the insane. A roadmap. A supercharger. A warchief and a lot of red paint.

In other words: you want Philip back ..

Seriously now, I totally agree, but... I also demand a bit more: I want a realistic vision. We did have all sorts of 'visions' in the past — all of which failed. In fact, Second Life seems to work best when there is no vision.

Imagine if LL made a 180º turn and allowed casinos and L$ speculation (outside LindeX) again — with a direct Bitcoin-to-L$ exchange, and possibly throw in a few NFTs (such as, say, https://www.nft-art.finance/ — that would appeal to artists and content creators for sure). You'd get the grid crammed full with new residents, coming in troves. Would that be a desired vision? Probably not — but it would certainly give the SL economy a huge boost. Sure, it would also mean lots of legal issues for LL, but all these can be dealt with in one way or another... it's just a question of hiring the right lawyers and following their instructions to the letter 😇

So, sure, we need vision, but we also need the right kind of vision, and that's much harder to get these days...

March 21, 2021

I love to bump old threads just for the fun of it, so here I am again

Sooo this thread started in 2019. Fun days. We had no idea what was happening under the hood. Sansar seemed to be a failure, but, alas, it was still around, and thus it was a potential 'escape' for people fans of virtual worlds and Linden Lab. If not, there were other alternatives, such as, say, Philip Rosedale's own High Fidelity. And Facebook's Horizon was... well, on the horizon. Oh, and of course, there was always OpenSim as a 'last chance'.

It's two years later (or so), six months after the last post before mine. A lot has happened:

Sansar was shut down (and all staff — including the precious developers! — came back to work on SL instead. It shows!)
High Fidelity gave up on its own virtual world, and are now doing some kind of voice chat thingy (Philip Rosedale got his [small] fortune selling one of the first Internet-based videoconferencing system to RealNetworks)
Linden Lab was sort-of-acquired (well, they technically did get acquired, it's just that it wasn't a nefarious takeover where the new owners would squeeze the company dry and shut it down...) and has established themselves for the long haul, no matter what the future might bring — with their current profits and the always-welcome tapping of unlimited extra money from their new owners, they're safe for another decade or four, even if they continue to lose a slight number of users every month...
The 'push to the cloud' is almost finished, or possibly has already happened, and that basically means that LL will never face a 'lack of land' ever again. It also means a much better management of resources: at long last, idle regions (and we know that the vast majority of them will be idle almost all the time — just storing content until eventually someone passes nearby to see it) will not waste CPU and memory, but will be 'activated on demand' if and when the need arises. Storage on the cloud is cheap (and fail-proof — no more loss of data!), computing resources are not, but since LL will consume CPU/memory only what they need it, it means that their overall operation will cost much, much less than before, and scale much more easily than before (just click on a backoffice button, launch a new instance of a region simulator, and off you go). It's not likely that LL will reduce the prices, though; the massive cost reduction is basically a safeguard for the future, as eventually more private regions are abandoned; in the meantime, the extra profits accruing from the cost reduction will make investors happy and give LL an opportunity to stash some money in the bank for the 'bad days' ahead (assuming that there will be bad days, of course...).
The pace of development — both bug hunting and introducing innovative features — has been ramped up even more than before (thanks to the 'lost' Sansar team, which came back to use their knowledge to improve SL...), which means that the 'partnership' between content producers and LL's own developers, which built this fantastic environment together, is just going to be able to improve the overall look & feel of SL. Even the goal of getting this social virtual world to have the kind of photorealism achieved by contemporary Triple-A games doesn't seem to be so impossible as it once did: the gap is closing, slowly, but inexorably...

Thus, yet again, SL managed to evade the prophets of Doom, reinvented itself, and is far better than ever before, in all regards (well, except for expensive land... but we're going to be stuck with that for many, many years).

I cannot even predict what will come next. The overhaul of pushing everything into the cloud consumed a lot of human resources, as well as the on-going work on Experiences, EEP, and Making Meshes Great Again. I'd think that the next two stages would be to take the advantage of cloud computing to offer more complex pricing on land, e.g. giving residents the ability to have the ability to lease 'low-end' computing power for 'limited homesteads', and having a slider to increase performance (affecting LI and the amount of avatars that can be in the same region), at an increase in the monthly fee. This would allow residents to choose to pay what they can afford according to their needs: maybe they want to host around-the-clock parties with hundreds of avatars in the same region — but don't need many prims for props — while others might prefer to have lots of LI-heavy content, but know that they won't be visited continuously by vast amounts of residents. Imagine that you could start paying as little as US$50 for a whole region (with a lot of limitation) but push the slider up to $500/month, for high-end regions such as shops where you need both a lot of available content as well as getting tons of visitors all the time. This kind of flexibility would be very interesting as a business model — and since it ties directly to costs, with little effort from LL, it might even work out fine in the end. Another possibility would be for estate owners to sort of 'distribute' resources among many regions, according to the needs. For instance, imagine a mostly residential estate, requiring plenty of content, but being rather empty most of the time; but at some times, the estate owner will host special events which are well-attended by lots of avatars. It would be logical (and much more cost-effective!) if the estate owner could decide to allocate more resources to a single region — where the event is going to happen — but reduce the amount of available CPU, memory, etc. on the remaining regions, while still paying the same every month. This would give estate managers a higher degree of fine-tuning which, in turn, would also allow them to reduce costs and eventually pass them along to their own rentals...

The other Big Project™, of course, could simply be another attempt to get SL to work in a browser and, by extension, on mobile platforms. This is the kind of thing attempted every 5 years or so (using different techniques, including streaming video) and that ultimately fails at some stage. However, things have improved thanks to amazing new technologies deployed on the browser side, such as WebGL 2.0, which follows closely the OpenGL standard (used to develop the SL viewer engine), and can even use hand-crafted shaders developed for OpenGL (SL includes those as well). Of course, it would mean porting most of the C# code to JavaScript, but these days there are so many options to automatically generate JavaScript (even JS supporting WebGL!) out of C# code that I'm sure LL would have no trouble picking up one of those fancy tools (most are free and open-source anyway) to 'javascriptify' their code. Granted, this is not the work of a weekend; if it were that simple, we would have by now tons of third-party viewers running in JavaScript. Clearly there is more to it than simply outputting valid JavaScript code from the C# source code. Nevertheless, I think that this Big Project™ is finally do-able: all the pieces have come together, and we're a long way since the early attempts of drawing meshes on the browser's canvas — now we have lots of frameworks to do that so efficiently that they can be used to run first-person shooter games. So we know it's possible. Will LL take the challenge? Only time will tell...

September 25, 2020

8 minutes ago, bigmoe Whitfield said:

Main difference is, if they connect opensim to SL, I'm out.

Heh. They did this, ages ago: https://wiki.secondlife.com/wiki/Open_Grid_Public_Beta/Teleport_How_To

It was done as a test project in 2008 and only worked from the SL Beta Grid. As you can see, you could not bring your own inventory to an OpenSimulator grid, and vice-versa.

Torley (a Linden back then) did an amusing video trying out this feature:

But you don't really need to worry. This was only a proof-of-concept project. Linden Lab never intended it to become a 'feature', just show that it was possible. They had had serious discussions back then if it would make any sense to switch their simulator servers to OpenSimulator (thus freeing many developers to do other things instead), but shortly after this video was published, Linden Lab ultimately decided to abandon any such ideas.

I would personally welcome such a project (as I've blogged about a decade ago, there even was an inter-grid communication protocol formally developed, with help from LL, IBM, and others) but it's clear by now that this will never happen.

Note that since the so-called Open Grid Protocol was abandoned (left to rot on a shelf...), the OpenSimulator community picked up from the lessons learned and developed the Hypergrid Protocol — which had several iterations. The last one allows for a secure way to teleport ('hypergrid teleport') your avatar across OpenSimulator grids, with inventories, without allowing permissions to be overridden, and has been quite stable for years. It would be relatively simple for Linden Lab to implement it on their Second Life infrastructure, if they wished, and the protocol allows not only for strong authentication, but fine-grained control over what can be 'crossed over' and what cannot. For instance, inside OpenSimulator, content creators can flag their objects to be unavailable on different grids — and the Hypergrid Protocol will enforce that. Second Life could easily have all objects flagged this way, to make sure that none could 'cross over', unless content creators specifically allowed it to happen.

But, again, this is all in the realm of utopian discussions. It will not happen. It's technologically possible, but there is not an iota of intention on the part of Linden Lab to even put this to discussion.

We just live in different times.

September 25, 2020

On 1/17/2020 at 12:33 PM, bigmoe Whitfield said:

LL's server side is closed source and not open to being able to be connected to from the outside, All we really have is opensim and that will not work with SL.

Small correction: OpenSimulator is 98% compatible with Second Life, and it uses the same viewer. You just cannot transfer any content from SL to any OpenSim grid (and aye, that includes L$).

The main difference between both platforms is that most OpenSimulator-based grids may use slightly worse hardware and connectivity than Linden Lab, but there are some exceptions...

September 1, 2014

I'm afraid that this is indeed the case... the lag is still there.

There is, however, a difference. Super-performant computers successfully 'mask' the issue. Recently I've been somewhat 'forced' to give up my ancient hardware — it was impossible to do some of my academic work related to Second Life and the Open-Source-Platform-Not-To-Be-Mentioned-Here because of this issue on the Cocoa code. The new computer has such a huge performance that the chat lag is almost imperceptible. It's still there, for those — like me — who know what to look for, but I can imagine that the majority of people will not notice a 'huge' delay, specially if they have never noticed it before (because they never had to log in to SL with 7-year-old-hardware).

However, I understand that this problem will very likely never be fixed. A year and a month has passed since the last release of a Mac viewer without chat lag issues whatsoever. As time goes by, the probability that everybody switches to super-fast hardware increases all the time. And going down from a minute-long delay between a key being pressed and a character appearing on the screen, to something that takes perhaps a fifth of a second, means that, for all purposes, there is no noticeable delay. Except that even on super-fast hardware you can still download an old viewer and compare them side-by-side — and see that there is no measurable lag whatsoever on text typing on the old viewers, while there is an ever-so-slightly lag on the current viewers.

In 18 months, computers will be twice as fast, and delays of a tenth of a second will not be perceptible to the human eye. So, effectively, the issue will be labeled as 'fixed' — because by that time it will be highly unlikely that 3-year-old viewers will still be allowed to log in (too much will have changed by then). That was my worst fear — which forced me to get a loan and buy a new computer. But I seriously suspect that not everybody is able to do that. And it feels somehow unfair, because there was nothing wrong with the old viewer and its non-Cocoa code from last year...

March 28, 2014

Monty,

Thanks for the clarification. Not being a professional programmer, and unfamiliar with the viewer code (the last time I looked at it and managed to compile it was for 1.7.X.... eons ago ), I was relying on some rumour I heard that most of the CHUI code is rendered using the built-in web browser, fully integrated in the UI. I tried to track down the place where I had read that, but couldn't find it. This was what led me to believe that Internet Plugins might play a role in it: if CHUI launches somehow some of the browser code, then it might launch the associated plugins as well, and some strange condition might make it respond the way it does (unlike the old non-CHUI code).

May I safely assume that this rumour I heard is wrong and that the CHUI code has absolutely nothing to do with the embedded web browser, then?

The truth is that, as you predicted, even without Internet Plugins, the keystroke delay issue is still present — I've tested it yesterday. The difference, perhaps, is that it takes far longer to manifest — 20-30 minutes in my case, as opposed to 2-3 minutes or even "instantly" as before. It could be a coincidence, which deluded me in believing the issues were related. I realize now that they probably aren't.

Pushing that idea away, I still have a much odder theory to test — coming from another piece of rumour, which I couldn't track down by googling for it — that is related to how CHUI required a change on the graphics rendering pipeline. In some of my tests, it seemed that I could postpone the moment when the chat lag/keypress delay hit by reducing the available memory for graphics. This is certainly odd, and I have to make sure I can replicate that consistently, even though there is a theory that would support that behaviour. Right now it was something I just noticed by mere chance: when installing a CHUI-capable viewer, either LL's or TPVs, and "forget" to set the graphics memory slider to the maximum (172 MB in my case, as opposed to the "default" 64 MB, which is all that SL thinks that my old Radeon X1600 has...), the bug doesn't seem to appear. But I really need to try this out some more; I labeled it just as "coincidence" during my testing...

March 27, 2014

Ha, I was too optimistic! 3.7.4 still has the issue. It's just that without any Internet Plugins, it takes much, much longer to appear. When it does, however, it's as bad as before — making chat, IM, group chat unusable. Relogging will somehow "reset" things, and even when logging back in to a busy text-chat area, it will give you more minutes of "normal" responsiveness...

It's not fun relogging every 20 minutes or so, though.

March 27, 2014

Update: under 3.7.4, eventually the issue appears again. It seems to be just a question of time. It takes much longer to appear, though. When it does, however, it's just as before — even without any Internet Plugins.

March 27, 2014

Yes, under 3.7.4.

March 27, 2014

@Freya thanks so much for your help! I followed all those links and apparently the issues are related to same class of problems, namely, some strange incompabilities between CHUI and some combinations of hardware/software.

In fact, for almost a year, I was pretty much sure that the way CHUI renders text, using a different pipeline order, was causing the problem on older Apple hardware, which, as you so well mentioned, probably has older OpenGL implementations. So, my assumptions for all those months were that the problem would be "unfixable" — probably Apple's OpenGL on old Macs was reverting to software emulation, or hitting buffer limits, or something cryptic like that, and LL wouldn't bother to "fix" things — you ought not to be using 2007 hardware to connect to SL anyway, yadda yadda...

Recent comments on the Firestorm JIRA, however, made me believe that I was completely on the wrong track. First, it was clear that this affects all graphics cards used by Apple (Intel, ATI, nVidea), and not only Intel and ATI (which I had tested). Then it was clear that the age of hardware and operating system was mostly irrelevant: people with recent Apple hardware and running Apple's latest Mavericks OS had precisely the same issue. And the final blow was getting reports from Windows 7 and 8 users, with top-of-the-line graphic cards, usually having 100 FPS everywhere, but experiencing incredible delays between key presses and characters popping up on the screen (as well as huge FPS drops).

So there is a class of users which have this issue, irrelevant from where they log in from, where they log in to, and whatever hardware, software, operating system, or applications they have installed. It's a much broader group then I thought. On the other hand, it's clear that it doesn't affect the majority of users, it doesn't throw any errors, it eludes any attempt to capture information from the viewer (turning fast timers on, etc.), and it is impossible to reproduce by LL's (or other TPV's) testing team.

So what could be common to all of them? That's why I think it's related to Internet Plugins, and the issue that Kitely pointed out with their plugin being incompatible with the "newer viewers" (which, coincidentally, also implement CHUI), made me think that the issue is related to Internet Plugins. After all, it's not the first time I had encountered similar compatibility issues which created the oddest issues with SL (but usually only when viewing media...)

Now we need more people to test it out. I've done a few tests with 3.7.4 and it is a bit better without any Internet Plugins, but eventually the chat delay will come back again. So there has to be something else additionally to that...

March 27, 2014

In my case, I had to track down where my browsers stored Internet Plugins (on the Mac, they're under ~/Library/Internet Plug-Ins and /System/Library/Internet Plug-Ins) and delete them. The hint I had was that I still had the Kitely plugin installed, but Kitely has abandoned it, claiming that it had serious problems with the "new way SL viewers do log in". It just happens that this "new way" was introduced at the same time that CHUI became incorporated into the viewer code. I'm not putting the blame on Kitely, it could be any other Internet Plugin interfering, but after suffering for almost a year from this bug, I'm happy to see that deleting the Internet Plugins folder fixed the issue for me.

I'm also trying the recommended RC to see the difference! Thanks for the tip.

March 27, 2014

If switching to compact view doesn't make a difference, try this: track down where your browsers store Internet Plugins (on the Mac, they're under ~/Library/Internet Plug-Ins and /System/Library/Internet Plug-Ins) and delete them. In my case that worked wonders!

March 27, 2014

@Nalates — I had this on JIRA for many months now. Because most of that year the JIRA was closed, I couldn't get more people to test it out and report. Fortunately, the Firestorm JIRA was open, and I could post and comment there — as well as two dozens of others with the same issue. Whirly, who is active on both LL's and Firestorm's JIRA, kept the information flowing.

Alexa Linden closed BUG-4423 as a duplicate of BUG-4121, but I have no access to that. I understand that only "new" bug reports are available to all users. I wished to add the following comment (which I posted on Firestorm's JIRA), because I believe I found a possible workaround; if Alexa or any other super-JIRA-admins are reading this, please add the comment below to BUG-4121 (or give me acces to it so that I might add it myself!). I'm copying the full text here — it's actually a request for doing some extra tests and see if people come to the same conclusion as I did. If yes, this bug might have finally been tracked down, and while it's not likely it will ever be fixed, the workaround seems to give excellent results. Yay for being able to use the newest viewers again!

---

After frying my brains over this, I thought: what could be common across *all* platforms that causes this issue, but is not present on *every* computer (but, rather, just a minority)?

Obviously it could be a certain combination of applications running in the background, but this seemed unlikely: as said, I tested running only Firestorm, and I still had the same problem.

It occurred to me that there is ONE thing which is common across all platforms, but will be different for each user.

Internet Plugins.

These are usually stored in a special folder, from which every browser will load them on demand. On the Mac, they're stored inside ~/Library/Internet Plug-Ins and /System/Library/Internet Plug-Ins. Because all viewers based on LL's code have a built-in browser, they will naturally load those plugins as well. I remember that sometimes I get compatibility issues with them, so maybe, just maybe, they were interfering with the CHUI API...

In my case, I had just three: one for Kitely, one for Picasa, and another for Facebook Video.

I remember a relatively recent announcement that, due to dramatic changes on the Viewer Log-In, Kitely dropped their auto-login plugin, so it's pointless to keep it around. I don't use the Picasa plugin any more. And, well, while I occasionally use Facebook Video, for doing a simple test, I could certainly delete it for a while. The hint that "Kitely dropped the development of their plugin because it interfered with recent viewers" triggered some alarm bells in my head!

So, after making sure those two folders were empty, I logged in and went straight to the Welcome Area in Ahern/Morris, where there are always people chatting. And I'm happy to report that the keystroke delay bug seemed to have gone! There were about a dozen avatars around (it's still early) and I was also furiously IMing someone else. After some 30 minutes it was clear that the bug was not present any longer.

This needs a bit more confirmation! Specially by Windows users! (I don't know where the Internet Plugins are stored under Windows) So delete everything on the Internet Plugin folders and try it out again, and see if it makes a difference. I'm also going to try later on, when the Welcome Area should be crammed full with avatars, and compare the experience.

But so far it sounds really promising!

I'm also going to crosspost this possible solution on every other place where I've reported this bug... we definitely need more people to experiment with it... we might also pinpoint it to a specific Internet Plugin only, and my prime candidate would be Kitely's plugin, as it's highly unlikely that Linden Lab's beta testers would have it installed. But any of the others could make a difference, too. Facebook Video is popular enough, for instance, to be present on many people's computers — but not on the computers of official beta-testers (they would not have time for that!).

March 27, 2014

CHUI, the new user interface for the chat console, is almost one year and a half old. It is considered a "mature" development and as such is available on most of the viewers (both LL's and major TPVs). One big change that CHUI has, in terms of programming, is that the text chat layer is fed into the graphics pipeline differently. It is supposed to work much better that way (keeping, in theory, graphics performance independent and separate from text chatting), and, in fact, that's what happens to a vast majority of users.

Mac users (but apparently many Windows users have reported the same issue), at least under certain conditions, will be unable to use chat. As soon as they enter an area with more than a handful avatars (some report that it happens instantly as soon as a single avatar comes into chat distance), the delay between a keystroke being pressed and the corresponding letter appears on string becomes unbearable — from a few seconds, which is bad enough, to a whole minute, which makes text chatting, for all purposes, impossible.

This is one very hard-to-reproduce bug. Anyone experiencing it will immediately know what I'm talking about; anyone who never had an issue will have no way to reproduce it. It doesn't appear on the logs or on the Fast Timers. Making a movie to show what's happening gives little visual clues about what's going on, unless you use a webcam to show pressing on a key and the delay for the character to appear. Even with that solution, it will still mean that developers and tech support teams will be baffled at what's actually going on.

Obviously it gets worse in low-FPS, multiple-avatar areas, but the problem is not directly connected to those. In many cases, you can have a high-FPS area with just a single avatar, and still experience delays between pressing a key and displaying a character for several seconds. A clue that it is not related to a particular simulator or region is that this affects both IMs and group chats as well. It's quite clear that it's related to the new CHUI code, since CHUI handles all the above in an unified way. Also, using an older viewer on the same area under precisely the same conditions will exhibit no problem whatsoever.

I used to think that this would only affect older Macs with older versions of OS X and using older graphics cards, because these might not support OpenGL fully, and CHUI is very likely using the latest batch of tricks to do its job. My thoughts were that CHUI would find an old card and revert to some software emulation, thus the delay. But apparently it's not the case, since so many brand new Mac (and Windows!) users report exactly the same problem. It's also not related to the size of the chat log on disk (I tried it out with alts without any chat history). What exactly it's related to is difficult to say, since nothing reports an error or a warning. The issue also appears on all regions, at all times (to be honest, I haven't tried it out on OpenSimulator grids... just on Second Life), no matter who is around, what HUDs you're using or wearing, or what viewer you use (so long as the viewer implements LL's CHUI code). It also doesn't depend on the kind of Internet connection. In fact, if it weren't for the fact that non-CHUI viewers have absolutely no problems handling chat-intensive areas, I would say that the problem didn't exist!

My concern is that, since CHUI is now a "mature" feature of SL, and development of non-CHUI viewers are not incorporating the latest improvements, this might mean that a large part of the SL resident population (mostly Mac users, but apparently others as well) will be excluded from text chat. Right now, what I've noticed is that Mac users (probably a majority!) install the latest versions, and, when they notice that this bug is still not fixed, just revert back to a 2012 viewer which has no problems, and patiently wait for another round of viewer releases. This has certainly been my case for the past year or so — I originally reported the bug while testing the beta version of the CHUI viewer, saw that the bug had "propagated" to Firestorm and reported it there as well, and just let things remain that way, unsolved and mostly ignored, while still going back to pre-CHUI viewers.

The latest batch of viewers, however, do really make a difference. Both the LL viewers and the latest Firestorm viewers include amazing developments of the renderer, which, in my very old hardware, achieves almost twice the FPS in the same area. 20-30% improvements are usually dramatic enough, but a 100% improvement is astonishing! Obviously, if you render everything in SL with 100 FPS on a latest-generation graphics card, going up to 120 — or even 200! — will not make a huge difference. But if you're used to single-digit FPS and suddenly get almost 20 FPS on texture-intensive areas, well, then it's obvious that it's time to upgrade your viewer!

This now creates a dilemma. Either you have text chat or you have amazing graphics performance (and rendering of fitted meshes, etc.). Apparently you cannot have both. But the problem is not one of choice: non-CHUI viewers are slowly being discontinued, and it's likely that they will not even be able to connect to SL in the near future. Right now, because there are still some text-based viewers using the non-CHUI API, LL hasn't removed it yet, but this might come in the near future. In the mean time, it's obvious that every new improvement and features will be implemented on CHUI viewers only, so we will be effectively out of the loop, unless, of course, we forfeit text-based chat for our enjoyment in SL.

I'm addressing these forums because I'm desperate :) There is always a chance that someone, somewhere, has found out how to tweak some obscure setting and get rid of this bug — but has not bothered to file a solution either with LL's JIRA (because it has been "closed" for so long until Ebbe opened it again) or Firestorm's (because they don't use it).

LL to Mac Users: Drop Dead · March 27, 2014

Almost all TPVs do indeed use 99% of LL's code... with two notable exceptions: Radegast and Lumyia (the latter is only for Android). Radegast started as a text-based viewer for SL using libopenmetaverse (which was independently developed at the beginning and had absolutely none of LL's code) and has been adding more and more 3D features (to the extent that on most platforms it can effectively be used as a 3D viewer). They (allegedly) use their own rendering engine and stay away from LL's. Of course, it means that scenes render slightly differently, but, as time has passed, they tend to look more and more like LL's own code, which is definitely an outstanding achievement — and proof that, as a TPV developer, you really don't need to stick to LL's code, unless you really want to (which is what most TPV developers want).

March 17, 2014

Not only it continues to work in 2014, but (shhh!) it even works under OpenSimulator... hehe.

Thanks for the script, I was going nuts in figuring out how to compensate for the camera movement, and all that because I got the control grabbing function wrong! Silly me!

February 20, 2014

A late welcome to Ebbe to Linden Lab, Second Life, the forums, and utter chaos being finely balanced on the tip of a needle

No, wait, now I remember: the first welcome message to Ebbe from me was on Twitter...

Anyway, it's nice to see, for a change, someone with a lot of background in social media and online communications at the helm of Linden Lab. It sure should give us some hopes that at least, this time around, we'll see better communication. And that's certainly quite welcome!

There are some pearls of wisdom at the LL board. We started with visionaries, like Philip Rosedale and Cory Ondrejka to get the ball rolling, even without knowing what direction it would take. Mark Kingdon saw an opportunity in expanding Second Life into the "serious" market and tried to turn it into a virtual 3D communications tool for enterprise and academic users. This didn't work so well at the corporate level, but did wonders in the research community: thousands of scientists are engaged daily in researching lots of aspects of virtual worlds (even though, because of the high cost of leasing land in SL, they do it now mostly on OpenSimulator — but all their work applies to SL as well). There are a handful of peer-reviewed scientific journals which practically only publish research on and about SL. I might even be so bold as to claim that "virtual world" and "Second Life" are now synonymous; few alternatives exist, after all, and probably the last serious one (Cloud Party) has gone with all the others. Second Life, by contrast, remains long-lived in spite of everything.

Rod Humble had a background in artistic game design, and he worked incredibly hard to fix bugs, add astonishing features — some of them in the pipelines for almost a decade! — and coming close to reach the impossible: on a high-end computer of the latest generation, Second Life is almost impossible to recognize. Long are gone the days of the "2007" look, images of which are still appearing on the mainstream news media. Gah! We have gone a long way since that.

Rod also managed to diversify LL's portfolio, and turn SL's success and profits into a source of financing for LL to launch new products. This was rather clever. In this era where two people with a computer and a programmer's handbook are able to grab a business angel, suck them dry, and waste millions after two or three years, it's refreshing to see LL and its financial resource allocation into R&D of new platforms as a functioning alternative to the "usual" ways of funding new development. Sure, not all "new products" are a success (or at least, not yet). But Rod proved the model worked without throwing LL into debt. He also recognized the potential of SL itself as a way to develop prototypes for games, by looking at the clever things that the RPG enthusiasts are doing in SL.

In SL, content is king, so getting designers the ability to create even more fantastic content (like meshes!) created a veritable Renaissance in SL. I remember this old image from Khannea Suntzu, made in 2009: http://gwynethllewelyn.net/2009/05/21/khannea-suntzus-preview-of-second-life-in-2009/ This was rendered on a top 3D modelling tool at the time, and she predicted that the SL renderer would be able to achieve those results by 2020. We laughed at her. And ironically, we actually get that kind of quality today — if not better.

Now it's your turn, Ebbe. For ages we have waited for a substantial improvement in SL as a communication tool — not only between LL and SL residents, but obviously among SL residents themselves. The way in-world text chat works is still stuck in the late 1990s — despite all improvements over the years, it still feels that the whole chat environment is not better than IRC running on a battered 486 with 512 KBytes of RAM and a sub-GHz CPU. We have my.secondlife.com, and some tentative integration with Facebook here and there. We have these clumsy forums where I'm typing now, which are invaded by spam every day (and yes, that's where most of the daily 10-12k registrations come from — not to join SL, but by spambots hitting the forums). Tickets (either in JIRA or elsewhere), abuse reports, requests for support and intervention by Linden employees — all those need a rehaul, mostly policy-wise, and not necessarily tech-wise.

So there is really quite a lot to improve, just on the communication side of SL. And it's desperately needed. Content is indeed king, but communications is its queen: we don't need merely to be able to buy awesome content, we need to be able to talk about it

Therefore, Ebbe, even if you don't stay at LL for a long, long while, you'll definitely have your hands full with things to do. It's definitely very kind of you to waste some of your precious time just to chat a bit on these forums, merely a week after you first sat on your chair That's an accomplishment, but the truly daunting challenge will be to keep it up over time. I sincerely wish you the greatest success in your new role at the helm of LL — after all, our (virtual) lives depend on it.

Cheers and good luck!

May 28, 2013

Ok, after much Googling, I found one solution. Apparently, this error is all wrong: it has nothing to do with "materials", but with a mesh which is too complex.

The solution, for me, was to get Meshlab use one of its simplification algorithms to get a much smaller mesh. This is naturally tricky, the better the algorithm, the more horrible the result. Sometimes, just a 10% decrease in complexity is enough for SL to accept the mesh and get it working.

Things are also not always obvious. Some objects seem very simple in Meshlab, but SL has a different opinion. And some objects upload fine to SL, while Meshlab crashes with their complexity! However, if you get this error and Meshlab is able to open your model, the good news is that you can use the simplification algorithms to see if you get a barely acceptable mesh that SL will import.

May 28, 2013

I'd love to know the answer too! I'm going to continue to Google for it...

May 9, 2013

After trying all sorts of external controllers — Wiimote, Nanchuck, two Wacom tablets, even an Apple Mouse — all of which are claimed to work as "Joystick FlyCam" — the results were quite uniformly disappointing: NOTHING WORKS. :smileyfrustrated:

However, a few very old tutorials claim that you can use FlyCam without a joystick, i.e. just using keyboard & mouse. I'd be more than happy with that, to be honest. If it worked.

Not only the options for turning on "Joystick FlyCam" are off, but nothing on the "Devices" panel is active.

So, how to enable non-joystick FlyCam? Is it a Debug Setting somewhere?

May 9, 2013

Hiya gamers,

I got the suggestion to ask about this here in this forum... so, here goes a repost:

The Web is full of lovely videos of people using the Wiimote (or the classic controller) with Second Life, mostly from 2006-2008. How did they do it? A mystery; I haven't found a link that shows all the steps. There might be very old tutorials that show how it's done, but even using the Wayback Machine to crawl sites that have disappeared years ago, I couldn't find a simple, straightforward tutorial...

So here is how far we've got. The Bluetooth adapter correctly finds the Wiimote; it is correctly labeled as "Nintendo" and as a valid "input device". With the proper tweaking, Windows 7 (64 bits) even recognizes it as a "sensor", although I understand that is not needed for Second Life.

I understand that we have to use GlovePIE to map the Wiimote's keystrokes into "joystick-compatible" commands (at this stage, we would be more than happy to just have the cursor keys being recognized as a joystick). However, the few links to GlovePIE scripts which allegedly do that are broken/not functional.

Very seldom, GlovePIE manages to establish a connection to the Wiimote. When that happens, the 1st and 4th blue led are locked (the 2nd and 3rd are turned off). Then, on the Manual tab, it's possible to change the emulation settings, e.g. from Wiimote to PPJoy (allegedly, SL uses the PPJoy libraries to emulate joysticks). When launching SL, the Advanced button on Movement will show the "Nintendo" as a valid controller, and the checkbox can, indeed, be checked. So, at this stage, we know that SL has identified the Wiimote, GlovePIE seems to be happy, and the Bluetooth adapter shows a lot of traffic being passed from the Wiimote to the laptop.

Unfortunately, "nothing happens". Pressing any buttons and/or moving the Wiimote around will not move anything inside the SL viewer.

After perhaps a minute — sometimes less — GlovePIE will become unresponsive. It doesn't really "crash" or show a spinning hourglass: it just stops responding (menus don't work, you cannot click on anything, etc.). And almost immediately afterwards, Bluetooth drops the connection (since it's an unpaired connection, the timeouts are very short...). One has to start again from scratch: close SL, force-quit GlovePIE, try to pair the Wiimote again (searching for Bluetooth devices), and so forth. This can be repeated ad nauseam with the same results. Sometimes the Wiimote drops the connection before GlovePIE launches; sometimes SL will recognize it, even if GlovePIE stopped being recognized, but nothing will work.

So clearly there is something missing here.

Do we need a special device driver for the Wiimote? If so, where is it, and why doesn't anybody talk about it?
What are the precise and exact settings for GlovePIE? Do we really need it? It seems a very archaic piece of software...
Everybody talks about "joystick scripts" and how easy they are to write but... isn't there a good, working example of a GlovePIE script that actually works with the Wiimote as Flycam controller? Because the rest is just guesswork: GlovePIE may be working or not, it's impossible to do even the simplest test, or get a feeling of what is wrong.
Is there a "test application" where we can see that the Wiimote is sending the correct information that SL can understand? This is to put SL out of the equation, and make sure that at least everything else (Wiimote, Bluetooth, Windows Drivers, GlovePIE) are doing what they're supposed to do.

Please, no answers with links to videos! There are trillions of videos saying how cool it is to use the Wiimote with SL; they have been posted since 2006 or so. I have seen most of them, and I'm naturally impressed by what people can do with it, but the videos are worthless if you wish to configure things and have no clue about what you're supposed to be doing.

Also, please do not simply answer with:

Pair the Wiimote with Windows 7
Launch GlovePIE
Add the correct GlovePIE script/use it in emulation mode
Launch SL

because the few articles covering this subject say that! There is clearly more than that. I need much more detailed instructions, like we have for the Zion Tristan on the Wiki. You can see how you need to do very complex steps until you can get that controller to work. I'm sure that everybody who has used the Wiimote as a Flycam controller knows all those steps by heart and just nod wisely and say "oh, yeah, sure, you have to edit some XML/change the registry/install obscure software, but everybody knows that". I don't know anything **Only uploaded images may be used in postings**://secondlife.i.lithium.com/i/smilies/16x16_smiley-happy.gif" border="0" alt=":smileyhappy:" title="Smiley Happy" />— except that it's possible, and that people are, for some reason, reluctant to write a step-by-step tutorial about it and post it publicly...

May 8, 2013

This is a tricky question.

If one of those TVs is connected to a video/audio stream that is served via Real Time Streaming Protocol (RTSP, also known as "QuickTime Streaming", but it's actually an Internet protocol), then everybody will see precisely the same stream; that's the whole point of the RTSP protocol, which is fully supported by SL (and yes, I've tested it often ).

Sadly, however, people are moving away from supporting an Internet standard, and inventing their own ways to send video over the Internet. Since, except for videoconferencing, most people will watch videos individually, most video websites will use either Flash Video or an older technique known as "progressive download" (basically what you're doing when you share a file via Dropbox). There is absolutely no way to get everybody in sync this way (to address precisely this issue of lack of synchronization, that's why RTSP was developed... in 1998!).

RTSP streaming providers charge an eye and a tooth for their services, even though it's pretty easy to install a server, assuming you have infinite bandwidth and unlimited CPUs

There are, however, other tricks. Since Media-on-a-Prim is effectively a full browser (supporting Flash!), there are a few applications that you can use to get sync'ed video. For instance, you can try Ustream.tv (if you don't mind the constant adverts) for that. But you will need something that grabs the video from your desktop and sends it through a streaming provider (on the Mac, you can use CamTwist for that, it's very easy to use and free).

Allegedly, Google Hangouts also works that way. You just set up a conference and select "Hangouts on Air", which will stream via YouTube (for an unlimited time), and apparently there is also a way to stream an existing YouTube video through Hangouts. I have tried this out twice but was unsure on how "realtime" it really is. The advantage is that it's completely free, has reasonable quality, and doesn't need any extra software (except the GoogleVideoChat plugin for your browser, which is just installed once). The disadvantage is mostly that I'm not sure how "live" the stream actually is, when seen from YouTube; you will just have to experiment...

Search for "free streaming" on Google, and try all those websites. There are so many options that perhaps these days there are some allowing you to stream directly a video without needing to grab it...

May 8, 2013

That's a great suggestion, thanks, Rolig! I'll try that

Forums

Blogs

Knowledge Base

Posts posted by Gwyneth Llewelyn

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us