Frankie Rockett

Hi I'm asking for help with a modification I made to Rolig's excellent multi-page Menu system which is in the LSL Script Library here: https://community.secondlife.com/forums/topic/181045-a-simple-multipage-dialog-menu-system/#comment-1382741 I am using it in a drone to select nearby avatars. I want it to return both the selected Av Name (displayed on the buttons) and also the associated UUID. To that end I modified her code to save name/uuid pairs, and to step through the 'Buttons' List in 2's rather than in 1's. It all works fine - as long as there are 9 or fewer avatars in range. If there are more and it needs to prepare a second menu 'page', it crashes with the following message broadcast to all: "llDialog: button labels must be 24 or fewer characters long". Clearly, and understandably, something is going wrong with the paging it seems to me. This is all at the edge of my understanding, so I tried some simple minded approaches like doubling her 9's and 11's to 18 and 22 respectively, but that didn't help. Days of trying to debug this are sending me bananas. So please, can anyone see where I've gone wrong here?! list gNames; integer gMenuPosition; // Index number of the first button on the current page integer gLsn; // Dialog Listen Handle list avatarsInRegion; key id; string name; list uListReverse( list vLstSrc ){ integer vIntCnt = (vLstSrc != []); while (vIntCnt){ vLstSrc += llList2List( vLstSrc, (vIntCnt = ~-vIntCnt), vIntCnt ); } return llList2List( vLstSrc, (vLstSrc != []) >> 1, -1 ); } Menu() { integer Last; list Buttons; integer All = llGetListLength(gNames); if(gMenuPosition >= 9) //This is NOT the first menu page { Buttons += " <----"; if((All - gMenuPosition) > 11) // This is not the last page { Buttons += " ---->"; } else // This IS the last page { Last = TRUE; } } else if (All > gMenuPosition + 9) // This IS the first page { if((All - gMenuPosition) > 11) // There are more pages to follow { Buttons += " ---->"; } else // This IS the last page { Last = TRUE; } } else // This is the only menu page { Last = TRUE; } if (All > 0) { integer b; integer len = llGetListLength(Buttons); len = len/2; // This bizarre test does the important work ...... //for(b = gMenuPosition + len + Last - 1 ; (len < 12)&&(b < All); ++b) for(b = gMenuPosition + len + Last - 1 ; (len < 12)&&(b < All); b=b+2) { Buttons = Buttons + [llList2String(gNames,b)]; len = llGetListLength(Buttons); } } gLsn = llListen(-12345,"","",""); llSetTimerEvent(30.0); // integer i; // integer length = llGetListLength(Buttons); // do // llOwnerSay(llList2String(Buttons, i) ); // while(++i < length); llDialog(llGetOwner(),"Targets within range:\n", Buttons, -12345); } default { // ---------------------------- S Y S T E M F U N C T I O N S ---------------------------- listen(integer channel, string name, key id, string msg) // Listens to and services all menu buttons. { llListenRemove(gLsn); llSetTimerEvent(0.0); if (~llSubStringIndex(msg,"---->")) { gMenuPosition += 10; Menu(); } else if (~llSubStringIndex(msg,"<----")) { gMenuPosition -= 10; Menu(); } else { //Do whatever the selected button directs..... your choice integer n = llListFindList(gNames, [msg]); if(~n) { // shorthand for "if it is an item in the list". If it is, key k = llList2Key(gNames, n + 1);//find the next item, //and thus you have the avatar's uuid. list test = [msg]; gNames = uListReverse(gNames); integer NameIndex = llListFindList(gNames, test); NameIndex --; NameIndex = NameIndex / 2; //llOwnerSay("DEBUG MENU choice made at position " + NameIndex + " / " + msg + " / " + (string)k); llMessageLinked(LINK_THIS, NameIndex, msg, k); } } } timer() { llSetTimerEvent(0.0); llListenRemove(gLsn); } link_message(integer sender_num, integer num, string msg, key id) // Services request for targeting from main script. { if (msg == "target" && num ==0 ) // if num==0 ie if sending script was 'Drone 166' { llListenRemove(gLsn); gMenuPosition = 0; gNames = []; llSensor("", NULL_KEY, AGENT, 96.0, PI); } } sensor( integer detected ) // Assembles list of Avatars detected by sensor function. { while(detected--) { gNames = gNames + llDetectedName(detected) + llDetectedKey(detected); } Menu(); } } Thank you for your thoughts.

Thank you Quistess for bringing that to my attention. On balance though, I'd like a solution that works with mainstream viewers, especially Firestorm, rather than the more obscure alternatives.

Thank you Qie. That concise toggle tip is very valuable. I've been doing it the more plodding way, with if/then to alternate a toggle's value! It sounds like I'm flogging a dead horse here. Yes the result was very choppy. I assumed that was because the drone itself had a choppy follow movement, but whatever the cause, it wasn't pleasant. If I read you correctly then, there is no way I can smoothly displace my camera to that of the drone's point of view?

Hi Lucia. While I don't have the in-depth knowledge to counter your comment, I can tell you that this script does follow a drone (which in turn is following a nominated avatar). Please see Wulfie Reanimator's post at the foot of this page - it's the source of my variation, and again, it works as described: Also, as I said in my initial post, this will work in a nearby (unattached and un-worn) prim.

Hi I have been trying to move my camera to the position of a separate drone I created and to move with the drone. It's largely based on a script someone gave in this forum, slightly modified for my own case. It works after a fashion but there are a couple of serious problems with it and I wonder if anyone can see the wood for the trees here? First problem: I need it to work from a HUD and to toggle the remote view on and off on repeated clicking. In a HUD, this script doesn't work at all. In a nearby prim, rezzed on the ground nearby, it works as it should (meaning on, then off). However, even as a script in a rezzed prim, it stops working after one round of off and on. After that you need to reset it to get it going again. So - can this be made to work in a HUD and repeatedly so without having to reset/remove and re-add the HUD after each remote viewing? Second problem: no matter how I tweak the parameters relating to where the camera IS and where the camera is POINTING, it's always essentially looking AT the drone. I want the camera to adopt a position as if it was the drone's camera - on the front and looking forward. Why am I never getting that view here? Here's the code I have so far. Note, a separate script messages the drone and it replies with it's UUID - that's picked up by this script and so works as intended. Additional note; I added some lines relating to rotation in vein attempts to modify the default rotation into something I wanted. key uuid = ""; integer listen_handle; default { on_rez(integer param) { llResetScript();//By resetting the script on rez forces the listen to re-register. } state_entry() { llRequestPermissions(llGetOwner(), PERMISSION_CONTROL_CAMERA); listen_handle = llListen(166, "", "llGetOwner()", ""); llRegionSay(166, "UUIDRequest"); } run_time_permissions(integer perm) { llSetTimerEvent(0.022); } timer() { // Get the remote object's position and rotation. list data = llGetObjectDetails(uuid, [OBJECT_POS, OBJECT_ROT]); vector pos = llList2Vector(data, 0); rotation rot = llList2Rot(data, 1); rotation rot90Z = llEuler2Rot(<0, 90, -270>*DEG_TO_RAD); rot = rot * rot90Z; llSetCameraParams([ // Begin controlling the camera and prevent it from being moved. // (Alt-cam will still override this.) CAMERA_ACTIVE, TRUE, CAMERA_FOCUS_LOCKED, TRUE, CAMERA_POSITION_LOCKED, TRUE, CAMERA_FOCUS, pos, // The position the camera will LOOK at. CAMERA_POSITION, pos + (< -1.0, 0.1, -0.1> * rot) // The position the camera will BE at. ]); } touch_start(integer n) { llClearCameraParams(); llSetTimerEvent(0); } listen(integer channel, string name, key id, string msg) // Listens to and services all menu buttons. { if (channel == 166 && msg == "UUIDRequest-Back") { uuid = (key)id; llOwnerSay("Receiving UUID = " + (string)msg); } } } So - is it even possible to have camera controls in a HUD, and if so, how can I get them to behave as intended? Thank you in advance.

Thank you for that Rolig. I'm not sure what I was expecting, but I guess in order to use llRegionSayTo, now I will have to create some sort of minimal HUD to operate the drone, since I cannot issue llRegionSayTo directly. No peace for the wicked! Thank you.

Thank you all for your input, time and knowledge! A special thank you by the way to Rolig; it's her menu script that I found in the SL script library and have adapted for use here. Thank you so much Rolig!! I feel I didn't really understand the sensor function before, and now I do - better at least. I decided to abandon the use of llGetAgentList() as it feels like I'd make things easier for myself to sticking with llDetectedPos() and enjoying the relative convenience of using it's index. Moving past that issue for now, I have run into a fresh problem on this same project, but as it's not related to the original Subject title (above) I am thinking should I open a fresh forum question? Happy to do so, but otherwise it's simply this. How does one broadcast a channel command further than the 10 meters it seems to cover? Since the llDetectedPos() function could see the drone flying at least 96 meters away, it would be nice to be able to call it back without the indignity of... running after it!

Hi! I am trying to adapt a script I have that makes a little 'drone' follow me around a region, such that it will go follow a different, chosen avatar, until I recall it. The problem I have is with the script sensor. It currently uses llDetectedPos(0); to locate and keep track of me - the owner. I find other Avatars in the region via llGetAgentList(). Now, I'd say I am of intermediate skill level with LSL so forgive me if the answer is obvious to others; it seems that the sensor wants the index value in llDetectedPos() to keep track of a new target, and yet llGetAgentList() only returns Avatar name and UUID. How can I get from name and UUID to an index value that I can feed into the sensor via llDetectedPos(index_of_identified_avatar) and have the drone latch on to another avatar and track it's position thereafter?? Or is there another way of doing this that won't require a major rewrite? Thank you for your thoughts! Frankie.

Hello everyone! A friend and I were making a machinima at the weekend as our response to Coronavirus. It started out as promoting washing your hands, but we discovered along the way that the more salient message here is to have fun, to smile. When you smile, you boost your immune system, right? So in that spirit I would love to submit for your pleasure - "Smile (Wash your Hands)". URL: https://www.youtube.com/watch?v=vmzbdFKbea0 Unlike the virus, this is something I'd like you to share widely and wildly - friends, social media, Lindens - everyone! Stay well / stay happy / stay sane. Frankie X

Hi Two excellent approaches worth looking into. With Animats approach I could presumably have the script check it's ownership, then delete itself if it's not myself. I'll have to test that out and see what I think. Nova's idea thrills me - it sounds like magic! How do I access this 'central controller prim'? Do you mean the root prim? Assuming so, how on earth do I get it to rebuild the state of itself when it was a multi-prim object? Once I know that (which I'd love to at this point anyway), the base question still applies: how do I give the controller/or/root prim, complete with it's parameters and script for rebuilding, to the user? Frankie.

Hi Gang I want to know if I can programatically get an object to offer itself, without having a copy of itself inside, so 'llGiveInventory' is not an option. I have what might seem like a perverse requirement here so a few words of explanation before I get back to the question. I have what for shorthand I'll call a 'game' for solo players in which objects are rezzed around a central controlling prim (that I'll refer to as the CP). The CP listens for the UUID of the latest prim to be rezzed and immediately links to it. This leads to a large object building up by accretion as more objects are added. At the end of the game the user clicks a 'Clear' object that tells the CP that a Clear is requested. The CP sheds everything by a) declaring itself to be Temporary, b) unlinking all the child prims, and c) declaring itself to be not temporary. So 60 seconds later, the setup is clear and ready for the next game. Now, in testing, users have expressed the wish to have a copy of the object (prior to clearing it). The object contains a listen remember, so in theory I could send a 'Give' command to it for it offer a clone of itself to the player. Or could I? To the best of my rather incomplete knowledge, llGiveInventory is the only function that might do this, but since the object was dynamically created, there can be no copy of itself within itself that it could offer to give via llGiveInventory. So; is there a way to programatically have a script offer the object - rather than an item in it's inventory? I can't decide if there's a glaringly obvious way to do this, or it's actually impossible. Nothing in between those two extremes I bet. Thoughts please? Frankie

Epilogue. The solution worked flawlessly. Fenix's proof of concept script does the job really well. The only tweak I had to make was as a result of idiot-proof testing. I found that if I clicked like mad creating scores of prims per second then hit 'clear' while things were still rezzing and linking, then - after a looong delay for things to catch up, two or three child prims were left over - still attached, and not temporary. So I wrote a little delay loop (because llSleep makes everything go brain dead so nothing gets done) before and after the unlinking call and that seemed to make it bullet proof / vandal proof. Success! Thanks to everyone again - you know who you are - for your superb insights! Cheers.

Wow Lucia! Yes, danger of information overload, yet I understood 87.396% of it. More than enough to see what an important set of considerations I'd never have dreamed off were it not for your input. I can imagine myself scratching my head for days and wasting hour upon hour trying to figure out why no more object returns were happening. And I've barely touched on half your contribution here, but it's all noted (and in need of sixteen re-readings to be sure I got the rest). Thank you so much. Qie - again, thank you for your input. Yes, I am leaning towards Fenix's approach like the Tower of Piza is leaning towards agreeing with gravity. Not only to circumvent the issues Lucia points to but also the general messiness of having my Inv fill up with what is conceptually at least, other people's junk. I still need to do a ton of experiments around circumventing the PERMISSION_CHANGE_LINKS complication, but it feels like the avenue I should explore ahead of the llReturnObjectsByID approach. Nice to have a plan B though, so thanks again Rolig. Oh, and a plan C too if you're on the right lines saying that a targeted listen is no biggie, together with a built in limit to how many prims I'll permit to be rezzed in one go. I kind of think 200 would be the limit though for game-specific reasons. I'll keep this thread posted with findings as I go along. Cheers.

Thank you Everyone! To Profaitchikenz: Thank you so much! That is brilliant. I am indebted to you. After a few hccups I realised I had been 'randomising' the wrong parameter. I needed to leave 90 in the second parameter slot and randomise the first, the x parameter. Then it all worked perfectly. Thank you. A huge Thank you too to Wulfie for fearlessly slashing away the complexity of rotations for me! Education by subtraction has a lot to be said for it - so seriously, thank you Wulfie. Lastly, thank you to Mollymews for adding all the complexity back in with your background reading! Hahaha! I'm only teasing - thank you. Cheers to all!

Hi Wulfie I tried my (clearly faulty) implementation of your very clear instructions, with the resukt that the rezzor itself started to randomly rotate, rather than the thing rezzed. Here's the code. My best guess was to try to change the definition of rezRot by assigning rotation rezRot = llSetRot(llEuler2Rot(object_rot * DEG_TO_RAD)); but that's a syntax error! can you see where I'm going wrong? Oh - the lines of yours I took and modified for this script's variable names is enclosed in the section marked 'Edit's'. Profaitchikenz - thank you for your suggestion too, which I had to try because it seemed so deliciously simple. No joy. So I found that changing: rotation relativeRot = <0.707107, 0.707107, 0.707107, 0.707107>; to rotation relativeRot = <0.0 0.707107, 0.0, 0.707107>; yields functionally identical results in that it rezes the 'picture prim' in the correct initial orientation (face X 'forwards') so I naturally assumed that changing the 2nd parameter would change the 'spin' of the image as required. No dice. Keeping within the 0 - 1.0 range as you said, I tried for example <0.0, 0.1, 0.0, 0.707107>; which made it rotate on the wrong axis. Remembering your comment about making the 4th parameter the same. I went with <0.0, 0.1, 0.0 , 0.1>; - all good. Except when I tried other values like <0.0, 0.4, 0.0 , 0.4>; and <0.0, 0.9, 0.0 , 0.9>; - no rotation occured at all. The various changes of value had no effect on rotation of the rezzed item. 'Clearly shome mishtake', as folk start saying nearer Christmas. Do you have a hair of the dog for me?! Thank you all.

Hi Try as I might I have to admit that I will never understand the maths or the geometry behind anything other than 'degrees' of rotation along three axis in SL. I say this upfront in case anyone tries to explain underlaying concepts to me! Keep it simple (because I'm) stupid (when it comes to this stuff). I have a script rezzing a flattened square prim with an image on it's front-most face that rez's against a wall I have provided. I have it working so it functions no matter which compass point the wall faces. However what I'd like to do is have it's orientation on one axis randomly oriented when it rezs. Imageine a poster that might be upside down, sideways, or any other of the 360 available angles. So the bones of what I'm working with is here: It's the object's own Z axis I need to spin. Everything I try seems to cause complex interactions and rotate the prim on more than one axis. Take the first line for example. If I change any of the 4 parameters, the object will rez skewed on at least two axis. I have spent hour (and hours...) on this and would be so grateful to know at what point I can inject values between 1 & 360 to have the object still flat against the wall but rotated some - like clock hands for example. Thank you!

Hi all So much for me to digest! I used to code daily but 'use it or loose it' applies here, and as I haven't got down and dirty for literally years, absorbing some of your fine ideas is a little overwhelming. Fenix and Rolig have (with a great supporting cast), between them I think, given me a workable alternative to a 'choir of listens'! Please let me play around with your combined suggestions over the next week or so to see where they lead. Thank you again so much for donating your brilliances! Much appreciated!! Frankie.

Hi Rolig + Hi Mollymews! Thank you for those remarks. I think I want to try Rolig's idea, especially as Mollymews points out, it involves least modification to what I have now. Although I do need to speak to the land owner. Can I take it then Rolig that he or she could create a parcel for me, and not fear that my PERMISSION_RETURN_OBJECTS could affect anything he owns outside 'my' parcel? And just for completeness, how (in what menu/dialogue) would he grant me such a permission? Cheers.

Hi Rolig! Thank you for your idea. The game won't always be on my land, which as you understand would scuttle that approach. If it was on my land, wouldn't the memory requirements be beyond an lsl script? Saving a little 'array' of - let's say worst case - 250 UUID's? Cheers

Hi Fenix, and Hi Profaitchikenz too. (I greeted you a second later Profaitchikenz, just to keep it straight!) Thank you both for your suggestions. Fenix, one question. You say the rezing prim (my prim A) would " automatically know" the UUID of the prims it's rezzing. How? Or more exactly, how would I access that value please? I love your suggestion overall, except for the ugly caveat concerning PERMISSION_CHANGE_LINKS. So I have an idea/question about how to get around that. Supposing my 'prim B' were a permanent, invisible part of the game, and once the game is ready for others, I give it the permission once that it wants. Then later, with lots of child prims attached, and hearing my 'Clear' command, could it contain a script that effectively says 'delete all child prims'? - excepting itself. Then, on future runs of the game, could it be told to link to a new series of prims as they are rezzed, by their UUID's, without needing PERMISSION_CHANGE_LINKS again? Or is that permission required on a prim by prim basis? Thank you for your idea Profaitchikenz but I see problems with it, like waiting an age for some potential maximum number of prims to rez and link, even if the subsequent player only used a fraction of what was invisibly prepared. Cheers!

Hi! I have an application working at the moment that I'd like to rewrite in a much more friendly way and I wonder if you guys and girls can help? I have a game that rezs many prims. It's up to the player but there might be a hundred or more. The region's the limit, theoretically. When the game is over, all the prims (which are all very close by and very close together) need deleting. Currently they all have a 'listen' in them, listening on a particular channel for the 'Clear' command, whereupon they 'die'. I would love to not be creating scores or even hundreds of listens! So I am wondering how else to do it? I was musing that perhaps there is a way to link two or more prims that are and remain separate from the prim that created them? Is that do-able? So to be clear, prim A contains the script and the means of spawning prim B, C, D and so on. Prim A creates B initially, but B is unique as the first one spawned, it's set to contain the only 'listen' needed. As each new prim is spawned, it links to prim B (or any of the others except A). When the game is over, a 'clear' command causes prim B to delete, taking everything attached to it with it. Ok, that's my uninformed guess! Might that work? What are the key functions that I might need to get it going? And of course, are there any other exotic techniques I might employ to achieve the same functionality? Thank you for your thoughts!

Yes, that's what I thought Qie was describing. Hence my illustration to counter the theory - how the texture seems not to have any transparent portions in this case.

Not quite clear if that's a question - as it starts out, or who the subject is - in what seems like a statement in the middle section, before reaching what looks to me like an exclamation. But - 'yeah right!'

Oh that would be good! I should set aside my conviction that all I'd see is a 'transparent' texture and try it. There are two barriers to this of course. For one it's broken and I'm not sure I learnt much from breaking it; buying another - ditto. Secondly, the 'flashing' on and off of tail positions is too fast for me to select it anew and inspect the texture - it would have cycled well past that tail's (in)visibility by then I would imagine.

The slightly depressing universal answer is that no matter which face I select they all have (is that 'both' have - I haven't probed every milimeter looking for another face) the exact same texture - the one as seen here.