Qie Niangao

I have yet to see this used successfully in the forums, neither this version nor the previous one. That's surprising, considering the number of talented graphic artists in SL. It is possible to create an appealing effect with animated gifs -- I may have to construct an existence proof -- but somehow all we're getting are crappy 1990's-vintage blinky banner ads. Kind of embarrassing really.

... no I'm not limiting my stuff so I can teleport, that ain't the case at all. Not sure how to read that. If you're saying that you're using an avatar with no attachments at all and still can't teleport, that would point in one direction for a solution (most probably a local network problem that might be fixed by rebooting your router, cable modem, etc.). If instead you're saying that you don't want to reduce the number of attachments because sometimes it works with everything attached... well, that's a different direction, where there'd just be no choice but to trim down those attachments (and that may not necessarily require losing the attachments, but stripping out unused scripts, etc.). If that's the direction, we just need to figure out how to minimize the pain. (Incidentally, even unscripted attached prims in large quantity can interfere with teleports, but it really takes a lot of them.) One off-the-wall possibility: Are you by any chance running multiple viewers at the same time? That seems to be a problem with the latest Viewer 2.5.1 release, that I've seen trigger upon teleport. But... that seems unlikely to be your problem here.

These ranks are very strange things anyway. They "unlock" some privileges that, at the higher levels, seem almost completely unrelated to the activities that elevate those ranks. I guess I can imagine that posting YouTube videos might be something to gateway based on such automatic metrics as number of posts, login time, etc. But being able to edit Knowledge Base articles? I find it very difficult to believe that such permissions are granted automatically anyway; they certainly shouldn't be. As an incentive to contributions, I don't think the visible role titles serve much purpose. Indeed, it seems to me that they motivate exactly the sort of folks one wouldn't really want to have elevated permissions. Some sort of "honorifics" ( "awards", "badges", ...) have proven useful for promoting positive contributions in crowd-sourced content sites such as Foursquare or even Stack Overflow. And there need to be permission gateways here. The current role structure, however, combine those two objectives in a way that seems unlikely to satisfy either of them.

Voted and Watched. I think even more important is another jira that would have LL viewers adopt the same URL pre-screening as all the third party viewers are scrambling to get in place. None of this is going to be enough to salvage Shared Media (dammit), but the pre-screening is absolutely necessary for any LL viewer to have users, and both are essential to the survival of in-world live music or DJs. Yeah, the game has changed a bit for them: it's possible that a few more folks will use audio streams outside the hosting parcel, but it's always been possible to do that--in fact, it could never be made impossible. Now, however, any attempt to hide a stream would be universally assumed to be an attempt to harvest data, and every newbie would be advised never, ever, to enable Media or Audio. And yeah, it has everything to do with LL's handling of "Redgate". If the Lab had promptly permabanned the scammer and bricked the devices, folks might believe that the policy measures had enough teeth to deter future large-scale abuses. That, however, is not what happened, and nobody will trust hidden in-world streams again.

Is there some reason why some badges have rounded corners and others are square? And why some have a heavy black box surrounding the whole badge? (Is that part of the badge, or some attribute of the post?)

Umm. So, all Blogs feedback in the Forums goes in this one thread? This seems, uh... other than optimal. But, just to get the ball rolling on that topic: The most recent land-related blog post was by Jack, five months ago. Land is still the Lab's number one revenue stream, and by margin completely swamps all other sources combined--probably by two orders of magnitude. And there's no Land Forum section. The deck chairs need re-arranging, no doubt, and it's a fine hobby, but isn't anybody minding the actual store? [Edit: Minor discovery: There is a "Land Ownership" forum, stranded under Commerce. I suppose that's not an altogether unreasonable place for it (although... not sure the average residential landowner would think of it that way). It's probably only "hidden" to those of us who have always avoided like the plague the old Commerce née Xstreet forums.]

More importantly, when are we getting 64m prim dimensions? (I have zero confidence that we'll see Mesh this quarter, and don't really expect it for next quarter either. I'm convinced the team is working very hard on it, but TBH, it doesn't seem any more ready now than it did when it first hit Aditi.)

Jeepers, Vick. You start this thread, a handful of posts later: problem solved. This is some forum here, eh wot?

Um, yeah. I'm kinda surprised the Jira is holding up as well as it has for that one. (I have to admit, it's not obvious to which category this discussion would be suited, ideally. But if it's between bogging down the Jira and exercising forums discussion software, the choice seems obvious.) Incidentally, I recently linked another really old jira ("Automatically play media setting ignored plays anyway - PARCEL_MEDIA_COMMAND_PLAY") to the Redzone one. Seems to me, had that been fixed, the explosion about Redzone could have been delayed another six months or so because it wouldn't have been able to scan so many addresses.

Is that what I was supposed to see? Evidently somebody thinks so. But probably nobody at Linden Lab. The thread was about an in-world suspension that a resident just received as a result of an unspecified Forums post back in September. That topic itself may violate Forums guidelines. The post that lead to the suspension was apparently criticizing the previous Support outsourcing company. Lindens are unlikely to be aware of any of these events, having outsourced nearlly all customer-facing business functions.

You know, Rod, the best thing about this post is that it actually looks as if you're having fun in Second Life. That's kinda the utility function, summed over all residents, that one would like to optimize.

This just in: Jack's boss, Joe, has left the Lab. Jack would have been Joe's "organic" replacement. Several stories come to mind, and the less interesting ones also seem less likely.

Welcome, Rod. We're all in this together, so very much hoping you'll find great success. The SL platform comes with a lot of history -- technical, business, and human -- so expect to learn a lot and to keep learning. Residents can help you with that in ways that may be impossible for other Lindens. But of course some things aren't known to residents. If I may suggest: try to probe why so many desperately bad business initiatives were pitched internally as good ideas, and adopted. They each came with opportunity costs -- sometimes huge -- so you need to figure out how to avoid the grandiose delusions that have perpetually plagued decision-making in the Lab. (At least to this outsider, BK seems to be uncharacteristically level-headed, so he already may have insight into what ailed preceding generations of management.)

Thanks for your many contributions to Second Life, Jack, your vision of all it could be, and your commitment to making things happen. Now, for a change, may your hard decisions be to pick from so many winning choices.

What are you all talking about? Is there some hardware that's not showing local lights now? As far as I can tell, they behave exactly the same as they always did. Oh, and the whole wish list -- and more -- is available in the experimental lighting and shadows option, under Develop / Rendering. That stuff, plus the huge speed-up of shadows, are among the best things about Viewer 2's new rendering code. (The bad news: if you happen to be running a Mac with an ATi graphics card, you're yet again screwed by Apple's notoriously crappy OpenGL drivers.) (There was one advantage to the old, limited local lighting: I could hide the neighbors' stoopid lights just with a stack of six completely transparent black-emitting "lights". With the new unlimited lighting, I have to put something in between that's visible from their side, to block the light.)

Independent of whether this was ever a good idea, the implementation is currently too broken to be used. Misbehavior of this feature is not something that can be handled as a chronic annoyance. It simply must work without fail at all times, or the feature is (much) worse than worthless. This feature should be disabled until the following very serious jiras are fixed: Display Name and username showing as ??? llGetDisplayName random returns a Null String Note that these are not issues with the concept, but fatal flaws in the current implementation. They must be really, really fixed, not just made less frequent -- so it's not at all certain that the current design can be made to meet spec. If not, LL would need to consider whether the objective benefit will justify the additional investment needed for a working implementation.

No, there's a real problem, with an associated jira. It's a fairly nasty bug, affecting not only what the viewer sees, but what scripts get when calling llGetDisplayName() -- so, technically, it's not a viewer bug, but I'm not going to suggest moving it at this point. To your earlier post: Actually, it is possible to choose a display name that's the same as somebody else's username because, although usernames are unique, display names are not: we can have as many Agent Smith display name characters as we want. (I realize folks think this is going to be a big opportunity for scam artists, and I guess I agree that for the next couple of months that may be true, not so much for newbies who have no reason to think display names are unique identifiers, but rather especially for oldbies who have expectations that aren't valid anymore. And, I guess, that may take more than a couple of months, because many folks use older third party viewers that may not have the display name capability for a while, so those users will be disabused of their assumptions only later when those TPVs are updated or replaced.)

As it stands now, there's a fairly nasty little bug in llGetDisplayName(), which turns the task of determining a user's display name into the Halting Problem some of the time. So, for avatars in the sim when that script function is called, one may get the Display Name, or the Null String, or apparently "???" if there are problems with the service. To really drive us scripters crazy, choose "???" as your display name. During the current transition, I think there are compelling reasons for some folks to want a script that checks whether an agent's display name is too similar to a merchant's user name, for example, perhaps ejecting and banning such agents from the parcel. I kind of expect that a year from now, nobody will much care about such things because nobody will be able to be fooled by display names, so there won't be any need to protect against an obsolete ruse. But that's not the situation at the moment. And that means if there will ever be a time for these script functions to work correctly, it's now--not later.

It's easy to try for oneself. I just looked in the stored log, and both are included for those who have a display name set. The username appears in parenthesis, following the display name.

Security orbs and really any scripted device should keep working without any problems. Kelly provided a detailed write-up about it on the wiki. Briefly, scripts that use names currently will continue to use those same names (called "Full Names"... which are the same strings as what we've all been seeing before Display Names came into existence). That does mean that anywhere you specify names to an existing script, you'll have to continue to use those Full Names, not Display Names. And if those scripts generate output that include avatar names, they'll keep using those Full Names. Display Names will, however, lead to some new products that depend on them, or at least make use of them. Many folks will really want to "hear" their scripts saying or emoting their display names, not their full names, and that means an update to those scripts. Also, one can imagine RP settings where scripts should respond the same to all agents that share the same display name, regardless of the agents' identities; such scripts would have to use the new scripting functions for working with display names.

Well, it's broken badly at the moment. Users with 2.x viewers capable of seeing display names will instead see "???" as both the display name and user name for themselves and every other avatar including their friends lists and really anywhere display names are shown, on Magnum RC regions that are capable of generating display name info. Oh, and then there's SVC-6290 which suggests this feature is indeed very far from ready for prime time.

Source is apparently now available.

Yes, I am very sure that's true. (I'm embarrassed to admit, however, that I got distracted and didn't test any of that yet. My sole attempt at scripting a mesh was merely to animate a single texture, which worked as expected until my viewer crashed and after relogging wouldn't load meshes at all until I cleared cache. But I have no idea if one had anything to do with the other.) So, yeah, in one thread or another, I mentioned a scheme for script-based "animation" of meshes, using a different mechanism from the one for sculpties -- both of which are pretty kludgy. It would be great to have non-attached meshes rigged to a scriptable armature; that might be as much scripted deformation as we really need. But what I meant by neutered is that a mesh object can't have cuts, twists, slices, hollows, etc., applied by the script. The corresponding appearances would have to be built into the mesh(s) that comprise the object, with the script manipulating those components. In some ideal possible world, one might instead be able to perform basic mesh operations (e.g., binary solids) by script, instead of pre-built within the model(s). And that doesn't much matter as long as the objective is to have a virtual world full of pretty meshes. It only becomes a limitation if one wants to use arbitrary mesh shape as script output. I suppose the most obvious application for that is real-time data visualization, which will still need to be done by "plotting" particles or by forming a psuedo "mesh" completely by script manipulation of single poly prims.

Kinda. The thing is, MOAP enables all kinds of control and display capabilities for scripts that simply can't be emulated with existing prims (including pushing a lot of programmable in-world interaction out of LSL and into javascript)... but hardly any of that enabled functionality is available in products, which instead only expose functionality that can be approximated without MOAP. Why? Because there's no market for MOAP-only content because nobody can see it because no products dare rely on it because there's no market.... Another possible interpretation is less encouraging for scripters: Maybe SL is all about lining up one's pretty avatar with other pretty pixels and taking pretty pictures, as opposed to actually interacting with a scripted control surface to make all those pixels do anything. Mesh is a case in point. It has extraordinarily limited scriptability compared to normal prims, neutered differently but to about the same extent as the nearly inert sculpties. The sinking feeling for scripters is that in fact this may be about right, and that our obsession is of interest to a small and dwindling share of SL residents.

MOAP can be used for much more than just displaying web pages in SL. As a prim itself can act as a web server it is possible to do interesting things like using text box forms for enering text, display scripttime generated text in all maner of fonts, etc. Can it? I thought it only is able to stream stuff from an external server into SL? Yeah, it has a very unfortunate name. It is an essential feature of a whole new generation of scripting. Incidentally, such scripts are by no means limited to text output; as a simple example, I'm using the SL MapAPI for an automatically updated click-to-TP map of the Zindra continent at 2048x2048 resolution, and one of the Kama City monorail system. But "chicken and egg" is excruciatingly apt. Almost nobody sees MOAP currently, so my maps have separate layers of MOAP and static-textured surfaces, plus a touch surface because of one of many bugs in MOAP itself. Because nobody is seeing MOAP, there's been almost no progress in resolving all the jiras about it, and some of us have just quit filing new defects on it. A long-promised security measure, domain whitelists, has also shown no progress for a half year or so, creating another good reason for folks not to enable the feature, even if they're using a viewer that supports it. As a result, MOAP is practically dead. It was very exciting for scripters at first, but if nobody can see the products, and no bugs are ever fixed, there's not a lot of incentive for scripters to put out products using it -- and hence little reason for users to enable the feature, nor for Lindens to fix it properly. It remains to be seen if Mesh will be the same, but I think not: there are a hell of a lot more 3D modellers than there are scripters, and it's much easier to understand the breadth of Mesh impact whereas most folks still think of MOAP as YouTube worn by griefers.