Jump to content

Qie Niangao

Advisor
  • Content Count

    7,920
  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. Qie Niangao

    Animesh and LI sky rocketing

    I'm still trying to assess whether Animesh is viable for applications wildly different from NPCs, requiring substantially simpler geometry. A couple weeks ago there was a thread in the Scripting forum in which a poster suggested Animesh as a low-resource-demanding way of making a ball appear to be tossed up and down in the avatar's hand. That may or may not have been the very best solution for that particular problem, and having a high Land Impact doesn't particularly matter for an attachment as long as it doesn't reflect true heavy resource usage. It's not hard to also imagine a freestanding contraption with simple geometry for which Animesh-like shape change would seem to be the best technical solution -- but prohibitively costly in Land Impact compared to other approaches (texture-flipping, say, or old-school translation+rotation of parts). Now, if there really is a justification for that 15 LI barrier to entry, then it's fine for us to stick with the other approaches. But those approaches send an object update for every call to llSetLinkPrimitiveParamsFast(), so that's not all that lightweight, low LI notwithstanding, and that's very different from a one-time download at the start of a looping animation. And of course texture-flipping burdens the viewer with lots of usually-invisible geometry, as I muttered about earlier. So... I'm thinking that 15 LI minimum may mean lost opportunities. (Personally, I have no interest in manually animating objects rather than calculating their transformation, but no doubt others' mileage will vary.)
  2. Qie Niangao

    Groups In SL

    Maybe so. I'm just relating what I remember of office hours from ages ago, so it's possible I've forgotten some details. I do however have a pretty definite recollection that Lindens were worried about increasing the number of groups per avatar because "groups" could be associated with land permissions, as opposed to hypothetical strictly social "groups".
  3. Qie Niangao

    Groups In SL

    Not people. The sim. [ETA: It's true, I anthropomorphize system components. They're variously naughty, sexy, cranky, etc., and apparently some of them speak Yiddish.]
  4. Qie Niangao

    Animesh and LI sky rocketing

    So... its practical application is limited to NPVs, then? Way back when (before I lost interest) there was going to be a project that would replace lots of texture-flipping to show and hide different mesh geometry. I gather that Animesh isn't that project. One virtue of texture-flipping is that it can be purely viewer-side once the server starts the animation... but even if it's too complex for texture animation, a script's resource demands should be much less than the recalculations this suggests -- and certainly incurs less land impact for interesting mesh geometries simpler than an avatar-like character. I mean, I'm fine with leaving some fully-transparent mesh rezzed, waiting for its turn at visibility, but I thought we were hoping to reduce that.
  5. Qie Niangao

    Groups In SL

    This is not all about group chat, and certainly the simulator performance hit of increased group count has never* had anything to do with chat. Years ago there were Linden developers already lamenting the decision to pool all "group"-related semantics into the single "group" construct, and the particular problems caused by land permissions being associated with group membership. Can an avatar even enter a parcel? Does it depend on their group membership? Oy, so many groups to check! It's not only parcel/region access, of course, but that's the one most traffic-sensitive. _____________ * "never" for as long as group chat hasn't been sim-mediated, which is as long as I can remember anyway.
  6. Qie Niangao

    Groups In SL

    I know some Estate owners who've been doing it all wrong!
  7. Qie Niangao

    Groups In SL

    Why are you blaming the Lab for something that's obviously the fault of store owners? Complain to them! They're using group membership as a marketing tool -- which is fine, but has consequences: it will inconvenience a certain share of customers who run out of the system-supported group slots. Also, note that increasing group slots isn't merely tweaking a number: it incurs real sim processing, especially in high-traffic locations, and especially when traffic teleports in and out or crosses between parcels. So have fewer groups, especially in your main avatar -- it's more important than reducing Inventory because the pain of excess groups just keeps happening long after you've logged-in. If you must keep those wasteful store groups, farm out as many as you possibly can to "shopping alts" that get their discounts whenever they buy gifts for your main avatar. (This is handy anyway, to route those pesky group notices to other email destinations than your main account. Note however that a group needs to be attached to whatever account is logged-in when that group's chat is useful.)
  8. Qie Niangao

    Agent Limit (Number of Avatars Permitted Per Region)

    To fully prevent the problem you're trying to solve, you'd need to make sure the sim's avatar slots could never be overbooked, which means much lower numbers. The (now) standard 1024 couldn't support even a single avatar, for example, because the area of a sim, divided by 44 avatars, is 1489.45 sq.m., requiring a parcel at least 1504 s.m. (because land comes in 16 sq.m. quanta). If you wanted to be allowed a visitor, you'd need a 2992 sq.m. parcel or better. Might it at least be better, though, if a single 512 couldn't gobble up all the avatar slots? Maybe. Nonetheless, the whole avatar distribution model (cleverly disguised as "land") depends on some pretty extreme overbooking. And a brief tour of the grid will reveal that there's always plenty of spare capacity almost everywhere. So that's just dicing up the overbooking limits into hyperfine chunks. And when, inevitably, somebody can't squeeze a visitor into their parcel because neighbors filled too many overbooking slots, they'll feel even more justified in their righteous indignation at the slippery tail of the Poisson distribution.
  9. Qie Niangao

    Add STOP button to menu :: music player

    This. The 10 sec individual sound clip duration fit an old, informal "fair use" standard for sampling -- which never got any real acceptance and didn't correspond to any practical threshold anyway. Once a script splices a bunch of those in sequence there's no protecting it from the music recording industry any time they choose to enforce copyright.
  10. Qie Niangao

    Crashed in no-script zone. Now my items are broken

    This is an ugly bug, but just to be sure we've helped as much as we can: You mentioned "I tried resetting the items; nothing happened" but resetting scripts will not also set them running; that's another step -- but if you're able to reset them, you can also set them running. (The killer is when you're stuck with scripted no-mod objects -- notably distinct from no-mod scripts -- which are to be avoided at all costs. Actually, any no-mod object is to be avoided at all costs. Trash all no-mod gacha junk now, to save yourself inevitable pain eventually.) It's theoretically possible for scripts to reset to an unusable state even when set running, but that must be extremely rare. In the special case of AOs, even if you can't get them to restore functionality by setting them running, all the real value is in the embedded animation assets (and maybe to a lesser extent the configuration notecards) which you can usually extract from the AO object and insert into another (free) scripted AO object. (But I don't think this will work if the old AO is no-mod and those animation contents are also no-copy, unfortunately. But if the objects were no-mod, you couldn't have reset the scripts either.) Finally, this specific bug only occurs if your home location is offline at the time you're teleported home by the security orb. That's probably what happened here, but if there's something else going on (perhaps something about being teleported from no-script land?) it would be good to check that out and possibly add to that jira or create another.
  11. Qie Niangao

    LAND PROMOTION

    Not sure this is what you're asking, but if you haven't already, you'll want to submit it for the Destination Guide. More info at the Destination Guide FAQ. Assuming you've already set the land to be listed in Search, you can give it a Place Page (which is really more useful for web promotion outside the Lab's own site). You can also pay to promote it in Classifieds (but I'm not sure how effective that would be -- I just don't know anything about Classifieds, so maybe somebody else can fill in that gap).
  12. Qie Niangao

    inventory in cloud?

    That must have been one of the Server-Side Rendering attempts, right? To be fair, five years ago the graphics power of a mobile phone or tablet may have been weak enough that SSR seemed a better approach (ridiculously high network bandwidth demand notwithstanding). But there were worse problems, too: they did very little to adapt the UI to a handheld, touch-control device, so the whole scheme was doomed from the start. That's no guarantee they won't repeat the same mistakes, but they would seem sillier now.
  13. Qie Niangao

    inventory in cloud?

    Personally, I think by far the most important thing for the survival of SL is a viable mobile viewer. Doesn't need to have everything the desktop viewers have, but more than Lumiya. The Lab is apparently working on it behind the scenes, but it's something they should have had five years ago. The SL userbase would be a lot healthier now if it had. But besides that: I almost never touch my Inventory, except very rarely when there's enough junk in Objects or top level that I start worrying about the 10K-per-folder limit. Otherwise I treat it pretty much the same as I've handled email since I got my early invitation to gmail: hands-off, no filing, no tagging, just rely on search and chronological sort to find anything. So, for me, it doesn't take much to be more valuable than offline Inventory management.
  14. Qie Niangao

    Revived JIRA for increase in memory limit

    I poked the bear. At least we're officially beyond the point where we're supposed to assume this can never ever happen because reasons.
  15. Qie Niangao

    inventory in cloud?

    My main concern would be opportunity cost: Whatever development goes into this would not be going into other features that might have a bigger impact on retention. And it's more than trivial development, too, because it would need to be at least as reliable (and secure) as current in-world inventory operations which took many years to get as robust as they are now. Looking at the new Auctions page, still not feature-complete and now months behind the expected date for resident-to-resident auctions, does not inspire confidence. And the very last thing any of us need is to have our Inventories corrupted, adding to the support backlog if fixable at all.
  16. Qie Niangao

    Revived JIRA for increase in memory limit

    But it doesn't work that way, unless those are some mighty big lines of code. As noted above, a Mono script can only use the memory it needs, regardless if it were to be blessed with a 128K limit. That said, there are occasions where I'd use that 128K if I had it available even when 64K would obtain only slightly less wonderful results. I recently did an event visitor counter, for example, for which I set capacities safe to the 64K limit that I may have doubled if I'd had the space, even though users might never notice the difference. One thing that would deter me would be if the larger script had double the Land Impact weight -- although it rarely matters, and of course never matters to attached scripts. Honestly, though, the profligate use of attached scripts makes it seem especially silly to fret over doubling a memory limit they'll never approach. I just got a pair of jeans -- jeans FFS -- with both a no-rez script and a (misconfigured) auto-alpha script, neither of which I can remove* and neither of which would be any worse if 128K were a universal limit. If we're actually concerned with script lag, reining-in the uncontrolled proliferation of scripts in mesh attachments would be a better place to focus attention. __________ * all because the creator is a no-mod flat-earther despite a stellar reputation in the SL rag trade.
  17. Qie Niangao

    Revived JIRA for increase in memory limit

    Strings are currently only limited by script memory, so... it would be a change for them not to change their max size if script memory doubled. That might be the right thing to do, but it would be another, different thing that might go wrong. And absolutely, they might catch any bugs with enough testing, but that could be a lot of testing. The project may take more resources than it appears.
  18. Qie Niangao

    Revived JIRA for increase in memory limit

    (In case that's in response to my post -- self-centered as that sounds -- I wasn't referring to bugs in existing scripts. I meant it could be unusually challenging to uncover all simulator bugs in handling new scripts > 64K.)
  19. Qie Niangao

    Revived JIRA for increase in memory limit

    The only real downside I see is the likelihood of weird implementation bugs that aren't easily detected in advance. I mean, who knows what functions unintentionally depend on the current memory-limited length of strings? Or what's been tacitly assumed about script size during sim-crossings and teleport hand-offs? And all the other stuff we aren't thinking of now, for which the existing regression test suite exercises only 64K? Maybe nothing will go wrong. Maybe it's a simple matter of changing a constant and recompiling the simulator. Maybe I could interest you in some shorefront the locals call "Marl a gogo".
  20. Qie Niangao

    Revived JIRA for increase in memory limit

    This proposes only 128 KB, merely a doubling of the current limit, so I suspect it actually has better prospects without the elaborate permissions and payment restrictions. It's not as if this will suddenly cause all scripts to double in size; the vast majority of scripts currently are nowhere near the 64K limit and having 128K available won't cause scripters to make those any less memory efficient than they already are. I especially doubt a pay-per-script thing will appeal to the Lab; making it available only to some level of Premium might, because Ebbe seems to like that direction and they may be having trouble dreaming up benefits to slot into those Premium levels. If it requires developing a whole new way of limiting access to certain users, though, that may be a deterrent; it may fare better if it can somehow piggyback on whatever "Experiences" are becoming. Also, the pose-engine example is... complicated. It's true that AVsitter at some point split its per-avatar script and this, combined with other script-level modules, makes a lot of scripts doing nothing most of the time yet using scheduler slots (and potentially boosting Land Impact for some furniture). Other engines (e.g., nPose) work and scale differently although they also have more scripts than would be necessary to custom-script a static set of furniture animations. And yet even a simple custom script will end up using two scripts for two sitters.* Anyway, the point is that larger memory limit might recombine AVsitter's basic per-avatar script for some very small reduction in overhead, but it won't revolutionize anything. One place where I personally would use this immediately is to expand pages served by llHTTPResponse(). I have no idea if this is a common usage or has any appeal to the Lab, but it's one application for which I've never found a practical, stable solution using multiple in-world scripts, and using external servers adds complexity and failure points. One difference between this application and the pose engine: The HTTP server script is limited by the size of a single string argument to a function call, whereas the pose engine script uses memory in lots of little references, and could in theory access the data elsewhere; nPose, for example, keeps less stuff in script memory and more in read-on-demand notecards. I've lately been tempted to hack the AVsitter source to migrate its preloading from notecards to Experience KVP store, just to circumvent the 0.1sec delay per llGetNotecardLine() with the much faster llReadKeyValue(). One can imagine instead directly accessing KVP for pose and menu data, not even preloading it into script memory (or maybe no more than a few menu pages cache). That rambling is to suggest that maybe there's some way to piggyback on (more available?) Experience KVP store to get much of the benefit of expanded script memory. But not all. ___________ * Using a script per sitter is not absolutely necessary, but it's simpler and (probably?) more time-efficient to retain permissions, one avatar per script. Back in the day it was also better at stopping animations for a no-longer-seated avatar, but I think it's been years since that actually mattered.
  21. Qie Niangao

    Star Spangled SL?

    Can't please all the people all the time.
  22. Qie Niangao

    Problem with world map

    Not exactly. Instead, the work of compressing all those region maps into zoomed-back images is done by the map server, in eight power-of-two scales. The documentation of the Map API has all the detail you never wanted, but as an example, you can see it working properly in these two intermediate-scale levels: http://map.secondlife.com/map-3-1000-1000-objects.jpg http://map.secondlife.com/map-4-1000-1000-objects.jpg I finally got into the jira and found that this has been broken at the very next step of zooming back -- since August!
  23. Qie Niangao

    Problem with world map

    Unfortunately(?) it's not just you, and not only in-world. Try zooming out on this map in a browser. This means that the map data collection process didn't complete the last time it ran, so some resolutions of the map never got generated. If the jira weren't in some Atlassian Limbo at the moment, I might try to find and re-open one of the several reports from all the times this has happened in the past. Maybe somebody can do that if/when jira comes back.
  24. Qie Niangao

    Problem with CHANGED_INVENTORY

    I think by "redundancy" KT was suggesting you don't need the if(change) conditional because the changed() event is only raised when change is non-zero.
  25. Qie Niangao

    How about a new sub forum in "People"?

    Right, so that thread would not have been appropriate for the proposed "anything but SL" forum. I'm not optimistic there'd be wide participation in threads where SL-related discussion is forbidden. Do people really care what other SL forum denizens think about such topics in isolation? Would that even be a good thing? Is there some benefit to filling people's time and attention with matters explicitly unrelated to the platform the overall forum exists to support? Also... y'all know there's Twitter, right? and Reddit?
×