Looping through variables.
|
|
Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
|
08-08-2007 18:40
list TermsList = ["apple", "banana", "orange"]; list Variables = [AccessNo, AdminList, AdminMode];
for (i = 0; i <= llGetListLength( Variables); i++) {
[assign i term from TermsList to i variable from Variables]
}
giving a result such that it then knows what AccessNo equals. So that if I go llSay(0, AccessNo), I will get it saying "apple".
I charged into doing this, but then screeched to a halt when mulling over my llList2Whatever functions.
It's probably dead easy but I just got stumped here.
p.s. The lists in question are way longer, which is why I'm bothering at all -- to avoid assigning them line by line.
|
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-08-2007 19:25
use llListFindList it will return the index integer which you can then use to access the same index on the other list
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
08-08-2007 19:40
It would be a lot easier if it weren't impossible.  Well, that is, a list can't contain variables, only values. So the line list Variables = [AccessNo, AdminList, AdminMode]; would try to evaluate AccessNo, etc., and put the values into a list, rather than storing some kind of handle or pointer to the variables themselves. But probably what's really desired is still possible. For example, one might use a symbolic constant for the index values of the list, something like: integer ACCESS_NO = 0; integer ADMIN_LIST = 1; integer ADMIN_MODE = 2; and then retrieve the list elements by index, e.g.: llOwnerSay(llList2String(termsList, ACCESS_NO)); Or, for other applications, there are association lists, either paired or strided, the latter of which might look like: list termList = ["AccessNo", "apple", "AdminList", "banana", "adminMode", "orange"]; llOwnerSay(llList2String(termsList, llListFindList(termsList, ["AccessNo"]) + 1)); or something like that. The paired-list a-list approach is what Osgeld suggested (whilst Qie was still a'typin')--but still, the termsList would have to contain strings, not variables. Perhaps obviously, the a-list approaches use way more memory and are much slower than the symbolic index value scheme, but permit dynamic, runtime definition of the terms.
|
|
Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
|
08-08-2007 20:26
ah kk thanks guys.
I figured I was being really dumb either because it was blindingly obvious how to do it, or blindingly obvious that it couldn't be done. :}
Too bad, as the list is really long, and I probably could have saved a fair old bit of memory. Oh well, other ways to save memory.
|
|
Chaz Longstaff
Registered User
Join date: 11 Oct 2006
Posts: 685
|
08-10-2007 11:07
From: Qie Niangao It would be a lot easier if it weren't impossible.  Well, that is, a list can't contain variables, only values. So the line list Variables = [AccessNo, AdminList, AdminMode]; would try to evaluate AccessNo, etc., and put the values into a list, rather than storing some kind of handle or pointer to the variables themselves. But probably what's really desired is still possible. For example, one might use a symbolic constant for the index values of the list, something like: integer ACCESS_NO = 0; integer ADMIN_LIST = 1; integer ADMIN_MODE = 2; and then retrieve the list elements by index, e.g.: llOwnerSay(llList2String(termsList, ACCESS_NO)); Or, for other applications, there are association lists, either paired or strided, the latter of which might look like: list termList = ["AccessNo", "apple", "AdminList", "banana", "adminMode", "orange"]; llOwnerSay(llList2String(termsList, llListFindList(termsList, ["AccessNo"]) + 1)); or something like that. The paired-list a-list approach is what Osgeld suggested (whilst Qie was still a'typin')--but still, the termsList would have to contain strings, not variables. Perhaps obviously, the a-list approaches use way more memory and are much slower than the symbolic index value scheme, but permit dynamic, runtime definition of the terms. kk by "a-list" approach you mean? integer ACCESS_NO = 0; integer ADMIN_LIST = 1; integer ADMIN_MODE = 2; if so, I wasn't sure I was clear how that would impact compiler memory, given that there are over 40ish terms at present to incorporate when I go to "write that out" on paper (granted, I did something like that already, as I think you've seen over here [url], and I'm itching to get rid of it as it is.)
I liked this idea:
list termList = ["AccessNo", "apple", "AdminList", "banana", "adminMode", "orange"];
but my mind kinda boggled when I tried to flesh it out:
list termList = ["AccessNo", "apple", "pomme", "apfel", melanzana", "AdminList", "banana", "banane, "banane", "banana", adminMode", "orange", "orange", "orange", "arancia",]; (etc for 40ish terms.
I thought it had the potential of becoming unwieldy for a tired pair of human eyes to manage (given that most of this LSL stuff is done in stolen wee hours, grin.)
|
|
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
|
08-10-2007 14:18
a-list = association list, as he describes above.
|
|
Learjeff Innis
musician & coder
Join date: 27 Nov 2006
Posts: 817
|
08-10-2007 14:29
Another way to have associated lists is to use two lists, one for the names and one for the values: list Names = ["height", "depth", "width", "weight"]; list Vals = [1.9, 1.0, 1.0, 100.0]; I often use this especially when the set of names comes from a notecard, something like this: define=height=1.9 define=depth=1.0 When parsing the config card line, I use something like this: config_parse(string line) { list parts = llParseString2List(line, ["="], []); string cmd = parts[0]; if (cmd == "define") { string name = parts[1]; float val = (float) parts[2]; Names += [name]; Vals += [val]; } }
Then, if I put all the names in a menu and the user picks one, I get the value like this: integer index = llListFindList(Names, [name]); if (index != -1) { float val = llList2Float(Vals, index); }
HTH 
|