Can you use an array in SL

[naughtyniece]

Hi,

Hi, I am trying to convert some code I have, so that I can use it in SL for a game I am making (still), but the code I use has an array Value( ) which I set

value(nRemaining) = i + 1;

But I can't seem to use an array in SL, how would I do this, as I need a value for value(1), value(2), value(3) etc etc so I can use later in script

while (binary > 0)
        {
            if (binary % 2 == 1)
            {
                sum += value(whichTile);
            }
            binary /= 2;
            whichTile++;
        }
        validMove = (sum == diceTotal);

 

[Ipecac Burnham]

LSL doesn't have arrays.

 

You could perhaps use strided lists.

http://wiki.secondlife.com/wiki/Category:LSL_List#Strided_lists

[naughtyniece]

ok thanks, I have managed to do it, using Lists

Edited March 18, 2018 by naughtyniece

[Rolig Loon]

Strided lists are one option.  The other is to use parallel, independent lists, making sure that they are indexed the same way and have the same number of elements.  Your choice of which option to use depends on the situation. You'll find strided lists more convenient sometimes, but not always.

It is also possible to use JSON, but I have never found a practical advantage for it in LSL, myself.

[Nova Convair]

I just calculate the list index. If I have a 2 dimensional array with index a and b and the size of a is 10 (0-9) then the list entry is simply b*10+a
For a=0..9 and b=0..x

If I store records I use a string with divider between the elements as list entry.

The list needs to be initialized since it's not possible to read/write non existing list elements.

If the data structure becomes really complicated then json is maybe a better choice

[Pussycat Catnap]

This always blows my mind... I think the very first thing I ever did with a computer, in the early 1980s, involved an array...

Like... on a computer that didn't even have a hard drive yet...

I am always confused as to HOW they managed to not put arrays into LSL... that's like coffee... without roasting the beans... It just belongs in the dictionary as a listing under "fail".

 

[Rolig Loon]

You won't get much argument from LSL scripters.  I was using arrays in Fortran II back in the mid 1960s.  In defense of the Lindens who gave us LSL, however, I should point out that the language was designed to move things around and to handle communications, not to do a lot of heavy number crunching and statistical calculations. It was also designed initially to work within 16K of memory (now 64K in Mono), again not well suited for handling a lot of data.  If you were around before Mono became the standard here, or if you have looked through the "hacks" section of the LSL wiki, you've seen the sort of juggling that we had to do with lists to keep from using up what little memory we had available compiling under LSL.  All of this doesn't mean that we couldn't have had arrays ( I remember using arrays on a PDP 8S -- with 8K of memory -- back in the 70s), but it at least explains why they haven't been high on Linden Lab's priorities. 

[Love Zhaoying]

10 minutes ago, Rolig Loon said:

You won't get much argument from LSL scripters.  I was using arrays in Fortran II back in the mid 1960s.  In defense of the Lindens who gave us LSL, however, I should point out that the language was designed to move things around and to handle communications, not to do a lot of heavy number crunching and statistical calculations. It was also designed initially to work within 16K of memory (now 64K in Mono), again not well suited for handling a lot of data.  If you were around before Mono became the standard here, or if you have looked through the "hacks" section of the LSL wiki, you've seen the sort of juggling that we had to do with lists to keep from using up what little memory we had available compiling under LSL.  All of this doesn't mean that we couldn't have had arrays ( I remember using arrays on a PDP 8S -- with 8K of memory -- back in the 70s), but it at least explains why they haven't been high on Linden Lab's priorities. 

It’s almost as if LSL is based more on LISP than C.

[animats]

LSL lists are arrays. They just have to be accessed through functions.

Experiences get a persistent key/value store. Why that's limited to experience scripts isn't clear. Fear of choking the data server?

[Innula Zenovka]

16 hours ago, animats said:

Experiences get a persistent key/value store. Why that's limited to experience scripts isn't clear. Fear of choking the data server?

I can think of several reasons.   One would be that it's a completely new feature and LL wanted to release it into a controlled environment in order to collect some data about how it's used and how much data people need to store before making available grid wide.    Another would be to encourage premium membership, of course!

There's also a design issue.   At present, it doesn't matter if you and I both use the same key name to hold data -- PlayerData_playerUUID, for example -- because the two keys are part of two separate experience, so there's no danger of your key names colliding with mine.   At the moment, it's up to me to worry about keeping my key names unambiguous and up to you to do the same with yours.   If we don't separate them into separate experiences, though, there has to be some way of keeping your collections of data separate from mine, while allowing for collaborative work (which means the data can't simply be tied to the scripter's uuid). 

I'm sure it can be done, but it would add several layers of complexity and more things to go wrong.

I agree it would be very handy, though, if KVP could accessed from anywhere on the grid rather than only from regions or parcels where the experience is allowed to run.