List Question

I've just been reading up about the limits of lists, specifically the 72 entry limit and it got me wondering. Assuming it can be done without severely impacting performance, can you just keep adding entries to the script once it's running to breach this limit? As far as I can tell it's just at compilation time that the list mustn't have more than 72 items right?

Also, I'm using a list to keep track of certain other objects and their parameters, so there will be three or four entries per object, so the list would be like:

list["o1p1", "o1p2", "o1p3", "o1p4", "o2p1", "o2p2", "o2p3", "o2p4"]

So if I want to get the information for object 2, I find the first entry in the list and then get the next three entries too. I've considered putting all the parameters in one entry but that's by-the-by. I was just wondering how easy it is to update a list entry since I know its position in the list.

the limit is only for compile time as your guessed, since I have stored 300+ keys in a single list (which is near the maximum space available for current scripts, and ~150 if you don't use memory saving techniques)

memory saving works by clearing a variable to be saved to before loading it, like this

my_list = (mylist = []) + my_list + new_value;
instead of
my_list = my_list + new_value;
or
my_list += new_value;

for functions it works a little differently as in
my_list = llList2List( (my_list = []) + my_list, start, end );
instead of
my_list = llList2List( my_list, start, end );
or
my_list = (my_list = []) + llList2List( my_list, start, end ); //-- doesn't give the desire result

this may or may not change with mono.

EDIT: woo hoo, 2k posts... well binarily speaking (204

OK, so if I understand you right then you're saying that rather than updating an entry in the list, instead I empty the list and put all the info back in with the new information instead?

Just so we're understanding each other too, I'm talking about updating an entry, not adding another, so lets say we've got this:

list["a", "b", "c", "d"]

and I want to change "c" to "3" so I have this:

list["a", "b", "3", "d"]

in that exact order. That's what's most important for me; that things are in the right order, else nothing will work properly.

Cheers

This:

list list_test = ["a", "b", "c", "d"];

default {
	state_entry() {
		list_test = llListReplaceList(list_test, [3], 2, 2);
		llOwnerSay( llDumpList2String(list_test, ","));
	}
}

or:

list list_test = ["a", "b", "c", "d"];

default {
	state_entry() {
		integer r = llListFindList(list_test, ["c"]);
		list_test = llListReplaceList(list_test, [3], r, r);
		llOwnerSay( llDumpList2String(list_test, ","));
	}
}

will return:
"temp2: a,b,3,d"

Void's technique is commonly used to minimize memory use during execution. The problem stems from the fact that lsl passes parameters by value and not by reference, so every time something gets passed or used another instance of the value has to be kept in memory. You will likely be updating your list with something like llListReplaceList which must pass the original list as a parameter and ends up with a new list, thus requiring two lists in memory at one time. So if your list takes up 5 K of memory, you actually would need 10 K to complete the operation.

The technique that Void illustrates is a lsl hack that reduces the large memory requirement. I don't fully understand why it works. It has something to do with the way lsl functions under the hood. It effectively clears out the memory before writing the final list.

BTW the same thing works for strings. Don't worry about why, just get in the habit of using it.

Warning: Thread derailment in progress!

Congrats on 2K Void!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Unfortunately LL may not recognize the value of the content creation forums or the contribution we make but there are a whole bunch of users that do!!!!!!!!
Thank you from all of us!

Now we return you to your regularly scheduled topic.

the format is the same as outlined above
mylist = llListReplaceList( (mylist = []) + mylist, (list)"3", 2, 2 );

WHY it works
lsl does assingments from right to left, so in effect you are building a new list, THEN clearing the variable that will hold it, then loading that variable (which is now empty) and placing the built list inside of it. the exact reason this works (when logically the act of clearing the list should first load it, as happens normally) is up to the vagueries of how the lsl VM works. I think because it treats empty assignments differntly than valued assignments... at a guess

now if you aren't using big lists (like 100+ keys) then you'll probably never need to do this... but since you mentioned the compile limit on lists I thought I might bring it up.

PS thanks Jesse, I too wish they recognized the forums value, or the wiki's (and not just the lsl portal either) but it seems more like they treat it as a fly in the ointment, than the icing on the cake. odd since only payment info on file people can view the forums, you'd think they'd treat it as a bonus and encourage it.

Thank you all, that has explained everything with the clarity of pure water

I'm gonna head in world and set up a demo for my own benefit before trying to tie everything I've learnt in the past few weeks into my final project. Hopefully all will be revealed soon

Thanks again all, and I recognise peoples contributions I can assure you, not that my recognition is worth anything

WOOHOO! Looks like we won't have to use the trick anymore in MONO.

LSL1 returns:

[12:05] Object: a,b,3,d
[12:05] Object: 15901//Using optimization saves 12 bytes
[12:05] Object: a,b,3,d
[12:05] Object: 15889//W/O optimization

MONO:

[12:04] Object: a,b,3,d
[12:04] Object: 61368//Using optimization
[12:04] Object: a,b,3,d
[12:04] Object: 61368//W/O optimization

Landing, you are wrong in your self-assessment. Even if you had only answered one single question, you have demonstrated what makes a society, a society, evolving past individualism. You have given up some of your "free" time to help others without any thought of recompense.

Ah yes, but have I answered anyone's questions? All I do is ask, I don't pretend to know enough to help people on here, though I do admit that in world I do help people if they ask. I'm more of a PHP coder than LSL

Maybe my questions and your answers may help the next person to come along though?

About Mono though; do we know if the existing 'hack' will be broken by Mono or are you just saying that there is just no point using it in Mono?

::ding:: now you've got it. =) trust me, when first peering at lsl, others questions provide answers we may not have even had the question for yet. I know it did for me, in fact I still learn things. it's also good for exploding self taught myths along the way, and learning new tricks.


a very good question... can we get a comparison of byte used rather than bytes left? granted with 4 times the memory available, even if it's broken, our upper limit will still be twice what it is now under the current vm

OK, I like what I'm hearing and thank you. Got a little playing around to do before I actually make a start on my final series of scripts, and I'm most grateful to everyone who has helped me ever, but especially this past couple of weeks. The two things that were sticking points for me were lists and encrypting messages between unlinked objects that had to be instantly replied to. Solved the message problem thanks to help on here and now I understand the lists too (I think). I think when I put the instructions in with the final product I shall put a "big thanks" on the notecard that credits people on here in general, but especially those who have helped me recently. I appreciate it so much

Haven't had a chance to play with it yet............ Someone has already filed a jira on it stating it is broken but I have a sneaking suspicion that it isn't and that just as the heap is recycled and freed up in MONO, that this is also. Easy enough to come up with a script to demo it and manually count bytes to verify.

you could use my method

an endless loop that adds keys 10 at a time, and a say that gives the number of entries in the list, each method will give the count right up till it fails. =)

if both methods report the same failure number, the hack is either broken or won't work.

for a baseline you can use the lsl VM figure which fail at around 160 and 320 keys in a list for their respective methods, and multipl by 4... not exact but it should be close.

I've specifically tested this, and thus far, mono-compiled scripts also evaluate concatenation operations right-to-left, so the code still works.

Thank you. I was happy to test Havok4 but testing Mono is a little beyond my abilities