Jump to content

KT Kingsley

Resident
  • Posts

    1,071
  • Joined

  • Last visited

Everything posted by KT Kingsley

  1. When this has happened to me it's usually been because there's been an invisible something between me and the object I'm trying to click. You can try right-clicking on the object and then selecting "Touch" from the context menu. If "Touch" is greyed out then it's not just you. Also, you could highlight transparent objects with Ctrl+Alt+T to see if there is actually something invisible in the way.
  2. Well, seeing as how it can be done this might make a nice little exercise in scripting for me. Watch out for KTKoins!
  3. For a vector you will need to round each component individually: vector position = llGetPos (); vector rounded_vector = <llRound (position.x), llRound (position.y), llRound (position.z)>; Or maybe you want something like this: string text = llGetRegionName () + " " + (string) llRound (position.x) + ", " + (string) llRound (position.y) + ", " + (string) llRound (position.z) + "."; But yeah, using llRound on position vector components should be done with care or you could end up rounding 255.9 to 256.
  4. I still don't get it, it seems. default { touch_end (integer count) { llRequestExperiencePermissions (llDetectedKey (0), ""); } experience_permissions (key id) { llAttachToAvatarTemp (ATTACH_RHAND); } attach (key id) { if (id) llOwnerSay ("@setrot:3.14=force"); } } I dropped this script into a prim, compiled it using my own moderate rated experience, fired up an alt, set the alt's RLVaExperienceMaturityThreshold to 3, adult, and had her click the box. The box attached and the RLV command was executed. I then set the debug setting to 0, never, and tried again. Again, the box attached and the RLV command was executed. I guess I'm missing something here. ETA, ok, so I then added my experience to my alt's RLVaBlockedExperiences debug setting, again with no discernible effect. I think I'd better wait for someone who knows what they're doing to explain this to me.
  5. I'd say it's more a case of, if it can't be done without RLV, it has to be done with RLV, and if it can be done without RLV, then it should be done without RLV. If it is to be done at all. I don't think it really matters whether the objects involved represent whips and chains or anti-aircraft guns.
  6. An interesting problem, particularly with all experiences going grid-wide soon (or so I understand). I too don't see this as a particularly good solution. Presumably the viewer gets some information about an experience when it tries to do something like auto-attach an object for this to work? Which suggests it might be possible to block RLV activity on a per-experience basis. Or maybe that should be allow RLV activity on a per-experience basis. And then I guess you'd have to block any RLV activity from an RLV-blocked-experience-attached object, even when the script actually issuing the RLV commands isn't itself experience compiled. And if this information isn't already available to the viewer, perhaps someone could try persuading LL to make it so.
  7. Also, I think you might be able to do something with the particle size (scale), stretching them out a bit so they blend together a bit more. And I think the follow velocity thing can be used to keep them better aligned when you try this. I haven't ever had to do any of this myself, so I could be hopelessly off-course with these suggestions.
  8. Particles are very much a viewer-side effect, so just what you get depends on what your viewer, running on your system and using your graphics card can get away with. You can try all the usual lag-reducing tricks (draw distance, avatar complexity settings, etc.) to give your graphics system more time to draw the particles. You can up the maximum particles setting in your graphics settings and you can block the owners of any competing particle generators nearby. You could also try specifying a burst rate, maybe something like 0.25 seconds (0.0 seconds asks the viewer to pump out the particles as fast as it can), and reducing the burst count to try to get at least a more even, albeit more sparse, wake effect.
  9. What I don't get is what interactions I can do with an experience-compiled script and RLVa that I can't do with a not-experience-compiled script and RLVa that needs there to be a threshold in the first place.
  10. Browsing the release notes for the latest RLVa in the latest release of Firestorm, I came across something about RLV and SL experiences that led me to the debug setting "RLVaExperienceMaturityThreshold: Specifies the minimum maturity an experience has to be before it can interact with RLVa". Can anyone explain what this is all about? What can I do with a sufficiently mature experience and RLVa that I can't without one? (Maybe send RLV commands directly using llRegionSayTo?)
  11. To identify the group you can use either its UUID or its name (and watch out, because group names can be a bit tricksy). <role> is the name of the role (as in "Owners", "Officers", etc.), not of the title (the tag that appears over your head). In the group profile, see Members & Roles/Roles to get that info. This works fine for me using RLVa in the latest release of Firestorm.
  12. The viewer URI namespace stuff can also very useful: http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space. It too doesn't require the presence of the avatar in the region. llInstantMessage(llGetOwner(), "The owner is secondlife:///app/agent/" + (string) CarOwner + "/completename."); I generally like to use the "/inspect" variety as it makes the name a clickable link that opens a useful little info dialog with access to some of the more common avatar interactions. llInstantMessage(llGetOwner(), "The owner is secondlife:///app/agent/" + (string) CarOwner + "/inspect.");
  13. You could also go the group route: create a private group and have the door script check that the user is wearing the correct group tag when they try to open it. Although if you're going to go that way it'd be whole lot more effective to carve off the space behind the door as a separate parcel and make it group access only.
  14. Might there be some transparency sneaking in somewhere? Under artificial lighting this can make white textures look grey.
  15. I did take my alt to Portal Park and went through the Realms portal. Auto-teleport, auto attach HUD, etc. No sign of activity in Avatar/Experiences... Relogged this morning, and there's a "New Linden Realms" experience now listed in my alt's Avatar/Experiences... Just what the difference is between the Linden Realms experience my main belongs to and the New Linden Realms experience my alt has been joined to is, I have no idea, and I'm not particularly inclined to do the research required to find out. Point being, except for the couple of days when the new, improved, llTeleportAgent went live and before its potential as a griefing vector (I think that's the current terminology) was vividly demonstrated to the Lab and resulted in its abrupt withdrawal, there's never (at least, since around 2005/2006 when I first started using SL) been a publicly available "seamless", non-experience, TP facility in SL. It's entirely possible, however, that the Lab has a selection of script functions available only to its employees and trusted agents that could do this, but are not available to us users.
  16. That's odd. For me in both Firestorm (Avatar/Experiences...) and the LL viewer (Me/Experiences...) both Linden Realms and Horizons are listed indelibly - as in I'm not allowed to "forget" them. (I tried both viewers because I wondered if Firestorm might be exposing things the LL viewer kept hidden.) I did just fire up an alt who has neither listed in either viewer. I'm pretty sure I've had a quick look at both those places at some time or another, and I'm definite that the alt never has. So... I took the alt to Horizons A1/Horizons Homebase and lo... the Horizons HUD automatically attached itself, and the Horizons experience appeared in the Avatar/Experiences... floater, all without so much as a by-your-leave (as in nobody and nothing asked for any permission to do so). And yes, the experience does not appear in the About Land floater there, either. So I guess the Lab is invoking its supernatural powers when it comes to these experiences. And possibly they were able to do things with llTeleportAgent (or a private more powerful version of their own) that weren't available to mere mortals.
  17. In my case Linden Realms and Horizons are LL experiences that seem to be permanent fixtures to which I was automatically joined and which I cannot leave: the "Forget" buttons are greyed out.
  18. On second thoughts... does anyone know where I can get an LSL blockchain script?
  19. From the font of all knowledge: As with similar "laws" (e.g., Murphy's law), it is intended to be humorous rather than the literal truth.
  20. Beware of linking that twisted prim to a linkset including any mesh objects! Linked to a 1LI mesh object the combined LI goes up to 26.
  21. Presumably saying "tiff forbid stray" on channel 1 is supposed to cause something your partner owns, and is within 20m of, to issue the relevant RLV commands to prevent teleporting. So the first thing I'd look at is whether the object that's supposed to react to the "tiff forbid stray" message is working properly and in range of your partner. llSay has a range of 20m. There are several ways to initiate a teleport, and RLV has separate commands to control them.
  22. I had this problem logging in a while ago, but it cleared up for me after a few minutes. I noticed that on the Second Life status page, https://secondlife-status.statuspage.io/, Logins had (and, at the time of writing, still has) a question mark in a circle next to it. Might this mean that there have been some reports of issues, but that there is no widespread failure?
  23. I think it probably means that whoever was tasked with terraforming those regions had access to a bitmap to terrain file converter.
×
×
  • Create New...