Qie Niangao

... I'm thinking of adding values that runs along SLRR, LL Roads and Mainland's waterways. The VRC train scripts will only help you with the SLRR and other tracks laid to SLRR spec so they contain a "guide" rail prim. They won't help with other mainland roads and waterways, because the train navigates by following that guide rail prim, which it locates by sensor. (And to be reasonably efficient, that sensor needs to be short range and geometrically "tight", so I think it kinda needs to be down near track level, not up in the sky where a balloon might be. Linking might be an option, I suppose, as long as the balloon never wanted to be more than 55m off the ground.) If it were me, I'd fly the balloon along set paths described by waypoints known to keep it on the SLRR, or on whichever roads and waterways for which I plotted out the waypoints. (Admittedly, that preference may be partially the result of my having completely mapped waypoints for the SLRR mainline and branches.) ETA: Code correction.... and this: *I'm also planning to add a //Die script or at least something that will 'reset back to installed location' in the event where the pilot/passenger gets unsitted or displaced due to lag or region crossing, etc* As long as they stay on Linden rails, roads, or waterways, stranded vehicles will get returned to your Lost&Found folder, not accumulate along the road, because all that land has a reasonable auto return set. (At least the SLRR does, without fail.) Unfortunately, I know of no way to cross region borders that is guaranteed to work every single time. My stuff that does this--thousands of times a day--will occasionally get directed to some unlikely destination a couple of sims distant from where they were trying to move. I must say, however, that this most recent restart seems to have completely fixed this for me, for now. Fingers crossed.

I'm reluctant to complicate matters, but a thread with this title sorta calls out for some reference to the cliche of using a separate state that lacks any handler for touch-related events. While the script is in that state, new touch events will not be generated -- indeed, the mouse cursor won't show the object as touchable.

Attaching from Inventory doesn't require permissions, but anything rezzed in world that wants to attach to an avatar directly has to get permission first. I don't know of exceptions to that, although an already-attached object is granted that permission without having to ask the user directly. Once a script has a permission it can retain it, so I guess if somebody dropped such an attachment, it could be scripted to re-attach itself without needing to ask permission again.

... there will be 3rd party "feathers" added to the hat as well, so pre-bundling all the feathers before delivery is not really practical, thanks. Okay, but the prims that a script could use to form those feathers could be bundled into the hats in advance. In such an approach, a third-party "feather" is really just data fed to the hat script about how to form the feather from those pre-existing prims. The third party feather developers don't need to know all the magic of converting feathers to feather-forming data. Instead, you could supply them with a script to embed in their feather that does all the llGetLinkPrimitiveParams() needed to read their feather and all the communications of those read parameters from that feather to the hat's script. The end-user, then, would just rez the third-party feather somewhere nearby while they're wearing the hat, and an identical feather sprouts from the hat as if by magic. (Note: There are some limitations as to what properties of an attachment can be reliably modified while the thing is attached, and some of those depend on permissions, so this might bear some manual experimentation first. But I don't know of any problem with changed prim appearance.)

It can be an extreme pain because a parcel doesn't even need to be contiguous, and in fact the centroid of the parcel need not be contained within the parcel itself.

Not having seen the things under discussion, but from the description alone, it seems as if some of it may be simply scaling a sculpty in one dimension. To rule out invisible prims, you might try highlighting transparent (Control-Alt-T). I'd just caution that none of this can beat texture animation for lag avoidance. Swapping sculptmaps is especially expensive, as object updates go, because it also consumes cache. Mention of "mesh just around the corner" brings to mind the fact that attached Mesh can be weighted / rigged to the avatar skeleton to deform with the avatar (replacement limbs, Mesh clothing, etc). Unfortunately there's to be no mechanism for doing any sort of scripted deformations... indeed, no deformations at all for unattached Mesh.

Poenald Palen wrote: There are all kinds of areas that could use attention, so I guess they will work through them all bit by bit and then have to start right at the begining again? The moles are stuck in a mobius tunnel of content fixing that never ends! Now that I look into it some more, you're right, of course. Here's one list of broken content, in much worse disrepair than just having outdated information and an unappealing build. And I know the Moles do rejuvenate old decrepit sims. I understand that Rizal is a recent example -- and a good place to nab some fresh Mole content, including some pretty nice pine trees -- although I never knew Rizal's state before the renovation. Which reminds me... whatever has become of Luna Oaks Galleria? Seems like the most recent lottery for six month slots must have been at least two years ago. I wonder how many of the stalls still have content, and of those how many are by merchants with still-active accounts. It appears that the record is erased now, so....

For no good reason other than spare tier burning a hole in my pocket, I picked up at auction a 512 in Hanson, a snow sim with an old infohub. Now that I look around in more detail, the sim has lots of problems, but foremost among them is the crappiness of the infohub itself. As far as I can tell, the only information it provides is how to turn on audio and media streams, with instructional screenshots of a long since defunct viewer interface. Otherwise... as much as I like the idea of preserving SL history, this is a beginner build at best, not a desirable new user experience, nor an appealing gathering spot for returning residents. On the plus side, it appears to be pretty much starved of infohub visitor routing, so it's not really doing much active damage (although it is still showing as an infohub on the Map). I'm certainly not much concerned about the fate of my dinky 512 there, so if the whole sim just rots away, it really doesn't matter to me, personally. It does make me wonder, though: How many of the old infohubs are in similar disrepair? and should LDPW rejuvenate them? Repurpose them? Give up and auction them off? Maybe the least successful of the old infohubs could be assets for whatever fresh approach is being taken to New User Experience?

The hat would need to be rezzed on the ground if you really wanted to add feathers as new prims not part of the hat from the start. The alternative being suggested here, however, is for the hat come pre-populated with as many prims as it could ever need, and new "feathers" be introduced in the form of data that the script uses to do "feather-making" calls to llSetLinkPrimitiveParamsFast() on those already-linked but dormant prims.

Yeah, a script can't change the linkset of an attached object (nor an object that's sat upon). That's why many attachments include a bunch of alpha'd-out prims, with a script that swaps visibility of sets of prims. One can be a little more sophisticated than that by changing all the prim parameters to transmogrify one configuration of prims into the next, calling llSetLinkPrimitiveParamsFast() for every prim that changes between configurations.

I'm not a texture expert by any means, and I don't even use Photoshop, but I'm sure it has a way to threshold alpha as Gimp does, which would produce an image that looked the same as one that had a one-bit alpha mask (although, when you upload it, I think it will come with an alpha channel the full eight bits deep). I think, however, that the viewer would still need to be set to do its own alpha-masking in order to get it to sort properly. I vaguely recall discussions, I think in an old Nyx office hour, about getting the viewer to directly use user-supplied one-bit alpha masks, and I believe there was general agreement that this would be a good thing, but can't remember any specific plans about it.

I'm not sure you have this exactly where you want it in the script, but I guess it will work there, changed to something like: text = llList2String(llGetLinkPrimitiveParams(LINK_ROOT, [PRIM_DESC]), 0); Just now I can't check to see if this is even syntactically correct, but hoping it will point in the right direction.

I agree that the stuff is amazing. Re-terraform and the Linden grass (eventually) reconfigures itself to the new terrain. And that one-bit alpha means that there's never any alpha-sorting problems. But yeah, that one-bit alpha mask makes the textures look pretty crude. They are not, however, full bright, so I'm not sure what you're seeing there. [ETA: There are also particle grasses that are better suited to some applications than are sculpted (or, soon, Mesh) grasses. They're not any more like the Linden grasses, really, just a different approach.]

It's difficult to follow what the real objective is for this project, but I'll guess that the object_rez() event may be useful because it reveals the UUID of the object just rezzed by the script. The thing is... if a script is rezzing and linking and unlinking and wanting other objects to un-rez, there's often some much simpler and less laggy way to get the end effect it's trying to achieve.

Do not care. I have Adult land. I bought it specifically for the freedom to do whatever the heck I want on it, within the ToS. I don't happen to have a child avatar, but regardless: I want the freedom to decide to have one on my Adult land (with fully General-rated content) any time I d*mned please. Maybe there's some third party grid that has all its ratings neatly sorted to suit OCD control freaks, but SL ain't that grid and shows no sign of adopting any such policies. Thank god.

Be aware that no script can fully control the cam. It controls the "default" or "scripted cam" -- that is, the camera parameters in force when you press the Escape key a time or two. But the user can always grab onto something in the scene and zoom into it, pan around from it, etc., overriding this default cam. A script can know that this is happening, but there's nothing it can do to force the user back into default cam mode.

I think underlying much of the confusion is the mistaken notion that Adult-rated regions are going to be All Orgy All The Time. That wasn't so far from true back when Zindra was forcibly and exclusively colonized by exiled pornographers, and any business on Adult land was horribly penalized by Search, exclusion from the Destination Guide, a broken age verification process (the subject of this thread), and pretty much every other screw-up that LL could achieve through a combination of lethargy and subconscious loathing. Anyway, most of that is behind us now, more or less, and it's high time we got on with it. Part of that is recognizing that Adult-rated land will have some adult content too "extreme" for Moderate-rated land -- right next to parcels with General or Moderate-at-most content. It's always been that way, in fact, but now there's much less disincentive for "normal people" to have Adult land.

Also, they keep tinkering with the alpha masking heuristic in recent releases of Viewer 2. This has more or less the same objective as the "Fast Alpha" option in V1-based viewers (IIRC somewhere under Debug or Advanced menu). In V2, this works much better, and gets turned on by default for some graphics cards (because the deferred rendering version is on by default, and some super-high-end graphics cards get deferred rendering turned on automatically); the settings can be toggled under Advanced / Rendering. Anyway, the point of alpha masking is to make tractable the alpha sorting problem by forcing any pixel of texture to be either opaque or transparent -- that is, one-bit alpha. The trade-off is that there is no alpha blending at all: the front texture's non-alpha pixels fully obscure anything behind them. Whether this option is turned on or not, Linden plants always use one-bit alpha masks... which is why their edges look so choppy -- they're dithered instead of alpha-blended. But you don't get alpha-sorting problems with Linden plants.

I agree with Rolig here that the lag introduced by an infrequent sensor is just not worth worrying about. It would entail slightly more processing than an open listener in the HUD (and corresponding llWhisper()s* in the treasures), but even that is somewhat a function of how many HUDs there are, relative to the number of treasures. That is, if there are generally very many treasures but few treasure seekers, just having the treasures periodically whisper costs some processing, and the fact that they're scripted at all costs some memory. On the other hand, if there are very many treasure-hunters crowding into sims containing very few treasures, one would want to be more careful about HUD-side lag than about whatever the scarce treasure might do. Taking that to an extreme, one might have the HUDs broadcast their arrival only on rez and region change, and the script in the treasure do all the work using llGetObjectDetails to track in-sim HUDs for proximity. Well... even more extreme: Lose the HUDs altogether and have the treasures run sensor scans for hunters, where those hunters have been registered at some central server to which all the treasures are networked (where this "registration" is in place of distributing HUDs). With this approach, the treasures would have to interact directly with the hunters and replace any other HUD functionality, so that may not be practical. (*Incidentally, the range of llWhisper is 10m.)

I haven't tried this, so it may be all wrong, but shouldn't llRegionSayTo(llGetOwnerKey(), ...) be useful for messaging between attachments of the same agent?

Too much of anything is too much. Enough is enough!

Yeah. About "bronies". That's all I've got to contribute to this thread. The whole subject seems the sort of recursive irony that depletes neurotransmitters to no effect.

No opinion on the street names, but just thinking that Novatropolis might want to hype the fact that it's part of the all-General continent. It's a tiny continent, to be sure, but much larger than Novatropolis only. As much as it probably made sense to glue the TG Bay City sims to the west of the original MG Bay City, the downside was that doing so removed them from that all-G continent, so it's more difficult for it to retain "critical mass" of interest. Of course, it may be that there never was interest in all-G content, other than that enforced on teens... but having a "predictable SL experience" vis a vis content maturity was the Linden party line, back when they herded all us pornographers off to Zindra. If it turns out that there's not really much interest in an all-G continent, then Novatropolis will have difficulty restoring occupancy and supporting anything like the current land prices there. It's double-primmed and there's infrastructure, so it's not going to revert to standard Mainland < L$0.5/sq.m. or anything, but... it's no Nova Albion either.

Are you sure it's worth all the angst? I know there are some merchants that still use obsolete viewers to compare each other's traffic figures, and are busy gaming those numbers against each other, but... I mean, everyone needs a hobby. Are we sure there are enough real users still using old search that it makes any difference to sales?

I'm having the same problem getting secondlife:// to launch from Chrome. I'm guessing the answers here were for Windows because they seem pretty irrelevant to what I'm seeing in Linux. What happens is that Chrome tries to run xdg-open secondlife://regionName/128/128/0 which of course does nothing because the secondlife:// mime type isn't registered anywhere, even after running the (extremely brain-damaged) install shell script. I'm not using any ~/.local/share/applications/defaults.list, and /usr/share/applications/defaults.list has nothing relevant, but it's sure not obvious to me what should go in there. I'm hoping somebody has already learned the xdg-mime magic, since I've already spent much more time trying to figure this out than I'll ever save by not cutting-and-pasting the URI into chat history.