Qie Niangao

Yeah, it was mentioned at the Simulator User Group on Tuesday as a problem in the latest server roll (which otherwise has some good features). Should go away with the next roll, probably next week. There was a request to just keep it this way—which on reflection would have some advantages—but imagine the complaints!

I wonder if we can be talking about the same thing. Granted, I avoid recording video (or even taking photos) so my needs are simple, but I cannot imagine navigating SL without using just the two alt-LMB and ctrl-alt-LMB drag gestures to position the cam, essentially instantly. No doubt, that "instantly" would be a problem for recording, though.

Unless you're already familiar with what Wulfie and Amelia were explaining, maybe try the description in the Knowledge Base, specifically the section "Keyboard controls". This needs to be so over-practiced it's automatic—no temptation to "cheat" with on-screen controls—before even starting to think about screen recording and the more advanced techniques Jackson described.

I did steal the idea, but I refuse to abandon a good April Fool's joke just because I'm late to the thread—nor just because everybody else is pretending to take it seriously.

If it's a good idea to take the exchange rate from 250:1 down to 100:1, surely it's a better idea to make it 1:1, or let's make it 1:4. But nobody wants to spend a minimum of US$4 for uploads, etc, so the NewL$ will need fractional units, . As long as we're going to have 2K textures, we should have high-resolution currency, too, so let's give three decimal places to NewL$. Oh. What a coincidence! 0.001 NewL$ = 1 L$. See what fun the central bankers have in Argentina?

One can edit one's profile on the web, but I don't think it's possible anymore to replace the photos without logging in and doing it in-world. Maybe there's still a back door for that, too. (I'm not sure the "copied" profile had the photos anyway, given that the OP specified "literally the same words" so maybe that's not a problem needing to be solved.) Anyway, aside from the photos, I think all the rest could be a trivial bit of LSL telling a web bot to scrape the text of a new arrival's profile and paste it into the mystery avatar's profile; could be done in a few milliseconds and might stay there until the next new arrival in the region, in hopes of freaking out the faint of heart (or something). Technically, I suppose it is a copyright violation. Hard to prove damages, but a cease and desist letter could be some lulz. Now where did I put that contact card from Dewey, Cheatham & Howe?

Now that I think about it, I was surprised to see this again a month or so ago, not having seen it for at least a year, on items only I can modify. Also, I use only recent viewers, so if a fix involved a protocol change that needed viewers to update to new messaging to prevent them corrupting rezzed content, I'd surely have that in any viewer I use. Trying to read through what remains of the old jira archive, I think they tried such a fix in 2021. One of the original 2015 bug reports survives in "[BUG-8715] [MAINT-RC] Material enabled objects with a diffuse texture set to alpha blending mode randomly (but often) change to alpha mode none locally. If the avatar that sees this breakage has modify rights over the objects, ALL observers see this change." But a couple other things: This frequency of flipping every couple of days is very much different from anything I ever saw or heard of before, so I wonder if this could somehow be something new going wrong. Or something about this particular situation (content, object owners' viewers or networks, something) could increase its occurrence it might be a clue for preventing the problem. In any case I'd definitely suggest letting Support know that it's happening with that kind of frequency. Weirdly enough, the region where I saw this happen recently (Tussock) is also running RC Ferrari. That sounds like a coincidence, except… how many regions could be running that RC?

Way longer than a year. But it's not that there haven't been attempts to fix it. Apparently what happens is that textured surfaces are actually set to the wrong alpha mode by viewers visiting the region attached to avatars with permission to change the affected objects (usually their owners). As it was explained to me it's not exactly a bug so much as an unfortunate design of the messaging protocol that makes it possible for a network error to actually flip the bits controlling alpha mode on those objects. I imagine that locking them would reduce the likelihood of that happening, although that's just a guess based on that explanation.

Do the HUDs necessarily respond to random objects chatting at them or something? I ask because scripts can't see HUDs just by using llGetAttachedList, but could see the other attachments, but really, who wants to look inside a vampire's mouth? What might work is to hammer the Search interface to the Bloodlines page with the avatar name, but I suspect that database includes everybody who ever mistakenly accepted a bite request and didn't know to get themselves removed from the database. (Actually… IIRC, they used to keep a record of people who rejected or had themselves cured or whatever it takex to un-vamp one's virtual self, so god knows what Search returns for recovered bite victims.) But with the OP's reply, I realize it's not necessary to find all vamps, only detect when they bite, which seems as if it should be impossible unless the system goes out of its way to make that detectable. Right?

There's a fairly recent (but closed) bug report about something that sounds similar (but I'm not sure it's the same thing).

Oh, sorry, I didn't mean they copied themselves back. I could drag and drop them from "My Outfits" into another parent folder and they'd move there, so then I was testing whether I could just drag them back from that other parent folder into the "My Outfits" folder, and instead of moving there, they copied, also leaving the copy where I'd put them in the other parent folder. It's fine, just unexpected. (This in Linden viewer 7.1.4.8149792635 ) While wearing an outfit from outside "My Outfits", if I use "Save as…" from the "My Outfits" tab of the Avatar window, it saves it into the "My Outfits" folder (which seems reasonable I guess) and "Save Changes" saves it to whichever outfit folder I wore, so that's fine too. I too don't see where the outfit title changes but I'm also not sure I'm looking the the right place to see that.

Hmm, yeah, and I did this for a while and then stopped and I have no idea why. Maybe I just got lazy. Before I sweep all the ancient outfits in the main folder into regular folders, I just wonder if I'd be causing myself future grief somehow. The moved-out folders seem to copy back into the Outfits folder (copy, not move, which is okay but slightly weird) in case that's something I'd want to do for some reason. I can't imagine trying to get along without outfits. Too many dependencies among items, so when I'm dressing "from scratch" I still need to use sub-assemblies of stuff that saved together in one outfit or another. Also, without outfits, how do all the BoM layers know in what order to stack? I don't want to have to solve that puzzle again each time I'm wearing a particular combination of "tattoo" layer stuff.

Here's a slightly different switcher: switcher() { if ( on ) { list parms; integer link = llGetNumberOfPrims(); do { parms += [PRIM_LINK_TARGET, link]; integer side = llGetLinkNumberOfSides(link); while (0 <= --side) parms += [PRIM_COLOR, side, <llFrand(1),llFrand(1),llFrand(1)>, 1]; } while (0 < --link); // use 1 to skip root llSetLinkPrimitiveParamsFast(1, parms); } else llSetLinkPrimitiveParamsFast(LINK_SET, [PRIM_COLOR, ALL_SIDES, <1,1,1>, 1]); on = !on; } Mostly, this squanders memory to construct a big parameter list to be used in a single function call, instead of one call per link; if memory is a problem, make all those calls instead. But I'm allergic to making a call in every loop conditional so I just count down the loop control variable from a single call to llGetNumberOfPrims and llGetLinkNumberOfSides. (It's also handy to count down in any loop that deletes some list elements along the way.) Reading the initial script, it seemed to want to skip the root prim, but I wasn't sure that was intentional. If it was, then use 1 instead of 0 as the terminal test of the link do loop. But maybe it meant to worry about the case with only a root prim, that doesn't loop over links. For simplicity, the above code just assumes there will always be multiple links. I also worried about "at startup switch on automatically" which might have wanted it to paint the colors initially, without a touch. If so, I'd move the "on = !on" assignment inside that initial conditional test, so it reads "if (on = !on)". [ETA: Oh, heh, forgot to mention the main difference, which is to paint each side randomly, not have all sides of a link share the same random color which would use ALL_SIDES instead of the nested while loop over side.]

I don't see a problem, just need to decide what triggers activation and deactivation. the blood spread would be in a timer event (not a sleep loop) so a deactivation can abort it mid-spread. Assuming the puddle's coordinate system is sensible, should be fine.

If the Land Use Fees table shows 0 monthly tier is authorized, you shouldn't get charged, however that billing is a full month in arrears, so you will be charged if you owned land or donated tier to a group at any point during the 30 days* before that billing date. Incidentally, you shouldn't be able to set that tier limit to 0 if you still have tier donated to group or own land, and it's not supposed to matter where that table is set in determining what you're actually charged. That is, if you don't own land and don't donate tier, after a full month of that being the case you should stop getting charged, regardless of where the table is set. The value set there is still useful, though, in making sure you get a warning if you try to acquire land exceeding that setting. (Nonetheless, call it superstition, I'd always set it to the correct value anyway, just to make sure.) _______________ * I think it really was 30 days at one time, but it now seems to be based on day of month, so the bill on March 11th, say, should correspond to the 28 days since February 11th, and the one on April 11th should be for the 31 days since March 11th. Or something like that.

First I just want to say that I'm easily confused, so don't assume you were confusing in anything you said. Anyway, I think I now understand what you're trying to do, and it is absolutely possible. Now we just have to figure out a reasonable way to make it happen. It seems this pose stand already handles both avatars and already comes with a multi-sitter script (the "[zED] MPS" system). Now that makes me suspect that the pose stand consists of more than one link, and that both links are scripted with that system. There's no real requirement that a multi-sitter script be present in both prims, but the few items I have that use MPS all seem to do that, with separate "Settings" notecards in each, and I'm lazy enough to guess that's how the pose stand works. If that's right, maybe start by simply duplicating that configuration and seeing if you can get both avatars seated and animated together on a fresh, similarly scripted linkset. Once that's working, I'd try simply dropping the rotation script into the root prim and seeing if it's close to what you want. (I agree with Quistess that a more general solution would use three prims, the root doing the rotating and the child prims being the sit targets for the avatars, but maybe we can get close enough by imitating this pose stand as closely as possible.)

I'm standing on it. Got there by searching Maps and teleporting. My script says: Region restarted at Wed 2024-03-27 08:13 PDT, 0 days, 23:32:27 ago Sim channel = Second Life RC LeTigre, Version 2024-03-18.8333615376, Agent limit 44 So yeah, it wasn't a restart. I wonder if there could be some very weird network problem between your part of the world and AWS

Hmm. I think we may need to understand what's supposed to be spinning here, with "a new technique with the camera and a spinning object." But I'm also unsure what this couples pose product consists of, with a pose stand containing a few single poses. Unless that "pose stand" was really a multi-sitter for both avatars in the couple, I'm inclined to agree that whatever scripts are inside, they won't be useful for setting up your pose(s). If it were me, I'd probably just start with AVsitter because it's in wide use, free/open source, and has tools for moving around posed avatars, saving configurations, etc. It's not magic or anything and one could certainly work with scripts from scratch, too. But however you get these avatars posed together, there's something that's supposed to be set spinning, and I'm not sure if that's the cam spinning around the avatars or the avatars spinning around with the cam watching, or the cam and the avatars spinning around with the world whizzing by behind them, or something else entirely. However that's supposed to work is going to determine what gets linked to what, with what as root, and where that rotation script belongs.

That's kinda the hard way to do it and defeats environments that have optimized for PBR. Maybe try cranking up Preferences / Graphics / "Brightness (exposure)" so you don't have to use personal lighting.

Well, the wiki's LSL portal is here, and you can search the whole SL wiki from there, but I don't see a page for the Society nor the Preserve. On the other hand, the Society has come up in the Forums a few times and the Preserve many more times in case any of that is of interest.

That's why they needed a throttle. Instead they destroyed the whole representation.

I know, I know! TikTok! It's the answer to everything! (Although TikTok appears to have peaked and Zuck's loathsome Instagram is somehow the new growth platform. Pick your propaganda algorithm.) Actually, I didn't realize how much I'd missed in this thread before I posted, so I should have clarified: I don't honestly believe that younger generations are incapable of learning directory hierarchies, nor even that they need some remedial tree-training. Rather, I think they simply may not expect to apply that to a game inventory, nor to other tech operations us old coots may take as revealed truth about the universe. So here's a dirty little secret: I barely organize my SL Inventory at all. Stuff I create I kinda need to keep structured at least while I'm working on it, but otherwise stuff rarely gets sorted at all… except chronologically: Every few years I sort everything by date and shovel strata of stuff into year-labeled folders or the Trash (old landmarks, etc.) and rely on search and sorting to find anything I want to wear or use. Why? Because I outgrew folders. I never sort email, for example. Once in a while I'll tag a category of stuff that will stay relevant for a while (and gmail loves labels), but I'll never manually sort mail into folders again. That habit of eschewing folders carried over to my SL inventory management practices, as much as I can get away with it. I'm not promoting this approach to the SL inventory, I'm just saying that people adopt different practices based on a range of experiences. Different practices may benefit from different affordances in the interface, but mostly they just work with whatever the system provides; the difficulty is mostly communicating among those who adopt those different practices.

I dunno. Although they have folders, seems to me iOS and even Android go out of their way to disguise the filesystem(s) and scatter most of the directory structure around invisibly to the end user. Load a proper third-party file manager and behold a whole, heretofore hidden storage hierarchy. So I wonder if the "app" model of phones has made the average user think of storage as unstructured magic. Who needs "files" when there's "user data"? And in SL, objects have inventories ("Contents") but nope: no storage hierarchy permitted. I bet there are funky old games like that, too, where the player collects stuff in one big bag of loot.

That part is interesting, inasmuch as the Bluetooth connection works with no issue until Firestorm tries to use it for a very slightly different thing. If you haven't already tried with a wired USB audio connection (Apple's USB-C EarPods are surprisingly not awful for the surprisingly reasonable price), it may be worth seeing if there's something amiss in Firestorm's voice configuration. Usually I'd fuss about the USB-Bluetooth adapter approach, which always caused me problems that magically went away when I got a motherboard with a proper Bluetooth + WiFi module, but if you're only having problems in p2p mode, that doesn't really seem like a Bluetooth problem. As you may know, the Lab is in the process of replacing Vivox with WebRTC, and on a pretty accelerated schedule. That might possibly fix stuff.

Yeah, this is one of SL's older self-inflicted wounds, confusing instance with class: mesh models are not first class assets to be manipulated in the world, where only individual instances of those models survive the upload process. This is unlike every other object primitive that can be morphed into any other by script. This decision to neuter mesh was intentional, as I understood it, in service of mesh modelers who feared IP infringement (which was a problem with sculpties and prims). Now it all looks pretty anachronistic. Soon enough human-crafted, artisanal mesh will be quaint, the hand-carded wool or hand-thrown pottery of virtual worlds, but SL will still prevent AI from morphing its mesh content.