Kayaker Magic Posted August 3, 2011 Posted August 3, 2011 I'm working on a project where I had to split a single script into several separate scripts. I'm learning some interesting things.Like: When an avatar sits on the prim, ALL the scripts get a changed event. If one of the scripts requests PERMISSION_TRIGGER_ANIMATION (for example) none of the other scripts in the same prim can take advantage of it (unless they request their own). So apparently permissions are a property of the script, not of the prim. There is absolutely NO HINT of this in the Wiki pages for changed, llRequestPermission, run_time_permissions, etc. that I can find.Is there a Wiki page somewhere that talks about the behavior of multiple scripts in one prim? (So I can find out WHAT ELSE I might need to know before I have to figure it out the hard way for myself). 1
Kylie Jaxxon Posted August 3, 2011 Posted August 3, 2011 Yeah, but that's how you learn all kinds of neat things, by doing it the hard way :matte-motes-nerdy:
Darkie Minotaur Posted August 3, 2011 Posted August 3, 2011 I've just looked at the llRequestPermissions üage after reading your posting - you are right - the entry there hints at the best at the fact that permissions are connected to scripts. You should add your observation there.
Dora Gustafson Posted August 4, 2011 Posted August 4, 2011 Kayaker Magic wrote: I'm working on a project where I had to split a single script into several separate scripts. I'm learning some interesting things. Like: When an avatar sits on the prim, ALL the scripts get a changed event. If one of the scripts requests PERMISSION_TRIGGER_ANIMATION (for example) none of the other scripts in the same prim can take advantage of it (unless they request their own). So apparently permissions are a property of the script, not of the prim. There is absolutely NO HINT of this in the Wiki pages for changed, llRequestPermission, run_time_permissions, etc. that I can find. It is the users, you and I, that find out how LSL works and we write the documentation:smileyhappy: You can add you own finding and comments in the wiki. This finding of yours would be great to add to the wiki
Helium Loon Posted August 4, 2011 Posted August 4, 2011 This is why multiple scripts within a single prim are usually constructed so that each prim handles only certain functionality.....such as animations, or sounds, or communications, etc. Then handle script messages (via llMessageLinked & the link_message events) to allow scripts that handle all the synchronizing and logic and dialogs to tell the other scripts what needs to be done at that moment. It can get pretty complicated pretty quickly. The more functionality you put in your scripts, the quicker you have to start doing things like this. Even with one-liners like Void comes up with can take up a good bit of memory server-side, and enough of them will eventually bump up against the limits. When that happens, you break the script down into two (or more) scripts that communicate what the other needs to handle. The communications has some overhead too, in each script. So use link messages, and keep your scripts as independant as possible!
Cerise Sorbet Posted August 4, 2011 Posted August 4, 2011 Hi, the llRequestPermissions page does mention this, from the opposite way around. "Scripts may hold permissions for only one agent at a time. To hold permissions for multiple agents you must use more than one script." It is not entirely true that permissions are always for a script and not an object. There is a fragile relationship between PERMISSION_TAKE_CONTROLS and prim properties, the "no scripts" override is shared and a controls release affects all the scripts. PERMISSION_DEBIT was fragile too, but I have not checked that one in a couple of years, that one might be more persistent now.
Rufus Darkfold Posted August 5, 2011 Posted August 5, 2011 Do disabled scripts consume fewer resources? How expensive is enabling or disabling them? Disabling does reduce the number of scripts that are listening for events, which should reduce lag, as well as avoiding bugs from handlers firing when the functionality with which they are associated is not in use. This is for stuff that is called relatively infrequently, in particular when someone clicks a button associated with that script. The fact of being activated is all the information the script being activated needs in this case, so a link message is avoided. I understand that disabled scripts can lose state on sim crossings or restarts. (That does not matter for these scripts because they reset after they are re-activated anyway).
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