Bem Beyaz

Well, it seems that I was indeed jumping the gun … I wasted a good deal of time on the assumption that I had wrongly formatted the @notify command. But it turns out the attachment was only firing on an ill-judged loop and not as it should have been doing first time around. Hence, shenanigans. The recursion (if it kicks off at all) is stopped after a few rounds with the judicious placement of a return but that'll teach me — as anyone who ever wallpapered the screen with "OwnerSay" statements will agree. Many happy returns for 2021.

So these are the two commands … gsCommand = "cuffing"; // Request notification first … llRegionSayTo(gkCaptive, giRLV, gsCommand + "," + (string)gkCaptive + ",@notify:" + (string)giCaptive + ";attached legally right hand=add"); // Then attempt to attach the folder … llRegionSayTo(gkCaptive, giRLV, gsCommand + "," + (string)gkCaptive + ",@attach:" + gsFolder + "=force"); And this is the debug output … Which is all well and good but I only want to pull those shenanigans in the event that "/attached legally Right Hand" is not confirmed first with the opening "if" condition — in case gsFolder follows Murphy's Law and happens to be empty, for example (a list of potential folders to attach was built on the first touch event because, in the true tradition of Second Life, Brad is one of those accounts whose #RLV folder is every bit as messed up with dead-ends and dumb stuff as his default Inventory). As it happens, this works even as said shenanigans kick-off prematurely with "/notify:162738272;attached legally right hand=add" in the following "else if" condition before "/attached legally Right Hand" comes hot on its heels a split second later. The routine finishes up then, resetting the timer, closing the the listen, clearing the notification and setting a control integer, giOffer, to FALSE. And I have Brad bang to rights, of course. I know it is verging on overkill to test all those folders when I could just give the dumb cluck another bunch of copiable items and get on with messing him about but, hey, the code block will be dormant 99.9% of the time (I would hope). Also, such small awkwardnesses speak to the the calibre of the person we are playing with — no such thing as TMI with RLV RP IMHO (LOL). That split second bothers me, though — and it really is only a split second. The RLV protocols are very resilient and tests on frantically busy sims with up to 60 meshed-up, variously textured and smugly smirking avatars (HUDs 'n' all), several of whom will have active relays (one or two with several), cascades of nearby chat, IMs from greeting bots, a dance ball and other typical headaches, the delay does not add up to more than the blink of an eye. Am I really condemned to jump the gun every time? NB: I have tried reversing the order of the attach and notify commands. I have also tried setting a different gsCommand on each despite the RLV spec which explicitly says that one-shot commands like "force" are not repeated anyway (confirmed with zilch in the listen for it). I also tried putting a sleep between the commands, hoping the @attach confirmation would skip past @notify in the ether and I tried that same hopeless strategy between the listen conditions too. I also placed my lucky bakelite "Beatles" pen-holder on a different corner of the desk every time but nothing doing.

Well, whaddya, whaddya!? It is just me! Being so used to the formality of "OwnerSay" commands in RLV, I completely ignored the fundamental purpose of the function which is to send chat to the owner. So of course old Brad will never hear those commands while I'm stood there, talking to myself. Instead I should use the llRegionSayTo() function and issue the inventory query to his relay along with an additional command on the relay channel. Unfortunately the RLV spec is befuddlingly befuddling as to how this is done — fortunately the estimable Innula Zenovka provides us with a working example in this post.

I won't bore you with the entire routine but in a case of llGiveInventoryList my attachment issues an "@notify" command according to the RLV spec like so … llOwnerSay("@notify:" + (string)giCaptive + ";inv_offer=add"); llGiveInventoryList(gkCaptive, "#RLV/" + gsFolder, glGift); … and dutifully listens to hear how the gift has been received. My test alt — let's call him "Brad" — takes delivery and by way of a "debug" my attachment's listen script gets far enough along to pump out the llOwnerSay at the top of this block in the "giCaptive" channel of the listen event … llOwnerSay("Listening for " + llKey2Name(gkCaptive) + "'s reaction …"); list reception = llParseString2List(message, [" "], []); string selection = llList2String(reception, 0); if ("/accepted_in_rlv" == selection) { llOwnerSay("Got it in #RLV"); } // the other two tests … … I also see the "/notify:123456789;inv_offer" notification appear on my console where 123456789 is actually the giCaptive channel listening for signs of life on Brad (I have tested to make sure of the actual channel number). Both the notification and the listen are eventually removed with a timeout which has been tested from 5 seconds to a full two minutes (I know, I know, even Second Life's too short). There is no mention of any of this on Brad's console although the item is delivered immediately to the "#RLV" folder if the "Accept" button is clicked — and neither is there any mention if Brad has forbidden "Give to #RLV" or if he has ungratefully clicked "Discard" in either of the following tests. However, when the routine has timed out he gets an IM to say that he has taken too long about it. So is it just me or shouldn't Brad be talking back by now? NB: The client in both cases is the latest Firestorm release (6.4.12.62831) with RLVa enabled of course and Brad is sporting the DEM Relay HUD (200f).

Thanks for the heads-up on that, Wulfie and Phate. It looks like Granny should have stuck to knitting. Or maybe not, come to think of it — this kind of explains the orangutan arms and teddy bear bodies on all those Christmas jumpers she gave me over the years. Boy-oh-boy, am I glad I asked about this problem — even if it looks like I need to write the whole batch of scripts from scratch.

Aren't there scripting gnomes living in the ditches between software and simulator that don't like us doing things like this? My granny called it "deprecation" and she said they'll sneak up and steal your hair if they catch you doing it,.

That is a good idea, Molly. Although the second part of the message converts to a key, it does not convert to the sender's key in every case — there are a number of security conditions involving a third party key but I could re-jig the routine to test only for those. I guess a combination of this and Rachel's suggestion of the "Left" and "Right" functions would be a good strategy.

Thanks, Wulfie — I just finished the post immediately above upon noting the problem.

I see now why that solution suggested by Rachel was such a revelation to me — in fact it isn't detailed under "LSL Portal > Functions" at all but "LSL Portal > LSL Types > LSL String" and further down the page under User-created utility functions. The Wiki can be a bit of a maze for anyone who does not regularly visit it. I'm posting this for the general benefit of those who may be a little hard-of-thinking like myself .

That's what I suspected, Molly. Thanks for the confirmation. Thanks, Rachel — those functions are exactly what I need. I was not aware of them but I have used something similar in PHP. Like many, I suppose, I tend to drop in and out of SL depending on my interest levels but I really should get back into the habit of looking at the Functions page on the Wiki.

I have a very old routine of linked messages passing between scripts where a listen or sensor event will pick up a message and concatenate the relevant key of an object or avatar before passing it to other scripts in the same prim. The message is processed in the other scripts using a series of conditions testing variations of something like this … llDeleteSubString(message, 0, 5); … where the first part in this case is expected to be a six-letter string and the second part will be a key in any case. The system works fine — so long as I'm paying attention and change the length of the expected message where necessary — but there are quite a few conditions in each of several scripts and I was wondering if, aside from the question of human error, it might be more efficient to pass the linked messages as a temporary list from the first script … list whatever = [message]; whatever += "," + uuid; llMessageLinked(-4, 1, (string)whatever, ""); whatever = []; … break it down in other scripts with something like … list whatever = llParseString2List(message,[,],[]); object = llList2String(whatever, 0); uuid = llList2String(whatever, 1); … and work away with a simpler set of conditions. Doubtless experienced developers will find the answer to my question trivial but I'll ask it any way because I'm thick as two short planks when it comes to the overheads on script routines. The benchmark for me is purely an instinct that if I see the same line or even a similar syntax too often, the routine might be written more succinctly. Any other suggestions would be welcome — would a strided list be better, for instance — I'd like to be clear about what I'm doing before I change so many lines. NB: For what it's worth, the code is old and has never been in production — I have a hang-up about distributing scripts in-world unless I'm confident they have the washboard stomach and trim overheads of Greek statuary.

It's a bit tricky for me to be sure since I overwrote that messy draft of the script but as far as I recall the listen was not updating immediately when the new owner wore the item but only when he wore it for the second time -- and that included the test you're suggesting with llGetOwnerKey(id). In fact I'm pretty sure that it wasn't updating at all until I started using that filter. When I looked into the problem, I found this on the llGetOwner page of the Wiki: The one problem many coders come up against is that previously-activated events referring to the owner don't automatically change when the owner changes. The most often-seen result is a listen registered to owner will continue to listen to the PREVIOUS owner rather than the CURRENT owner. It is often confused as a bug in llGetOwner or llListen it is not in fact a bug but part of the design. There are several ways of working around this problem. The easy solution is to reset the script when owner changes or it is rezzed. The easy solution is not always the right solution. The same article suggests the init() function as a workaround instead of llResetScript and indeed that did the trick. But it's redundant now that I am using a bespoke channel for each new owner.

Indeed this is an RLV attachment and I agree that it's best to keep the script as simple as possible. I was running the init() function while the device was still hard-coded with an obscure negative channel and I found that llResetScript() wasn't immediately registering the listen to the new owner in the changed event. Things got very messy when two avatars in the same sim wore the device. Since I'm still very much a learner, I kept the function even after discovering that trick of generating a more or less exclusive channel for the wearer until I could be sure what I'm doing. Now that I'm wiser, I'll follow your suggestion and set the listen in the attach event. A second script will use llListenControl to turn particles on and off so I'll keep the init() function in that.

Thank you both. It's heartening to know that I'm probably on the right track. The device is an RLV attachment (yes, it's those cuffs, Rolig) and I have concatenated the permissions request with PERMISSION_CONTROL_CAMERA so the captive's camera really ought to comply or I will have to know the reason why. On Qie's comment about overriding the camera controls, perhaps I'm not testing the script properly -- with two viewers on separate monitors but still using the same mouse? I'll crank up my geriatric Windows machine and log my testing alt on that (providing the latest SL viewers still work on turf-powered computers). Failing that I'll have to find a friend to take control of me. Also, a little bit of further research inspired by that comment suggests that I should use the devious RLV snippet "@camunlock=n" to prevent the captive overriding his predicament while the "follow" script is active. I know this seems harsh but I see it as a usability issue: it's no fun to be admiring a tree or a lovely mesh building only to find that one's av has been taken somewhere else in the meantime.

I'd like to force the same result as CTRL + ALT + LEFT-CLICK on another avatar. I've tried the basic function on the Wiki, which could work given that we are likely to be in close proximity, but I'd be happier if I could force the other avatar's viewer to look at me specifically (I'm sure I'm much better looking for a start). Unfortunately my forum byline would most certainly be the opposite of Rolig Loon's if I had one so I can't be sure that what I'm after may even be possible. I looked at this talk page on the very same issue which provides little hope. Am chasing my own backside here?