Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Consolidating scripts using menus

Vang Foden
Registered User
Join date: 10 Feb 2008
Posts: 10
02-15-2008 03:38
I'm a noob scripter so bare with me a sec.

I've got 3 scripts and want to use a Menu script to activate them.

The 3 all work using the touch start event. Do I have to pull bits of code from the these 3 and drop them into the menu script or is there a better way. Ideally I would like to leave the menu script clean, without it being cluttered.

I guess I really want to be able to call one script from another but can't figure out how yet.

Would appreciate your thoughts.
Kahiro Watanabe
Registered User
Join date: 28 Sep 2007
Posts: 572
02-15-2008 03:56
Well first you should ask: "Why do I need three scripts instead of having all in one?"

If each script must be in a different prim is reasonable.

If they are on the same the only reason why you are *forced* have different scripts is because of memory limit (16k per script so far)

In my case there are other factors when I consider having different scripts in one prim one is: script complexity and script task.

For example: I make a very big script that work as main menu and I need to add a feature that will make the script even bigger and the specific task is not beeing port of a Main Menu then I decide to make a new script. (It seems that this is what you want)

But if you have small scripts you can join all in one.

----
Now replying to your question if all the scripts are in same prim/object you can use linked messages. Linked messages are messages that are only sent internally between prims, and you can send a message to the same prim itself. This is the function's header:

llMessageLinked(integer sender, integer parameter, string message, key id)

More about this function: http://www.lslwiki.net/lslwiki/wakka.php?wakka=llMessageLinked

And the event that listens for this messages:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=link_message

-----

I would like to hear other opinions about this. Some scripters use the script until they ran our of memory. Others when working in big projects preffer to divide scripts according to tasks: One for main menu, another for process a, and another for process b.

----
Pale Spectre
Registered User
Join date: 2 Sep 2005
Posts: 586
02-15-2008 05:41
By 'menu script' do you mean one that uses llDialog? llDialog results in only one thing: spoken commands. You then have two choices. All of the other scripts listen to those spoken commands, or the menu script listens to those commands and uses llMessageLinked to communicate with the other scripts - in coding terms the listen Event handler is not very different from the link_message Event handler.

Given scripts that are already using a listen Event Handler it is relatively easy to have an autonomous script control them via llDialog. The only real consideration is that you have to use a fixed listen channel across all the scripts if they are all to be controlled from the same llDialog panel.

Using llMessageLinked is usually preferred when having scripts talk to each other within a single object. It requires minimal active listens and is generally a 'tighter' communication.

However, having many agnostic scripts is more modular with each one being able to more easily function in isolation. I prefer the modular approach if I'm going to use a script across a variety of applications.

Having each script carry its own listen Event Handler will make them more portable.

Having many listen Event Handlers in an object will make it less efficient (ie. laggy).

This is a good place to start: if you want to get a better idea about how scripts can communicate.