Is there a limit to how scripted something should be?

[Pamela Galli]

I have this kitchen island. In the main prim is a texture change script.  One prim has a half dozen  items that rez on Touch, and two single animations and one couples animation, and one prop to go with the couples. Another prim has a singles animation for a friend to use. Another prim is for the other half of the couples animation.  Another prim has about a dozen things with a variety of Give on Touch things that rez on touch from a menu.

 

So we are talking about a lot of scripts. And they dont seem to be working very reliably.  I have to keep resetting them to get them to work correctly, and even so the prop refuses to rez at all, even tho it has earlier today.

 

It is a little late to be asking after all this time I have spent on this thing, but can one object have so many scripted prims and function correctly?

[LepreKhaun]

---

Pamela Galli wrote:

I have this kitchen island. In the main prim is a texture change script.  One prim has a half dozen  items that rez on Touch, and two single animations and one couples animation, and one prop to go with the couples. Another prim has a singles animation for a friend to use. Another prim is for the other half of the couples animation.  Another prim has about a dozen things with a variety of Give on Touch things that rez on touch from a menu.

 

So we are talking about a lot of scripts. And they dont seem to be working very reliably.  I have to keep resetting them to get them to work correctly, and even so the prop refuses to rez at all, even tho it has earlier today.

 

It is a little late to be asking after all this time I have spent on this thing, but can one object have so many scripted prims and function correctly?

---

Within LSL (under mono) the limits are only memory and the understanding of the scriptor. Multiple scripts can (as it did unde rLS0) overcome memory limitation, which is imposed by the necessary  "sandbox"  that our (untrusted) scripts are allowed to run within.

 

That said, it is possible to have (theoretically) any number of scripts interacting with each other; each doing its job and returning the results back to (eventually) some "BOSS" script that directs everything. The "trick" to doing this is 3-fold:

1. Defining how "jobs" are to be delegated to different workers.
2. Defining a protocal of communication between the various workers.
3. Defining the algorithm that implements #1 and 2.

 

And I'll be the first to say that this isn't an answer to your question! But that's only because you're asking the wrong question. What you really need to know is how to get a number of actions (scripts) to work together.

 

And the answer to that question IMO should be explored...

[Pamela Galli]

Thank you :-)

 

For the most part these are not scripts that work together, except for the couple animation. They work mostly serially --you do one thing, then you do some other thing, then some other thing.

Maybe my sim was just lagging or something.  I just know it is terrifying to see something that has taken thousands of hours to make -- not work correclty.

[Qie Niangao]

Lag could certainly affect your ability to test the scripts, but of course lag also generates user support problems -- and the more scripts involved, the more such problems will arise when the products are in the field.

There's also usability, and that may become a worse issue than lag. Most buyers just want a simple prop for their pixel house or pixel dolly, not something that requires an instruction manual to operate.

All that said, whether or not it's a good idea for a product to have the functions listed, it's quite common for objects to have scripts doing all that and more. My hunch is that there's something simple and silly interfering with rezzing (some geometry not quite right, such that it's trying to rez the root prim more than 10m away, perhaps?). Other problems... yeah, maybe lag, but IMHO more likely some bugs somewhere.

[Pamela Galli]

---

 

---

Thanks Qui.  I am not going to release until it is working reliably.  

 No, this kitchen is certainly not for most buyers -- it is more a role play toy, where they can prepare and then cook the food they serve on their tables. Everything is scripted within an inch of its life, but yes I do have an instruction manual HUD (linked to pages here http://lagalleriadinnerpartykitchen.blogspot.com/) , plus other Say on Rez instructions and instructions in description field. Amazingly, I dont get many questions about how to work things, which is actually pretty standard.

 

[Rolig Loon]

The number of scripts in an area is rarely the issue, as Leprekhan points out.  The most common problem is disagreements among scripts.  These can include

• cross-talk when scripts use the same communication channel,
• competing touch events when there are two or more touch-sensitive scripts in the same linkset
• processes in one script that affect the number of links, position, size, or contents of an object that another script depends on

Problems like these are more likely to happen when a project has grown gradually over time.  One good idea will lead to another, accreting new features and more moving parts until the project is much richer and more complex then you originally expected.  If each new part is scripted by a different person -- or even by the same person over a period of months or years -- it's increasingly likely that the parts will not be well-designed to work together.  The more scripts there are, the harder it is to track down disagreements among them, and to avoid creating more problems. 

The obvious solution is of course to design all complex systems carefully from the beginning and resist adding new features later.  That's hardly practical, however, and it is anathema to the creative mind.  However, it is sometimes smart to take a deep breath, clear the decks, and do a radical new design that incorporates and improves on Version One.  That's more than a technical decision.  It's all bound up in your business model and the way that one product line fits into the larger enterprise, to say nothing of how you prioritize your own time and resources. 

Sometimes it makes more sense to keep applying bandaids. :smileywink:

 

[Pamela Galli]

What I added to the island was the couples animation that rezzes a prop with it -- except the prop does not rez now.  It did rez but then stopped.  Also now when I switch animations sometimes the animation will be facing the wrong direction.  So the problem is not with any of your excellent (dummy proof) scripts, Rolig, but with the animation script. We had already had to get rid of one couple animation because when you switched animations one was always facing the wrong way -- the script support said the problem was with the animation. Well now it seems the problem is with all the animations. :-)  

 

So if I cant get this thing to work properly I will just try a different system. (I bought this one because it had video instructions.)

[Yingzi Xue]

Sounds like an issue with the scripts themselves and/or how they've been configured. The amount of scripts being used shouldn't be an issue. As per the other reply above, if scripts are fighting each other (using the same comm channel, for instance), you'll have strange results. Lag can rear its ugly head at times, but lag and x amount of scripts in a region aren't going to cause an animation to be flipped backwards or a prop not to rez (unless said lag is causing chat or link messages to be dropped or missed; rare and unlikely), those are configuration/script issues that need to be resolved. My advice, try going through the config process again with the problem animation and prop. If it does the same thing, contact the script author and request help. The only time I've ever seen an animation cause issues is when they are uploaded without a loop setting, which can cause the animation to play once then end, thus your pose may not stay constant, but just stop altogether and go back to your AO or sit or whatever animation is the default.

[steph Arnott]

All I can say is, if the com channels are not being filtered for specific commands or data then anything can happen. Unfortunately some write scripts with no thought for cross communication. Only thing I can suggest is finding the good stuff and removing the bad and that means rezz a test until something goes wrong. Sorry not very helpful. If you wrote the scripts then first thing to do would be to set com filtering

listen(integer channel, string name, key id, string message)	{		if ((channel == 9000) && (message == "door"))		{			do stuff		}

 As for com filtering, I tend to go overboard and I not sure if that's a good thing, especially if others here read them, LOL