Jump to content

Bem Beyaz

  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Bem Beyaz

  • Rank
  1. 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.
  2. 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 c
  3. 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 e
  4. 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(
  5. 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.
  6. 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,.
  7. 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.
  8. Thanks, Wulfie — I just finished the post immediately above upon noting the problem.
  9. 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 .
  10. 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.
  11. 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 t
  12. 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
  13. 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
  14. 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
  15. 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?
  • Create New...