Jump to content

Qie Niangao

Advisor
  • Posts

    10,826
  • Joined

  • Last visited

Everything posted by Qie Niangao

  1. That's at least as likely as my theory that a disgruntled Facebook admin took the opportunity to disrupt the flow of blood money.
  2. 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.)
  3. 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?
  4. 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.
  5. 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).
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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. ]
  11. (probably meant llGetNumberOfPrims() which would be better named llGetNumberOfLinks)
  12. 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.
  13. 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.
  14. 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.)
  15. 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.
  16. 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.
  17. 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.)
  18. 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.
  19. 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:
  20. 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:
  21. 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.
  22. I agree, with a couple caveats. First, I'd recommend carrying something like a smartphone everywhere you go, or at least a phone capable of both placing emergency calls and recording video, either of which one day may save your life or somebody else's. (A sim card is not needed to call 911.) Second, however, all devices need regular updates to reduce security vulnerabilities, and that means a reasonably up-to-date version of the operating system, and that tends to mean a pretty new device (or, in the case of Android, an up-to-date third-party ROM). [ETA: I meant to add (redundantly) that I'd expect most MFA implementations to (eventually) support authenticator registration by some means besides scanning a QR code, and then basic desktop browser-based authenticators work just fine without access to cams or scanners. Also, I would never push for SMS text-based authentication; security-wise it's pretty obsolete even though some places definitely still use it.]
  23. In SL, MFA is still optional, as is Microsoft's move to get rid of account passwords for now, but eventually passwords as an authentication secret will vanish everywhere. They simply do not work and never have. Long before the Lab makes MFA mandatory (if that even happens within the SL product lifespan), they'll surely get it working with any of the many desktop authenticator apps that can be enabled by text instead of QR code. (Or maybe they already have this, I didn't play with it that much.) For now I only set it up for an alt's account, just to ride out the first wave of bugs.
  24. It may be open to market research, but my guess is that they'd lose more Mainland business than they'd gain at this point. Bellisseria is a great illustration of how Mainland might have been, but while it's true that the orb & whitelist ban restrictions came to Bellisseria after it first opened, that all came quite early in its expansion, before many orb aficionados could establish full entitlement. Also, at that point, Bellisseria was under such great demand—further heightened by the new neighbor-friendly landownership policies—that it could easily absorb a few folks returning to Mainland for their augmented "privacy" role-play. Mainland itself is a very different situation now, with ancient orb-worship an entrenched religion of believers in the god-given property rights of pixels. If intrusive parcel and script settings were no longer available on Mainland, of course Estates could fill the demand, but I'd fear more than a few folks would just quit SL land ownership altogether, out of spite. On the other hand, if the Lab can convince itself that, net-net, more tier will get paid with a less explorer-hostile Mainland and more of the "privacy" market moved to Estates, they simply must do that. Two tangents: I don't recall the whitelist banline ever being other than 50m Above Ground Level. I vaguely recall the explicit "blacklist" bans extending upwards from 768 to 4096m when the build height was raised, but I'm not real sure about that history. It's possible that further development enabled by the cloud migration could make it much less expensive to run sparsely-populated regions. No idea where that may stand on the priority list for server development.
  25. I'm pretty sure, though, there used to be some enforcement against hair-trigger orbs. Not sure when we heard about it, but I'd guess sometime around when Zindra was created, and the reported penalty was only return of the scripts with a warning; I don't recall anybody saying a suspension was involved. Somebody should go to Governance (or Concierge?) user group to see what the Lindens actually think the Mainland policy even is now. I'd be surprised if there's agreement (and more surprised if they agreed that zero-warning kick-bans were just fine). As I usually post to these threads, it's far too late now to establish a meaningful "right to roam" policy for Mainland, but that once upon a time it would have made LL a lot of money over the years to limit the more restrictive access features (whitelist banlines, llTeleportAgentHome) so they'd operate only on Estates. For one thing, the pretend-privacy aficionados and proprietors of animatronic brothels, etc., would be paying slightly more for Estate fees than for Mainland tier, and more interestingly, Mainland would have been as visitor-welcoming as Bellisseria which has proven a very big draw (and, I'd suggest, not only for vehicle users).
×
×
  • Create New...