Parsing notecard with dumps of pos/rot/size

[Suki Hirano]

Hi, I was wondering if parsing a notecard would save on script memory? I'm running into stack heap collision error probably because I have too many lists containing dumps of link pos/rot/size of links: http://pastebin.com/0pRc6uen

If so, what would be the easiest way to parse these pos/rot/size dumps? Right now my dump syntax is like this:

 

pos1 = [<vector position of 1st link for 1st position>,<vector position of 2nd link>,...]
size1 = [<vector size of 1st link for 1st position>,<vector size of 2nd link>,...]
size1 = [<quaternion size of 1st link for 1st position>,<quaternion size of 2nd link>,...]

pos2 = [<vector position of 1st link for 2nd position>,<vector position of 2nd link>,...]
size2 = [<vector size of 1st link for 2nd position>,<vector size of 2nd link>,...]
size2 = [<quaternion size of 1st link for 2nd position>,<quaternion size of 2nd link>,...]

The link numbers are not 1,2,3,4... They're stored in the list "accessorieslinks". I.e., I scan the entire object for each prim with the description "accessory" then add its link number to the list, since I only want "accessories" to be affected by the resizing/repositioning.

Edit: the coordinates in the pastebin script are just an example (yes I know pos1 and pos2 are identical, I was just copy pasting).

Edit: there is absolutely no pattern with the coordinates so I can't have just 1 set of coordinates, then use math to "model" the coordinates for the other positions. I manually resized/repositioned every single prim for every position.

 

Thanks.

[Rolig Loon]

Memory may be an issue if you are reading and then storing every single set of values into lists, so it might be wiser to figure out a way to read part of the total and then delete or overwrite it as you don't need it any more.  For your immediate question, though, you can certainly read values faster from a notecard if they aren't all on separate lines. So, pack the related ones together and then parse them out as you read the card (or, better still, as you need them).

<position vector 1>~<size vector 1>~<rotation vector 1>

<position vector 2>~<size vector 2>~<rotation vector 2>

<position vector 3>~<size vector 3>~<rotation vector 3>

<position vector 4>~<size vector 4>~<rotation vector 4>

Then for each line of data, read values as follows:

list temp = llParseString2List(data,["~"],[]);

vector PosVec = (vector)llList2String(temp,0);

vector SizeVec = (vector)llList2String(temp,1);

rotation Rot = llEuler2Rot((vector)llList2String(temp,2) );

 

[Profaitchikenz Haiku]

There is one slight problem in that a script can only read the first 256 characters of a notecard line, so it does pay to monitor the line length as it gets built up.

 

http://wiki.secondlife.com/wiki/Category:LSL_Notecard

 

One trick is to take chatted lines from llDumpList2String out to an external editor and compact all the strings of consecutive zeros  which is what I had to do in order to fit all the information I needed into the one line.

[Rolig Loon]

That's true, and it's something to watch for if you want to pack more than three vectors into a line on the notecard.  Three vectors (or two plus a rotation) are well below the length limit, though.

BTW, if you want to compact vectors or rotations by getting rid of trailing zeros, you don't have to do it manually with an external editor.  It takes a bit of work, but you can write a LSL script to do that.

[Miranda Umino]

I see in your psate , you have written your rotations with 6 digits .

When you convert a string to rotation , the precision of 6 digits are not enough .

Your result quaternions won t be normalized ; if you manipulate your unnormalized rotations with other LSL functions, you could meet some issues

So , 

- either after reading your strings containing the rotations , you normalize the rotation

rotation NormRot(rotation Q){    float MagQ = llSqrt(Q.x*Q.x + Q.y*Q.y +Q.z*Q.z + Q.s*Q.s);    return  <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>;}

- either you use in your string a precision for rotations of 8 digits .

 

- either you use in your string , some rotations written in C99 float format

 

 

[Suki Hirano]

Thanks, it seems there's no really good way to save on memory when I got lots of positions stored. I just ended up using a second script to store a portion of the coordinates.

[Profaitchikenz Haiku]

Using extra scripts and communicating by link messgaes is a very good way to seperate data and functionality, I use the method often. It also allows the main script to be reset without all the stored data in other scripts also being reset. The second script could reset when it detects a new notecard being dropped into the prim it is in, and after reading and checking the data, it can reset if necessary and tell other scripts also to reset, via link messages.

 

My suggestion would be to use extra scripts to store all the data, and only pass the main script what it needs to know for the moment.

I have looked quite a bit at scripts on my island using the region console, and as far as I can see, script memory is nothing like the issue script time is. Ypu are , I think, better off paying attention to getting the scripts running so that script time is op[timised.  From personal experince coding, when you start to pay attention to streamlining the execution of a script, a by-product of this is that you usually improve the way it uses memory as well.

[Qie Niangao]

---

Profaitchikenz Haiku wrote:

I have looked quite a bit at scripts on my island using the region console, and as far as I can see, script memory is nothing like the issue script time is.

---

Yes, script memory is nothing like the problem it used to be. Just for completeness, though, it's tricky to test because its effect is very non-linear: it won't matter at all until a threshold is crossed corresponding to exhaust of the host's physical memory, and then performance will fall off a cliff. (They seem to have added a bunch of physical memory to the simulator hosts to push that "cliff" further away from normal operating conditions; also, the penalty of paging can vary by OS, hardware, application design, etc., so they may have improved that, too.)

As to the original problem of this thread, if I understand the planned operation of the script, it's not clear why all these separate lists are needed. Why not one great, long list of all the parameters for all the links for all the animation states? Are there really so many that they won't fit in one script? The main advantage being that, instead of some long list of if / else conditions for triggering the "lots more" animation states, it can be just one block of code that calculates indices into that long list corresponding to "positionselected." That would save a bunch of program memory (if that's really how this script works).

Finally, if it's possible for that one long list to be local to a single function or event handler, that may dramatically reduce its memory use. (At least that's what's claimed in this source, subject to confirmation.)