Jump to content

Qie Niangao

  • Posts

  • Joined

  • Last visited

Blog Comments posted by Qie Niangao

    Calling All Bloggers!

    Surely the contributions were approved long before this blog post soliciting them.

    Bets now being taken on whether the first post will be the one about finding true love with the aid of a vampire HUD, or the one enumerating benefits of breedables in senior homes.


    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.

    Linden Lab's New CEO

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

    A Farewell From Jack

    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.

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

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

    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.

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

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

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

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

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

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

  11. Yes, there is too much diverse functionality all packed into the current "Group" feature.  Keeping the full-functionality Group limit at 25 and adding another 25 "landless" Groups would have less risk of hitting the lag wall.

    It's been asked several times: what happens if under the new limit we fill up beyond 25 Groups and then the limit rolls back?  It may be wise to have a contingency plan for that, and it will take a bit of development.  So here's a suggestion:

    Every Group gets two new Roles: "Social Only" and "Inactive", mutually exclusive with each other and the "Everyone" Role, and with every member able to move at will among those three Roles.  (Eventually Groups should be able to remove the existing "Everyone" Role, and become a social-only Group.)

    Members in the "Social Only" role still get notifications and chat and appear on the member list, but the group is not among the limited number that have to be checked for land access permissions, etc; for all purposes related to land, it's as if they're not a member at all.  They can still choose that group to be their "active" group (so llSameGroup() will allow them to operate group-only stuff).

    Members in the "Inactive" role have no group permissions at all, except for the ability to reactivate themselves at any time and have their old roles and abilities restored.  They don't get group chat, don't see notifications, and cannot make that group their "active" group.

    If this seems viable, I might turn this proposal into a jira.

    Oh, and, while I'm jira-ing... Does anybody else think the "homepage" profile slot for individuals is needed even more for Groups?

  12. Yeah, I got the same permission violation.  Was going to vote because I got the same avatar deformation when trying out a rigged avatar mesh.  Among other problems...

    Which raises the question:  Where might one productively post questions about this stuff?  There's this thread, a whole forum for Mesh, and some posts popping up on both the Building and General Discussion forums (and I suppose theoretically Second Life Answers if one can bear it, although I don't see any posts to the Mesh category there, thankfully).

    I've been making up random disinformation on the Mesh and GD forums to try to get some answers out there, but it would be helpful if there were some place we knew to go that might get some attention from the closed beta participants, or Lindens, or really anybody who actually knows something.


    Can you post a link to an example of these "faces", with the 8 different texture maps so we can see it?

    That's easier then words sometimes.

    Good point, but let me try to use an imaginary extension of Jennifur's barrel example above, because I'm too lazy to create my own.

    Imagine the modeller had made the rusty metal bands around that barrel as separate polygons from those that make up the wooden staves.  Then it would be possible to assign a different material to the polygons that make up those bands -- which is kind of intuitive in this case, because they're metal and the rest of the barrel is wood.  So now, those polygons could be projected onto a separate UV map, textured separately from the wooden part of the barrel.  And one could change the textures separately: oak vs pine staves, rusty vs shiny bands, etc.

    To scripters, this is a big deal.  Well, to be honest, it's the only half-way interesting thing about Meshes that are exposed to scripts, but scripters are pretty much over that disappointment now and are casting about for anything clever we can do with those UV maps -- which as I mentioned are treated in a script as if they were a "face" or "side" of a normal prim.

    Anyway, so yeah: each of the eight textures that can be applied to different parts of a Mesh can have its own resolution -- and all the other attributes of textures, such as repeats and offsets (and glow and etc).

    In the terrain example, I would think the tricky bit will be to leverage the resolution available to those eight possible UV maps without lagging texture downloads.  So, one would want to tile repeating textures, not just project a single non-repeating image the way one would normally make a clothing texture.  But to get multiple terrain textures (sand and grass, say) to blend into each other naturally, they'll have to be carefully crafted, and aligned at the edges -- keeping in mind that these are repeating textures, so that in turn constrains the design of the UV maps themselves.

    The point is, it opens some very exciting possibilities for terrain texturing, but bringing it to practice may involve some tricks that aren't part of standard 3D modelling.  (For all I know, however, it all may be old hat in game graphics.)

  14. Yeah, I tried to warn that there was something special about "faces" with the scare quotes.  Perhaps "face" is too much a scripting term of art.  Those eight UV maps are separately addressable by script, using the same functions as we use for "faces" in standard prims (where each of those "faces" may consist of multiple polys).  Maybe I should have said "side", but that seems even more apt to be confused with "poly"--and indeed you used "eight sided" as a counter-example.  I guess I could have said "UVW maps" to be technically correct, but then neither scripters nor casual readers would have the first clue WTF I was talking about.

  15. Yeah, I do think that sculpty terrain is dead after Mesh except for some very special applications, but it's a bit complicated:

    Meshes probably won't work at megaprim scale.  Details are sketchy at the moment, but best guess is that mesh max size on any dimension will be 64m, so it would take 16 meshes to fully tile a region (which isn't always the objective).

    Each mesh object can have 8 "faces" (specified with something like "material ID" in the modelling program), so that means 8 possible texture maps per mesh.  That opens up a huge opportunity for terrain appearance -- and a new level of complexity in actually generating that appearance.  (It's not as if those textures will just fade into each other automatically, as with Linden terrain.)

    To match complex visual appearance of the terrain model would require a relatively complex physical model, too.  To partially sidestep that, one could first terraform the Linden land mesh to some approximation of the desired terrain physical model (lacking caves, etc), and then omit or greatly simplify the mesh's physical model.  (I would presume this is how most sculpty terrains work now.)

    Also, big meshes are assigned high primcounts (that of the highest LOD, because they're always seen at the highest LOD).    So if one isn't careful, a sim could have no prims left after mesh  terrain is in place.


    General reply here;  I think changing the tier for educational and non profits; sends a clear message to educators and non profits;  and that message is obviously that LL no longer wishes to support your efforts.  Other grids would be very happy to have all of you; even if LL isn't.

    Happy enough to discount their rates by 50% ?

  17. Although I could only stay for an hour, I was reasonably encouraged  by the generally constructive, problem-solving orientation of the  meeting at Rockcliffe yesterday.  Returning to these comments this  morning is rather less encouraging.  (I even started writing "A Reader's  Guide to FUD" but screw it: Everyone's a grown-up and capable of reading past the surface text of blog comments.)

    At the Rockcliffe meeting, I was struck by some things that are  probably painfully obvious to most people.  In particular, I was  disabused of the mistaken idea that educators and non-profits in SL are a  monolithic community with common interests (beyond the discount, of  course).  They come to SL for a wide range of reasons and have widely  varying uses of the platform.  I expect that these differences will  motivate different responses to the discontinued discounts.

    At one extreme, some rely on the population of SL residents as part of their mission.  They may use SL residents to influence RL outcomes, such as  an organization that drives RL donations (or membership, or other  desired behavior) because their SL presence and activities gain  increased awareness among residents of SL.  Or they may seek in-world  donations from residents, or rely on residents as volunteers, a  ready-made audience, experimental subjects, etc.  These organizations  are either in SL or they're not in virtual worlds; for the foreseeable  future, there's nowhere else to go with a comparable resident  population, and the "hypergrid" remains mired in... well, it's not going  anywhere any time soon.  These groups also must be very careful about  how and what they communicate publicly (on any topic, but specifically  w.r.t. the new prices), lest they alienate their resident audience.   (See "Beware of the Just World Hypothesis," below.)

    Other groups gain synergy by interacting with other in-world communities as part of their virtual world activities.  If, unlike the first group,  they don't rely on SL residents, they can say any inflamatory thing  they want, as long as it doesn't alienate other communities with which  they interact.  They are, however, constrained by the "network effect":  to retain the benefits of inter-group cooperation, to leave SL they  would have to move all the groups at once.  If any of those networked  groups also relies on the SL resident base (above), they can't move.  (This is why Facebook can do whatever the hell they want with user  privacy: nobody can leave because they'd have to convince all their  friends to leave, and the friends of those friends... and maybe Kevin  Bacon's second cousin doesn't want to move.  Any suggestion that  Marketing Linden attended the Mark Zuckerberg Charm School is purely  coincidental.)

    Finally, some groups function as standalone pre-existing communities or exist as technology experiments,  using SL as a 3D conference hosting site or sandbox.  There are no  strings attaching these uses to SL; these groups can go wherever the  functionality is adequate to their needs and the price fits their  budgets.  And, of course, they can say anything they want to anybody,  including other groups.

    I've mentioned constraints on what  different groups might say publicly.  Some prominent organizations have  been conspicuously silent in their public response to this.  I think I  understand why: their mission requires that they retain the support of  SL residents, and not all SL residents are going to rally to the cause  of affected non-profits and educational institutions.  And that's not  because those skeptical residents are jerks, but rather because there's  no narrative explaining the rationale of LL's decision.  The brain  abhors a vaccuum in cause-and-effect, and devises its own rationale for  events:

    Beware the Just World Hypothesis.

    In the absence of another explanation for misfortune, people  ascribe fault to the victims.  The "logic" goes something like: Bad  things happen because of bad behavior--it's a "just world"; somebody  suffered a bad outcome, so that person probably deserves it.  In this  case, maybe the discounts were abused (I raised this myself, in an  earlier post).  Maybe those who got the discounts were more trouble than  they were worth.  Maybe they didn't hold up their end of the bargain  for good PR, attracting and retaining residents, or whatever.

    There was more than a little schadenfuede at the fate of those  herded to Zindra.  They deserved it, right?  They were smutting-up the  whole platform.  Well... one step of "just world" recursion and we're at  "what goes around comes around," this time to the non-profits and  educators.

    It doesn't matter whether any of these explanations are valid or  even  plausible--what matters is that they fill in a missing link in the  chain  of causality.

    My point is to suggest that some responses may not have the  intended effect. Trying to rally the general SL resident population to  the cause of retaining the discounts may not work, and may even  backfire.  And emphasizing the positive contribution of communities with  discounted sims may help -- but not if accompanied by an appearance of  entitlement.

  • Create New...