ainst Composer Posted April 4, 2019 Share Posted April 4, 2019 (edited) Hello! need a script for linkset of several objects, allowing one object to emit light and turn off for the rest in a circular chain. I managed to add a light to all objects but I can’t turn of for the rest. What is the way to do this? Edited April 4, 2019 by ainst Composer Link to comment Share on other sites More sharing options...
Rolig Loon Posted April 4, 2019 Share Posted April 4, 2019 Do it in two steps: 1. Turn OFF all lights. 2. Turn ON the one light that you want lit at the moment. Not only is that logical, it's also most efficient. It guarantees that the only light that will be on is the one that you want, without needing to address each of the others individually. 1 Link to comment Share on other sites More sharing options...
ainst Composer Posted April 4, 2019 Author Share Posted April 4, 2019 2 minutes ago, Rolig Loon said: Do it in two steps: 1. Turn OFF all lights. 2. Turn ON the one light that you want lit at the moment. Not only is that logical, it's also most efficient. It guarantees that the only light that will be on is the one that you want, without needing to address each of the others individually. You're genious, Rolig! Thank's a lot! Link to comment Share on other sites More sharing options...
steph Arnott Posted April 4, 2019 Share Posted April 4, 2019 //this is a crude example of storing the link numbers for data usage integer gFace = ALL_SIDES; list primData = []; Data(string name) { integer l = llGetNumberOfPrims(); integer i = 1; for(; i<=l;i++) { name = llGetLinkName(i); if( name == "two" ) { if (llListFindList(primData,[name]) == -1) primData = [ name, i ] + primData; } } } default { state_entry() { // // } on_rez(integer start_param) { primData = []; Data("two"); primData = llListSort(primData, 2, TRUE); llOwnerSay( llList2CSV(primData) ); } changed(integer ch) { if(ch&CHANGED_OWNER) llResetScript(); else if(ch&CHANGED_LINK) { primData = []; Data("two"); primData = llListSort(primData, 2, TRUE); } } } Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted April 5, 2019 Share Posted April 5, 2019 @steph Arnott Your function doesn't work. I'm posting from my phone so I can't format properly, but here goes: 17 hours ago, steph Arnott said: Data(string name) name = llGetLinkName(i); If( name == "two" ) Your function overwrites the input parameter, and doesn't use the input parameter in the way you intended it to be used. If you try to find a link named "one" but there is another link with a different name, you will change "one" to another name. Even if you fixed that, the if-check becomes 'if( "one" == "two")' which obviously still doesn't pass. I also really enjoy the irony of someone who has sn unhealthy obsession with efficient memory usage to be adding things to a list like this: 17 hours ago, steph Arnott said: primData = [ name, i ] + primData; While this is a completely valid way to preprend things to a list, you later sort this list after the function has finished. You are objectively spending memory with no purpose or benefit. 1 Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted April 5, 2019 Share Posted April 5, 2019 /me gets out the popcorn 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted April 5, 2019 Share Posted April 5, 2019 23 minutes ago, Wulfie Reanimator said: @steph Arnott It was written that way on purpose. The word 'crude' was explicit and intended to get the person to study it, understand it and write it better rather than keep getting others to write their entire projects. So far the OP has done nothing except ask/demand As for for not working, it outputs the name of prim and its number if you simply addd a touch call. And to be clear because you appear to want to preen your feathers i would not use a clearly obvious kludge. Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted April 5, 2019 Share Posted April 5, 2019 I can keep going. 18 hours ago, steph Arnott said: if (llListFindList(primData,[name]) == -1) This one line has two problems, one of them I already covered, but I'll clarify. Most importantly, nothing is added to primData unless this check passes. The issue is that primData starts empty. This if-check will always be false. And again, it is more memory efficient to use typecast than constructing a new list. What I mean: 1 hour ago, Wulfie Reanimator said: if (llListFindList(primData,(list)name) == -1) Link to comment Share on other sites More sharing options...
steph Arnott Posted April 5, 2019 Share Posted April 5, 2019 Just now, Wulfie Reanimator said: I can keep going. This one line has two problems, one of them I already covered, but I'll clarify. Most importantly, nothing is added to primData unless this check passes. The issue is that primData starts empty. This if-check will always be false. And again, it is more memory efficient to use typecast than constructing a new list. What I mean: I already know that. It was written that way deliberatly. Link to comment Share on other sites More sharing options...
Qie Niangao Posted April 5, 2019 Share Posted April 5, 2019 Well, whatever you two both seem to know is news to me. Is there really some penalty (runtime allocation, or even just bytecode size) to prepending to a list, as opposed to appending? And is there really a difference between typecasting a list and explicitly creating the list in the code? I tried these things with some simplistic llGetFreeMemory() testing and couldn't find any consistent pattern one way or another. I could certainly refine the measurements with script profiling, but maybe I'm just not quite understanding what everybody else seems to know here. 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted April 5, 2019 Share Posted April 5, 2019 12 minutes ago, Qie Niangao said: Well, whatever you two both seem to know is news to me. Is there really some penalty (runtime allocation, or even just bytecode size) to prepending to a list, as opposed to appending? And is there really a difference between typecasting a list and explicitly creating the list in the code? I tried these things with some simplistic llGetFreeMemory() testing and couldn't find any consistent pattern one way or another. I could certainly refine the measurements with script profiling, but maybe I'm just not quite understanding what everybody else seems to know here. The point was that it was meant to be bad. A baseline understanding would have changed it to a simple list load and index find. integer i; for(i=1;i<=llGetNumberOfPrims();++i) { primNames += [llGetLinkName(i)]; } integer LnkIndex = llListFindList(primnames, [the_prim name i want]) + 1; Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted April 5, 2019 Share Posted April 5, 2019 50 minutes ago, Qie Niangao said: Well, whatever you two both seem to know is news to me. Is there really some penalty (runtime allocation, or even just bytecode size) to prepending to a list, as opposed to appending? And is there really a difference between typecasting a list and explicitly creating the list in the code? I tried these things with some simplistic llGetFreeMemory() testing and couldn't find any consistent pattern one way or another. I could certainly refine the measurements with script profiling, but maybe I'm just not quite understanding what everybody else seems to know here. From http://wiki.secondlife.com/wiki/Typecast "For casting a variable myVar to a single-item list, the syntax (list)myVar is about 30% more efficient under LSL Mono than the syntax [myVar]. The same (list)myVar syntax is also slightly more efficient under LSL-LSO." 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted April 5, 2019 Share Posted April 5, 2019 (edited) 1 hour ago, Wulfie Reanimator said: From http://wiki.secondlife.com/wiki/Typecast "For casting a variable myVar to a single-item list, the syntax (list)myVar is about 30% more efficient under LSL Mono than the syntax [myVar]. The same (list)myVar syntax is also slightly more efficient under LSL-LSO." 30% more efficient to what? Even Linden can not explicitly determine what code is and is not more efficient unles it is grossly bad because each server is different. This is an example of fixed laboratory condition data as opposed to actual reality. It is nonsense. Edited April 5, 2019 by steph Arnott Link to comment Share on other sites More sharing options...
Qie Niangao Posted April 5, 2019 Share Posted April 5, 2019 Well, I think I understand what's being compared, but I sure can't find an efficiency difference -- neither in execution time nor in allocated memory use. It's true that my tests produce a range of results for each test case, so it's not the purest laboratory conditions, but I come from a social science background so I'm not scared of an error term. Anyway, call me skeptical of a 30% efficiency advantage here -- frankly I doubt there's any difference at all. It's the most recent update to that Typecast wiki page, made in November 2018. I wonder if there was some special condition that produced that result. Link to comment Share on other sites More sharing options...
steph Arnott Posted April 5, 2019 Share Posted April 5, 2019 (edited) 29 minutes ago, Qie Niangao said: Well, I think I understand what's being compared, but I sure can't find an efficiency difference -- neither in execution time nor in allocated memory use. It's true that my tests produce a range of results for each test case, so it's not the purest laboratory conditions, but I come from a social science background so I'm not scared of an error term. Anyway, call me skeptical of a 30% efficiency advantage here -- frankly I doubt there's any difference at all. It's the most recent update to that Typecast wiki page, made in November 2018. I wonder if there was some special condition that produced that result. If it works that is all that i care about. Personally Lua makes LSL look pathetic. Edited April 5, 2019 by steph Arnott Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now