Best Practices guide of some sort?

[Trinity Fraktul]

What I'm hoping to get from this thread is more of a "best practices" guide so I can start off doing things the right way o.0

In my object oriented brain, I would think that if I had an object which was a gameboard, each of the sections of the scoresheet would have a lot of common properties and functionality, so they would implement the defined functionality of an abstracted "scoresheet item" and customize themselves as need be, like so: (pardon my psuedo oo code)

 

game = new AwesomeGame();
item = new ScoreSheetItem();
item.value = 25; //for 25 points
item.text = "the floating text above this says its value";
game.scoresheet.add(item);
item2 = new ScoreSheetItem();
item2.value = 50; //for 25 points
item.text = "I'm the second item";
game.scoresheet.add(item2);

 

...each ScoreSheetItem would handle its own events, touch or reset or blastParticles or whatever they need to do.  when you wanted the total score of the game, you could iterate through all of the items in the game.scoresheet and total the score.  

How do you accomplish this with lsl?  or do you not even look at it the same way?  

I built the game, the game is working, but I have to think I didn't do it in the best way.  What i did was create 12 scoresheet items, and copy the same script into each of them, made some minimal customization to the variables in the script (the score, display text, texture offset (they're all using on texture)), and then in the root game prim, send and recieve messages for those children to report back with their score when they had been touched.  the pattern goes like this: 

 

1. on rez of game, root prim asks all children to report themselves, and listens for their message.  
2. all child prims message the root back with their number and what they are - scoresheet item, or other prim
3. root prim keeps a strided list of these in a scoresheet list - [1, 0,  FALSE, 2, 0, FALSE ]
4. when the child it touched, it sends a message to the root with its number and current score, which gets replaced with the scored values in the list - [1, 25, TRUE, 2, 50, TRUE]
5. at the end of the game, I run through that list and add up the 2nd entry in the stride of 3 to get the total score.  

Right off the bat, I see this is the wrong way to go.  Theres a ton of repetitive, unnecessary code, and that must have a direct impact on the size of the script.  I had a couple ideas about how to optimize this, one being to remove the script from the child prim altogether and have the parent handle all the events, customization, etc.  This is the route Id like to go, but what I don't see clearly is how to get a handle on which of the linked items are scoresheet items and not other types of linked items - do I have to know the child objects name in order to do this?  ie: iterate though llGetNumberOfPrims(), use llGetLinkName(iterator) to see if its a "scoresheet item" and if so, set the texture to the right offset and etc.  

This seems like a step in the right direction, but still not streamlined - would either have to depend on the order of the linking to know which scoresheet item is the one to assign as 25 points or 50, or what texture offset to give it, or I would have to name each item something unique and have a check for each name in the iterator.  

Is it better then to have the root object rez & link its own children?  that seems like a larger script, but possibly with more control over it. I haven't thought this one entirely through, but I think I would still have to uniquely name each of the inventory objects to be rezz'd.  

I should add that the 4th option would be to use 1 prim for the entire scoresheet, and use the vector of the touch to decide what the score would be, but at this point I want to be able to float some text over the score item so that wouldn't work, and creating a texture that large with every possible combination of scores seems like a really big undertaking :)

ok, theres my enormous question, I hope my logic at least makes partial sense :-)  Thanks in advance for any replies... 

 

 

 

[Rolig Loon]

You could do the entire thing with a single script in the root prim.  Take a look at llDetectedLinkNumber  >>> http://wiki.secondlife.com/wiki/LlDetectedLinkNumber .  So long as you can tell which prim in the linkset was touched, you can filter the responses, build link-specific lists, do whatever stats you need to.........  You can also use the PRIM_TEXT parameter in llSetLinkPrimitiveParamsFast to put different floating text over each child prim, which is another part of your plan..

[Trinity Fraktul]

thanks for the super fast reply  

[Void Singer]

unfortunately normal OO reusability practices and constructors don't mesh well with LSL, which is essentially event driven procedural, with it's reusability locked to functions and resets.

you can generalize some OO principles though, like your score sheet, to a list (since each property is just a variable in this case), and tie it to a key, database style, as a record set.

there are two ways to do this depending on how you want to handle those records, and how many you need to handle. The first is straight forward, each record is a serialilized group of values, and all records go into the same list, and can be read id strides. it's optimal for larger records (many elements), or ones that use list statistics functions. unfortunately it's not optimal for large numbers of records, but it is possible to make dynamic length records. it's horrible for searches.

the second, which I tend to favor, is a key list, and and a list for each property, with each record being the same index in all lists. it allows for larger numbers of records in general (gets around stack duplication) but is sub optimal for large records, variable lengths records (max always controled by list declarations), and is inefficient for operating on the whole record together, but it's optimal for list searches of a single field.

 

as for actually building the lists, you've got plenty of options, but it seems that right now you are using a particular touch interface.... you can do this by prim name (or description) without worrying about link order by checking llGetLinkPrimitiveParams( llDetectedLinkNumber( 0 ), [PRIM_NAME] ), or if you have a single texture, using llDetectedTouchUV (possibly with llDetectedLinkNumber) to see which option was chosen. you can also grab the key of the toucher if there are more than one and you want to store them separately, letting you use the same interface for multiple users without collision.

 

ETA:
there really isn't a best practices guide that I'm aware of. The base language was hacked together inside of a week (it's core in a single weekend) and almost all the documentation was written by users and all caveats discovered by trial and error.

[Trinity Fraktul]

awesome feedback, void!  thank you both so much.