Qie Niangao

The scope of reflection may be how "reflection probes" got their name, but that's really not where they're basically indispensable, which is controlling (to some degree) how much damage an EEP setting can do to various scenes when viewed in a PBR viewer. That's of practical significance because in SL one EEP setting may apply to a whole region or at least a bunch of distinct structures. But wait: the EEP gets revenge! It can partially neuter the Ambiance setting of all reflection probes in that environment. This too might even be practically useful, but this lighting tit-for-tat is anything but intuitive.

There's a bunch of this I don't understand, but I can't imagine using object descriptions to communicate between objects. It appears that Box A sets its description, rezzes Box B, and llSleep()s for two seconds in hopes Box B will finish rezzing and reading the description before Box A wakes up and rezzes the next Box B. That'll probably work almost all the time, but it's sure not to work some of the time, and there are multiple widely-used approaches for communicating between a rezzer and its rezzed children. See the object_rez wiki page for a couple cookbook examples, or try something else, perhaps communicating via the Experience's KVP persistent store (since all the scripts can be compiled to that experience), but whatever the medium, the logic mustn't assume the rezzed object is ready to do anything until it says it's ready. This section, I'm sure, explains why there needs to be a separate Box B instead of just rezzing the HUD directly, but I've reread it a dozen times and can't understand: It's not obvious to me why a freshly rez'd HUD can't just do everything Box B is doing and then decide whether to attach to the target avatar. If at all possible, I'd remove Box B from the architecture, removing a whole raft of potential failure modes with it. With the llSleeps between rezzes, it's not surprising that some avatars will escape the region before anything asks whether they have a HUD attached, requests Experience permissions, or tries to attach, but if it remains unexplained after tightening up the delays you could log those attempts (to Experience KVP if nowhere else) to gather more info about which avatars are falling through the cracks, and maybe why. Maybe somebody who deals with temp-attached objects across region borders will know if they just fall off sometimes, even if both regions have the Experience enabled. It wouldn't seem too surprising, considering that regular attachments fall off occasionally on teleport.

With the disruption to various SL product categories caused by glTF materials, I'm not super confident that the bigger chunks of glTF scenes are going to be any less disruptive. Integrating PBR in SL required lighting volumes (reflection probes with ambiance settings) to patch it together with EEP environments, and that patch has some pretty rough edges: suddenly prefab structures need to come with EEP-aware parts that will baffle customers. I can't begin to guess what patching will be needed to make imported glTF scenes coexist with other aspects of the SL platform ecosystem.

I hope it's true. I notice all the Bluesteel sandboxes are offline at the moment. 😮

Presumably this applies to the Guided Tour System described in this recent comment, not to the original proposal (which I understand to have been abandoned or at least suspended indefinitely). I have no idea about the Guided Tour System but I'm quite sure nothing from @Anaimfinity would be like that. I assume this is in comparison with notecard-driven systems, which is probably true in this case, but access to list items in script memory is no longer the guaranteed winner overall. Even simple search with llListFindList isn't free, and more sophisticated text search of list memory is woefully slower than regex matching with llLinkSetDataFindKeys. This particular application may access data mostly sequentially, so search may not be a consideration, but sequential access to linkset data is also very fast and synchronous, unlike how notecards worked until, basically, right now. (And of course linkset data is large and frees script memory for other uses.) Installing on the Bluesteel channel today is the "Gingerbread" RC that includes synchronous notecard reading. It's a very big deal for other applications (bearing in mind that at any point, the notecard could be uncached due to a region restart, if nothing else, so must always include async recovery). But for this application it could only apply to loading memory or linkset data from notecards at the start of a tour, because the notecard won't be cached in the region after the one where it was last read. That notecard reading will be much, much faster when re-implemented with llGetNotecardLineSync(). For this application, I'd still choose asynch access to the relatively vast shared store of Experience KVP, now that it's not limited to Experience-enabled land (as I mentioned above). All this said, though, I think it wise to avoid a proliferation of diverse automated vehicles on non-regular Mainland routes. As @CarlaWetter mentions above, it's one thing to encounter a few easily identified phantom vehicles travelling established routes known to all drivers, and quite another to need to dodge unfamiliar, potentially non-phantom vehicles with riders who aren't driving. I just don't think we need more of those unless they're fantastically more sophisticated at collision avoidance than anything I've seen on SL roads.

You'd think that maybe LL would want to do something about that . . . Before you know it they'll be calling SL a sympathetic, well-meaning, elderly game with poor performance.

Oh, thank you! I completely overlooked the existence of the animation when I suggested "no permissions" would be needed. As an attachment, though, it really wouldn't hurt to llTakeControls anyway (doesn't actually matter which controls) just for the trick of continuing to work on no-script land. Not sure how much no-script land allows pushing, though, so maybe there's not much point making sure the script can run if it can't actually do the push. In fact, it could be a benefit to not run on no-script parcels if that prevents the kicking when the parcel is also no-push. But either way, if the script is running on a no-push parcel, one could avoid the kicking animation by beginning the collision_start() handler with something like if (PARCEL_FLAG_RESTRICT_PUSHOBJECT & llGetParcelFlags( llGetPos())) return; to just bail out without kicking or playing the sounds or anything.

Yeah, that thread was from a couple years ago. As shown above, there's now a way to see more info about a playing animation in modern viewers. (That's the Linden PBR viewer, but the feature isn't that new so it's probably in most viewers currently used.) There's often talk of figuring out a way to inform the sim about these details too, but I suspect that will await broader changes to animation.

There are very specialized ways to do something similar, but as Wulfie says, there's no direct way to detect that you've clicked another object or avatar. It's possible to know where the avatar's cam is pointing (in general, and especially in mouselook) and llCastRay in that direction to see which avatar it intersects first. Or, to be able to click somewhere other than exactly where the cam is directed, a HUD covering the full display can detect clicks and project them into 3D space although this is fraught with complexity, some of which will be reduced by new features in the upcoming Gingerbread release, notably LlWorldPosToHUD. (Also perhaps of interest: llGetCameraAspect() and -FOV.) Obviously this is all a lot more bother than just a touch*() event.

This certainly could be modified to trigger the "yeet" effect from a collision_start event instead of a click-triggered sensor() event, and in fact it would be safer inasmuch as the current script actually "yeets" the nearest avatar within 2 meters, regardless of where you click. It would also be simpler (no permissions, no controls, just a little extra housekeeping to filter the collision_start events for avatars and probably add a little hysteresis). Note, however, that either way, such a script won't work on land set "no push" because it's effectively a push weapon, however light-hearted its intent. It doesn't actually animate the "yeeted" avatar—animation requires permissions, one way or another—and instead uses the llPushObject call on the last line to do the whole deed. That and other physics operations on other avatars won't work on "no push" land. (Incidentally, the calculation here doesn't scale the force by distance, which is kind of a big deal since the effect is reduced by distance cubed, so maybe it will need adjustment for use in bumping proximity.)

Yeah, it may be worth a peek at https://secondlife.com/my/land/landfees.php to make sure you understand what's going on here. If the 8256 m² parcel is the only land you own (no Linden Home or anything), that US $31 monthly fee should buy a Premium subscriber 9216 m² total (8192 + 1024 Premium bonus) or 8704 m² with a Plus subscriber's 512 bonus, or 10,220 m² with the 2048 bonus of a Premium Plus subscriber. Then, in addition to this bonus free tier that @Rowan Amore points out, there can be that additional 10% bonus for group-deeded land that @Sylvia Tamalyn mentioned. A Linden Home parcel can't be deeded, but other Mainland can, and it's just a matter of forming a group with an alt in Owner role and deeding the land to that group. Doing both of these things will result in a substantial balance of additional Mainland and/or Linden Home you can own without paying additional tier.

Altruism, especially philanthropy

Pretty sure I heard one of the Lab speakers at the SL20B talks explicitly not rule out VR in SL's future. But sounds like hedging its bets—doesn't cost anything to say "maybe, someday"—or at least it costs a lot less than Tim Cook spent on Apple Vision Pro on the off-chance Zuck was onto something. I mean sure, once the technology gets beyond strap-on headsets, it might be worth exploring. Who knows? SL may still be around in twenty years, and maybe by then we'll have VR without these ridiculous face-mounted iPads.

I'm not beating the SL bushes hunting for popular music clubs, but if I were, I don't think I'd search regions for those venues, any more than I'd use it to find scenic or role-play settings. That's what blogs are for, found through Google and by monitoring Blogger Network posts in the Community News blog. The existence of that particular Linden blog suggests that the Lab is aware that Search isn't an efficient way to find events and venues. Also groups. Might find Groups in SL Search (sort by Popularity; I'm not sure how that's measured but it does suppress old, moribund groups), or just make it a topic of conversation when you meet somebody with the good taste to share your particular interests: "What groups should I belong to, to hear more lofi electro swing?" (and as an icebreaker, it sure beats "cute avatar!") One group that might be of interest for live music, poetry, gallery exhibition openings, etc: "Hotel Chelsea Manhattan NYC". (Notices are about that venue but chat is broader.) It's just an example; there are many groups that will help you find events that match your interests. Curate a private network of trusted groups and blogs. Search can help build that network but it's too noisy and gamed to use for finding events and venues directly.

It's certainly possible for such a script to exist. This seems a pretty specialized requirement, though, so it's pretty unlikely you'd find a suitable script already written, but it's also not a particularly difficult script to write. Some specs to work out, off the top of my head: Does it only restart when the item is attached (meaning it needs to handle the attach() event) or also when the user logs in with the item already attached (need the on_rez() event)? or also after teleporting (CHANGED_TELEPORT)? What happens after it's gone through all the textures? Does it stay with the last one, or cycle back to the first? How long between texture changes? How should the order be specified, or is it random? Are these textures going to be "regular" (Blinn-Phong) textures (for which llSetTexture() might suffice), or the new PBR (glTF) Materials? or both? (various options to llSetLinkPrimitiveParamsFast()) Are the texture/material assets going to be in the object's inventory, or referenced by UUID in the script? Which of these decisions can be hard-coded in the script, and which need to be options set by the user somehow? If you're writing your first texture change script, it's pretty important to have a "pre-load" surface where the next-to-appear texture can be painted at full transparency so it will already be in viewer memory when it's shown on the target surface.

You may want to send a support ticket to have somebody sweep up after whatever they did to your inventory. I googled for this and found one other reference in the wiki from almost thirteen years ago, a side-effect of one of the worst directions the Lab took in implementing mesh: making it impossible to change the model asset of an object. (Let's pray they don't repeat that mistake with glTF models.) So apparently when they changed their minds about that, they wiped everybody's mesh model asset folders, and the remnants ended up with that name. So that suggests one way this might have happened: perhaps you've been beta-testing something to do with the PBR Materials, which only comes to mind because I know it makes a new system folder. Or maybe something with this new-ish inventory folder image thing?

These and other comments help me see ways LL may indeed be able to do a shopping event unlike anything residents alone could run. If they can offer new creators an outlet free of charge, that's cool, and it's smart to let bigger names participate too, to help draw shoppers. So then the sheer size of the thing… quantity has a quality of its own (as Stalin may have said).

I'm all for snowball fights and birthday celebrations. But now that you mention it, I realize I'm not quite sure why the Shop&Hop events are necessary. They seem to be popular though, so they must be serving a purpose, it's just not obvious to me why that niche isn't filled by resident-run events.

Some truth maintenance: which I don't see promoted this time (unless I missed it) … Yep, I missed it, but stumbled on it today in-world. (Still can't find it on the event website but I'm obviously an unreliable scout.) The auction vendors show: Dinner with the Lindens 12 month premium account subscrption 6 month premium account subscription Name Change (from existing last name pool) — two auctions Pick a Linden Home name (subject to approval by Linden Lab) (I don't see where it actually says these are donated by the Lab, but surely they are.)

One thing to try, if you want, is to go to a big, not too busy sandbox, open the build tool first (Ctrl-3), and then try to rez it. Keeping the build tool open, check to see what it has selected (in case there's more than just the one gacha item). Such "coalesced objects" look different in Inventory, too, like a little stack of blocks instead of a single block, so maybe you already know that's not what happened… and yet, if it were me and I had trouble rezzing something, I'd still try in the middle of a big sandbox with the build tool already open.

I believe those numbers are totals from the last 30 days, so if the viewer was used at any point, it would show up there. If it's showing up when it hasn't been used at all for over a month, or if its number is rising while not in use, then it would warrant investigation.

Oh, I didn't know that. I wondered why the change. Regarding event listing sites, I found that Seraphim indeed does list it in its "Fairs and One-Time Events" category (which I don't often check). I see that last year it featured in the Modemworld blog but not until March 7, when it would close just five days later (so it may yet appear there this year, too). That timing suggests it was a few weeks later on the calendar last year. That post also highlights some significant Linden involvement last time: which I don't see promoted this time (unless I missed it) but such auctions sound familiar from another recent RFL event, though I forget which. Performances probably act as promotion for the event overall, through the performers' networks of fans. Besides fundraising, these events include information that raises awareness and educates, so that has some value towards the organization's program objectives. It may seem as if I'm shilling for RFL but my past involvement (other than a little shopping) was limited to writing a script widely used for a couple years at the old Home and Garden event.

I have no position one way or another about ACS, but I sure don't know where the Odyssey article got its data (from 2010). ACS must file a Form 990 every year to the IRS, so it's all public record. ProPublica has a handy Nonprofit Explorer that's one starting place for somebody with more of an accounting background. Also, GiveWell had a (2010) report analyzing how ACS programs spent donations on categories of patient support, prevention, detection/treatment, and research (it's more about supporting patients and informing the public and health professionals than research).

Probably true; there are differences between the US's 501(c)(3) and Canada's T3010, too. But it cuts both ways: the tougher the regulation, the more onerous the overhead in meeting those requirements, particularly for smaller scale local causes.

Okay, but people do. Personally, I don't often find stuff I want very much (really, at any events lately), but I'm more inclined to stretch the envelope at RFL events because I feel it encourages the creators' support of the cause. That said, I need to have a sense that the charity is doing good things, as opposed to, say, Diagolon or a terrorist organization. They don't need to benefit me directly: I give to the Humane Society for example and those aren't even my species. Yeah, probably the latter, but it's hard to imagine the RFL people couldn't know the S&H plans, so maybe this is just how it goes, year round every year; I honestly never paid attention before. What got me this time was surprise that the RFL event was even happening, but I'm wondering if that's just me and the entropy in my current schedule.