Questions on Multiple Scripts, Permissions, & Bitfields

Hello,

As I'm working through learning more and more about scripting, I had another couple of questions I was having problems finding answers to in the Wiki. The answers might be in there somewhere, but either I couldn't find them or wasn't sure where to look. Was hoping someone here could give me a hand.

1) Multiple Scripts in an Object.

Many times I come across objects that have more than one script in them. Most of the objects that I have, that have these, are no modify so I can't look inside to see 'why'.

When should I use multiple scripts in one object?

How do I get the multiple scripts within an object to interract with each other? i.e. Is there some way to 'call' one script from another?


2) Permissions.

If I have several agents that I would like to run animations on (lets say that I'm trying to animate Agents A, B, & C). I have to llRequestPermissions for each one to be able to animate them. After they have given permissions, I can then use llStartAnimation to animate them.

My question is: If I wanted to put in functionality for one or more of them to turn OFF permissions....is there a function in LSL to SET permissions? There is llGetPermissions, and there is llRequestPermissions....is there an llSetPermissions or llRemovePermissions or llReleasePermissions?

3) Bitfields.

I've read and worked with the stuff in the Wiki on Bitfields and Bitwise operators and I understand the concept and usage. I understand how they can be more 'efficient' because, essentially, its like defining just ONE integer that can now hold 32 individual flags which you can flip on and off.

My question is this...

It seems that the examples I've seen access these bitfields by defining the bitfield, as for example:

integer myBunchOfFlags;

and then defining what the different bits in that bitfield represent as follows,

integer FLAG_ONE = 1;
integer FLAG_TWO = 2;
integer FLAG_THREE = 4;
integer FLAG_FOUR = 8;

allowing you to set and unset the individual bit positions in myBunchOfFlags.

What I don't understand is...the above example defines 5 integers in total to keep track of those flags. If you just defined the individual 'flags' themselves and didn't worry about the bitfield...setting the individual flags to 1 or 0 for on or off....wouldn't that require defining LESS integers (4 defined instead of 5)? For example...instead of using the above....using the below:

integer flagOne = 0;
integer flagTwo = 0;
integer flagThree = 0;
integer flagFour = 0;

allowing you to set each flag above to 1 or 0 (on or off) and simply test on the flag itself instead of on a bitfield.

The second example seems to do the same thing as the first example, but requires 4 integers instead of 5.

Maybe I'm not understand how to properly use the bitwise operators and such.

Any help would be appreciated.

Thanks!

I'll answer your questions 1 and 2.

1.) Scripts in an object count as seperate entities - If the are two scripts in an object with a touch_start event, for example, when tht object is touched, BOTH scripts will fire. There are several ways for scripts inside an object to communicate with each other, the main two being regular chat on private channels, or link messages (script 1 says 'blah' on channel 2, and script 2 is listening on that channel, and responds to 'blah'). Link messages are private to the object.

3.) On of the benefits of using bitflags is that it makes conditional statements execute much faster; saying

if(myflags == flag1|flag2|flag3)

is much faster and readable than

if(flag1 && flag2 && flag3)

The former is only doing 1 conditional statement and 2 math operations, rather than 3 conditional statements, which I think is much slower (CPU-wise).

At least this is what I assume. I could be completely wrong, because I'm not privy to the internal workings of the LSL compiler.

Well, this may be more readable, but it's not exactly equivalent to flag1 && flag2 && flag3. This checks if flag1, flag2, and flag3 are set, and the rest aren't. To just check whether the three are set and not care about the others, you'd do this:

if (myflags & (flag1 | flag2 | flag3))

Which is arguably not as readable as using separate variables.

To answer the original poster's question, I'd say that you're right: don't bother using a bitfield in a case like this where you have 4 individual flags that can be stored in separate variables. A bitfield can be useful if you want to refer to a set of flags algorithmically by number. For example, if you are writing a game, and want to store some flag for each player, and want to refer to them by player number, a bitfield is ideal because you can access it dynamically by number almost like an array:

integer playerFlags=0;

if (playerFlags & (1 << playerNumber) ...

playerNumber is an integer identifying the player... probably starting at 0. The shift puts a one in the proper bit position for that player, and the & checks only that bit and not the rest . In this case, using one bitfield is a big advantage; otherwise, you'd have to use a list of integers or, worse yet, an if statement to switch between separate flags per player (ugh).

Hmm, so that's why my atomic death ray wasn't working...

Yes.
The easiest way for multiple scripts within 1 prim, or an object made up of multiple linked prims is Linked Messages. There are no channels involved in link messages, but rather you can send messages to a specific prim in a link set(or all). Link messages are private. For scripts in the same object, you will rarely/never need an open listen for one script to talk to another.

As for when to use multiple scripts in one object, here are two SLworld examples

- As a data-storage script.
Currently, a script can hold ~ 70 keys before it overflows. So, if you want to hold more than that, you need to store the data in multiple scripts.

-As a control script
In my 'utility belt', I have one script that just serves to take in commands, and pass them along to the relevant other scripts in the same object. A side benefit is that keeps things manageable - each script is responsible only for it's little functions. Also makes updates a bit easier - only have to update a little piece, instead of the whole.

Hope this helps,
Max.

There's no release permissions, reseting the script works, having someone else request it overrides the old permissions. This multi-permission system is, btw, one of the classics for using multiple scripts since each one will only hold one person's permissions.

Parts for confidential data can also be split if you need people accessing other parts of the script(s). There are other ways to do it too, but you could, for example have something that emails you and 'hide' your email address to reduce spam in a no-modify script whilst allowing people access to other parts...

The other big use of bitwise flags is reducing communication load. I can set a load of flags and pass them on en masse, in one message (actually with a link message as one part of one message) and efficiently unpack them at the other end. Passing the total of 4 bitwise flags as a fifth integer and unpacking it saves me at least 1 link message. The same for 32 saves me 10. It might not be too much extra, but sometimes every little helps.