naughtyniece Posted March 18, 2018 Share Posted March 18, 2018 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); Link to comment Share on other sites More sharing options...
Ipecac Burnham Posted March 18, 2018 Share Posted March 18, 2018 LSL doesn't have arrays. You could perhaps use strided lists. http://wiki.secondlife.com/wiki/Category:LSL_List#Strided_lists 1 2 Link to comment Share on other sites More sharing options...
naughtyniece Posted March 18, 2018 Author Share Posted March 18, 2018 (edited) ok thanks, I have managed to do it, using Lists Edited March 18, 2018 by naughtyniece 1 Link to comment Share on other sites More sharing options...
Rolig Loon Posted March 18, 2018 Share Posted March 18, 2018 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. 1 Link to comment Share on other sites More sharing options...
Nova Convair Posted March 18, 2018 Share Posted March 18, 2018 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 Link to comment Share on other sites More sharing options...
Pussycat Catnap Posted March 18, 2018 Share Posted March 18, 2018 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". 1 Link to comment Share on other sites More sharing options...
Rolig Loon Posted March 18, 2018 Share Posted March 18, 2018 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. 1 Link to comment Share on other sites More sharing options...
Love Zhaoying Posted March 18, 2018 Share Posted March 18, 2018 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. Link to comment Share on other sites More sharing options...
animats Posted March 18, 2018 Share Posted March 18, 2018 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? 1 Link to comment Share on other sites More sharing options...
Innula Zenovka Posted March 19, 2018 Share Posted March 19, 2018 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. 1 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