Jump to content

Qie Niangao

  • Posts

  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. Speaking of second monitors, so far the thing I found most impressive about the Windows 11 migration is that it—at the same time I updated to iPadOS 15—didn't break Wired XDisplay. I've been using that to park windows away from the main screen, on an iPad Air as a tiny second monitor. I don't know that I exactly recommend that, but it is kinda cool and (I discovered yesterday) is one way to get a Windows touchscreen. I guess it's only a quasi-touchscreen because it doesn't seem to show the widget panel (Windows Key + W) when swiped from the left edge. Also, the taskbar, set to auto-hide, doesn't seem to show on the iPad as a second monitor, but I'm not sure it's different from how it worked in Windows 10.
  2. FWIW, this also appears to prevent logins with Catznip, but I can confirm that the Linden viewer can login to Aditi (albeit after a long delay, as usual).
  3. Right now there's a problem on the "Aditi" beta grid with Firestorm and Catznip (at least) claiming to be unable to load a certificate, but trying right now I can get in with a Linden viewer.
  4. I've never been a gamer, so I really don't care about framerates. On the other hand, I'm a scripter, so I care a lot about script lag. It's unfortunate that both low framerates and unresponsive scripts are conflated for many (most?) SL users, especially because they are almost always completely unrelated. That doesn't mean scripters are off the hook: there are plenty of LSL scripters who optimize for irrelevant considerations, creating products that may work fine individually, but put out more than a couple on a Homestead and watch the Scripts Run percentage drop off a cliff. A well-crafted LSL script has more in common with a device driver than with a conventional application program.
  5. That's at least as likely as my theory that a disgruntled Facebook admin took the opportunity to disrupt the flow of blood money.
  6. Probably. There are at least a couple of things that could be problems for scaling: Land permissions need to be checked by group membership, so when an avatar crosses a parcel boundary there is (or may be?) some kind of check that could take longer depending on the number of groups of which that account is a member. Probably worse is the fact that group chats track the online status of group members (although less than they used to, for larger groups), so the more groups to which accounts belong, the more stuff to check. (The first should probably scale log n, but the second may be a function of the number of group members coming and going X the number of group members needing to be notified.)
  7. Last I read (on a Twitter reposting of Reddit comments by a supposed Facebook employee), the cause was a flawed Boundary Gateway Protocol configuration change that Facebook admins pushed before the outage started, effectively partitioning their whole network from the rest of the internet and gradually starving DNS caches elsewhere. Presumably accidental but after 60 Minutes last night, who knows?
  8. FWIW, I use alts to hold places in groups too numerous for my "main account" to belong simultaneously. I especially do this for merchant groups that require payment, and then have that alt buy "gifts" using their group membership. (I also have alts that "own" land tenant groups, but that's kind of a special use case.) Usually my main belongs only to social or permissions groups with which that specific account really must be associated.
  9. I think I can imagine wanting to image several regions from above, with more / other features than are shown on region maps. Probably somebody knows the visual angles involved but I'd have to experiment to find the draw depth needed for a given radius of ground imagery. (I guess one could also stitch together multiple single-region images; even for just one region I remember setting a longer-than-usual draw depth, but probably "only" 512m.) Also the new 360 snapshot images present an occasion for long draw depths. Personally I haven't gone that deep, but I definitely use a longer depth for those than for just bopping around the grid… … and for that "bopping around" I tend to use only 96 or 128m, even though I have a shiny new machine and fiber-to-the-premises internet and really don't care about framerate. So I surely agree that restraining one's draw depth is a win (in my case because I prefer my SL textures to load and stay loaded).
  10. Well yeah, but presumably the LL lawyers were trying to avoid relegating neo-gachas to Adult regions with nation-restricted access, as they were forced to do with (their version of) "skill-based" gaming. It's actually risky for the Lab that the gacha restrictions can't be based on any stable set of laws, nationally or internationally, because a churning stew of such "loot box laws" are pending in various jurisdictions and are only delayed in the US on the dubious promise of industry "self-regulation." Visibly performing such "self-regulation" may be the whole point of LL's gacha ban.
  11. In case it confuses anybody, those two bits of LSL would not "compile to the same bytecode" despite having the same effect in an object with 3 links each with 3 faces; that's because they don't do it the same way. (Adding a link or a face in the Build Tool would demonstrate that difference without recompiling the scripts.) Also, the single function call will be much more efficient, executing the entire texture change in a single simulation frame and with fewer object update messages to the viewer. To generalize, whenever there's a choice between doing work in LSL or inside a library function call, doing it in the library will have a big performance advantage. (Pre-Mono, that advantage was huge because LSL execution was so slow.) Sorry to pick on this, but this preference isn't universal: I much prefer to keep to as few scripts as possible. There are special cases when it's better to spread scripts among multiple links, but from an efficiency standpoint fewer scripts will (almost always) win, often by a lot. To be precise, it's script time that will be reduced whereas script memory may be comparable because within a sim, multiple copies of the same compiled script will share one copy of the code memory (not data memory, of course, and not if the script copies are compiled individually). The script time savings are in part an artefact of how the scheduler works, so all scripts—even completely idle scripts—burn a little processor time every simulation frame.
  12. Not sure there's any real reason to teleport from anything but the experience_permissions event, but the following little script seems to teleport directly from a collision event, after the first time the agent grants permissions, both for me and a non-owning alt. vector destiny = <41, 89, 20>; vector facing = <42, 89, 20>; default { collision_start(integer num_detected) { key collider = llDetectedKey(0); if (ZERO_VECTOR != llGetAgentSize(collider)) { if ((collider == llGetPermissionsKey()) && (PERMISSION_TELEPORT & llGetPermissions())) { llWhisper(0, "TELEPORTING FROM collision_start"); llTeleportAgent(collider, "", destiny, facing); } else llRequestExperiencePermissions(collider, ""); } } experience_permissions(key agent) { llWhisper(0, "teleporting from experience_permissions"); llTeleportAgent(agent, "", destiny, facing); } experience_permissions_denied(key agent, integer reason) { llOwnerSay("NO PERMS, reason:"+(string)reason); } } Incidentally, to the subject of the thread, this should emit "NO PERMS" messages when the teleported agent steps off experience-scoped land if that works the way I think it does.
  13. Ah, I ninja'd an update into my post. All set. Been selecting wallpapers, then trying to figure out how we're REALLY supposed to activate that sexy widget panel, besides that clunky toolbar button.
  14. Somewhere I read that they preserved the "shy" taskbar that hides itself. Used to be so buggy but fixed enough that I rely on it on Win 10, so it better be in 11… … which my machine is currently installing. We'll see soon enough if it works. (Worst case I have an up-to-date Ubuntu box doing fileserver duty. Wouldn't run SL well though.) [ ============= UPDATE: Survived the upgrade intact. Catznip runs. The Restart cycle during upgrade could have better production values; if it were a Cupertino production there'd be a 4K surround sound ad for "The Last Duel" while we wait. ]
  15. (probably meant llGetNumberOfPrims() which would be better named llGetNumberOfLinks)
  16. Zindra's theme is supposed to be "futuristic" which is why there's a whole elaborate (but not very reliable) monorail system running through and around Kama City. The nearest stop to Osbourne Walk, http://maps.secondlife.com/secondlife/Osbourne Beach/95/250/30 seems to be out of service, but there's one not too far away at http://maps.secondlife.com/secondlife/Strute/54/104/39 that appears operational.
  17. Skirting the risk of descent into "cancel culture" drivel, there's some interesting semiotics here. Do we think van Gogh's self-portrait would include a pipe if painted today? He might very well smoke something if he were alive today. Not out of character for artists, right? But would he have included it in a self-portrait? A pipe is a very different signifier now than it was in the 1880s. In an image, smoking is now mostly associated with horrific death and debilitation, and that pipe now evokes an oxygen tank. "The Treachery of Images" indeed.
  18. Tobacco companies paid for cigarette ads for a reason. They always claimed that reason was to sway people from one brand to another, never to lure new smokers. But anybody old enough to remember Joe Camel knows that was a blatant lie. Persuasion is persuasive, and subtle persuasion is insidious. Anyway, it seems unlikely that banning SL "smoking" would have any meaningful effect on the total population of smokers. On the other hand, I can sure imagine seeing an avatar "smoking" could trigger cravings in those trying to quit. So SL "smokers" might want to think twice if they're not entirely sure all observers are immune to such cravings. (I had an avatar who used to "sneak out" for a "smoke" as a kind of character trait but I stopped for just this consideration.)
  19. I think the confusion here is that a script can only have permissions for one agent at a time, and just because it asked whether an agent is in the Experience doesn't mean that's the agent for which the script gets permissions. (It may ask that about lots of agents from whom it doesn't intend to use permissions.) That's why it needs to llRequestExperiencePermissions but if the agent is already in the Experience they won't get asked the dialog with the scary litany of component permissions. Once the script has taken permissions from an agent, though, I think it can ask itself llGetPermissions() and llGetPermissionsKey() to see if that's the same agent from whom it wants Experience permissions now, and if so, it shouldn't need to request them again, not even tacitly.
  20. I asked at the most recent Concierge & Land user group and was told that the 360 code will be rolled-up into the mainline viewer source, so undoubtedly Firestorm (and all TPVs) will eventually pick it up in a future release. That's in contrast to the Lab's previous 360 viewer that remained on a "project" branch. There's nothing especially great about the current 360 viewer other than that 360 imaging ability, so personally I only use it specifically for that purpose, and that's with graphics settings for high image quality at the expense of framerate (extra draw depth, ultra everything, even tweaked-up RenderVolumeLODFactor), but I guess that all fits in a "graphics preset", not needing a separate viewer installation.
  21. It's up to the Estate owner what they want happening on their regions, but personally I'd never discourage a tenant from using their prims effectively, even if they encroach, as long as they aren't causing any trouble for other tenants. Just seems bad business practice to be fussy about such things. On the other hand, I can see that permitting mutual encroachment requires cooperation and understanding among renters, and that's gonna be more difficult for leases with higher turnover rates. Anyway, in this case the OP doesn't want to deal with such encroachment, and as Estate owner, what they say in the covenant goes. Now, in the interest of enforcement, an script idea I've not tested at all: Imagine there's a periodic llCastRay() along the parcel boundaries from ground to 4096m altitude; it could gradually walk the boundaries to stay well under the raycasting throttle (and be mindful of the region's physics lag because llCastRay is implemented in Havok). In theory, llReturnObjectsByID() —also tightly throttled—could return anything found by the raycast, right? If it's this easy though, surely somebody is doing it already, right? It could miss some objects (e.g., any that have linked "stuff" on either side of the parcel border but no link on the border itself), but could it also have false positives? If there's any risk of that, the best a script could do would be to report a list of potential encroachments as a possible aid to manual enforcement. (Or maybe there'd be so many misses that the whole idea would be impractical. I bet somebody knows.)
  22. If there were a way for scripts to change parcel access—and the visibility option while we're at it—that would be a huge win. It would be even better if, as you suggest, there were a way to set it to do that without a script. And better still if that were the default.
  23. Only old fogeys sort inventory. I stopped using email folders the day I joined the gmail beta, so many years ago. And yet, as a new scripter—and old programmer—it took me a while to accept that LSL has no concept of files or filesystem. (Closest it gets is read-only access to object Notecards.) Turns out LSL was just a bit ahead of its time:
  24. Interesting. Sit Target teleporters have been around for ages and they certainly do work across region borders, but I'm surprised they've changed since the wiki recorded back in 2009:
  25. Apparently I have SomaFM stations set as "land radio" on some of my parcels, which doesn't have much impact becaus I almost never have sound turned on myself, and my parcels don't generate a lot of traffic. It makes me wonder, though, how small this streaming world really is, if little ol' SL ever contributes noticeably to SomaFM's demand. Perhaps a busy event might draw a hundred avatars (or more, across several regions) and maybe most have streaming audio enabled, so if a stream usually gets just a few hundred listeners, SL could be a signficant factor, I guess. In contrast, if a stream got a few hundred thousand listeners, nobody would care what SL demand may come or go. So evidently the scale is smaller than that. Imagine we had to come up with a technical solution. I think Coffee is headed in a promising direction with: Six months may be a bit generous because any listener could retain the stream URL until it quit working, and use it anywhere on (or off) the grid. Suppose they "sold" a land radio script that took payment in daily increments (like, a year's worth in advance, say), where paid-up units automatically get a new working stream URL every 24 hours. Might that be viable? In theory, listeners on unpaid parcels could snoop those URLs (llGetParcelMusicURL() would need the landowner to be complicit to mechanically leak the new URLs, but anybody can get them inside the viewer), but I think a lot of folks would happily pay-up instead. Certainly more than donate now, right? Maybe this is trying too hard.
  • Create New...