Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Allow second user to control private channel script

Tre Ugajin
Registered User
Join date: 11 Aug 2008
Posts: 11
02-22-2009 00:06
I took some initiative and coded my first script in LSL.

It is simple. Move a box up 8m and change it's texture to clear, so it is out of the way and unseen. At the same time, change the texture on a couple of other objects, making them visible. This all works together to create a privacy type setting for photos, while removing a box that covers our basic studio so others don't just come in and use it when they please.

Once done with the studio, I move the box down 8m and change it's texture to solid black again, and change the other objects textures to clear.

All of this is done through simple private channel commands (/# command for state 1, /# second command for state 2... both commands use the same channel#)

It worked very well. And I saw that it was good and I rested... for about a minute.

Then I got the idea to make it typeless and created a simple two button HUD. Essentially "lock" and "unlock". Dropped llSay into each with the channel number and command for each state respectively.

Attached the HUD and voila! It was good and again I rested... for about a minute.

Now I have no rest. My problem? I need one other person to use the same HUD. I give my partner the HUD and it wont work. I pull hair, cuss, the whole 9 yards when I realize, also, after my partner tries and fails to make anything work in type commands or the HUD itself, I try again and the box wont move up or down anymore for me, typing or HUD controlled, but the other objects change textures for me by both types of command.

I relog. It works for me again. Phew. Again partner loads the HUD and tries and fail. I try again. Same issue as before. Box wont ove, other objects still change texture.

I need help. I just want two people to control the same setup with a HUD.

What am I doing wrong?

Thank you in advance for anything anyone can give.

Here is code for HUD, box, and "shades". The channel and commands have been changed to protect the innocent:

-----------
Box Script:
-----------
default
{

state_entry() {
llListen(16,"", NULL_KEY, "";);
}

listen(integer channel, string name, key id, string message) {
if (message == "close";) {
// move down over studio
llSetPos(llGetPos()+<0,0,-8.09>;);
// set the texture to logo
llSetTexture("shade",ALL_SIDES);
}

if (message == "open";) {
// move up above studio
llSetPos(llGetPos()+<0,0,8.09>;);
// set the texture to clear
llSetTexture("clear",ALL_SIDES);
}
}

}

-----------
"Shades" script
-----------
default
{

state_entry() {
llListen(16,"", NULL_KEY, "";);
}

listen(integer channel, string name, key id, string message) {
if (message == "close";) {

// set the texture
llSetTexture("clear",ALL_SIDES);

}

if (message == "open";) {

// set the texture
llSetTexture("shade",ALL_SIDES);

}
}

}
-----------
HUD Open Script
-----------
default
{

touch_start(integer total_number) {

// speak out loud!
llSay(16,"open";);

}

}
-----------
HUD Close Script
-----------
default
{

touch_start(integer total_number) {

// speak out loud!
llSay(16,"close";);

}

}
Ron Khondji
Entirely unlike.
Join date: 6 Jan 2007
Posts: 224
A couple of things.
02-22-2009 01:37
First:
You need to add some kind of flag to know if the thing is 'open' or 'closed'. Like it is now it moves to 16 m if I say open twice.

Second:
I don't see why the thing doesn't work for your friend. Since you are using open listens it should even work for me. The way to debug is llOwnerSay() in the listens to see if the object hears the commands spoken.
This brings me to how to make it work for just 2 people.

You need to filter the listens to only hear the messages from you, your friend or the hud. The easiest way to do this is to check the for the name.
Like:
CODE

listen (integer channel, string name, key ID, string message)
{
if (name == me || name == myfriend || name == hud){
if (message == open) open();
else if (message == close) close();
}
}

or something like that.

On a side note I want to add that a open listen isn't all that desirable unless you like lag.
I think it could be better if you link the objects together so you can use llMesageLinked().
To interact with the object make on prim the controller prim that starts to listen for commands on touch and stops listening after a set time or something. This object can than relay the commands to its child prims.
Tre Ugajin
Registered User
Join date: 11 Aug 2008
Posts: 11
02-22-2009 21:10
Some great help and thank you.

I am kind of lost now tho so it looks like I will be turning to the wiki and library for some sample scripts.

I am using the "Multi-user door script with locks" posted in the library to manage a door to my skybox and it works very well.

I tore it to pieces to see if I can modify it to work with this as it listens for about 30 seconds on the channel and then stops, allows an authorized list of users, and sets a locked/unlocked state as well as the open/close state.

I thought simply changing the "open door" command to the commands I would need instead would work but I am new to scripting and was easily discouraged at syntax errors beyond my comprehension level at this point.

I don't understand how to make a parent object relay commands to a child object so that is one I will be looking into for sure.

I had thought about saying open twice sending the box twice as high but I am not sure how to set flags yet either...

So your ideas are great and it looks like it is time to do some further research.

I too am confused at why it wont just work for anyone who knows the channel number and think it may be something to do with the sim needing a restart but I haven't mentioned it to the land owner yet as I have not tested it outside of the sim to be sure.

More to come and hopefully a useful script to add to the library for others to base their own new creations from soon!

Thanks again for your guidance. Much appreciation. Any further insight would also be much welcome! :)
SuezanneC Baskerville
Forums Rock!
Join date: 22 Dec 2003
Posts: 14,229
02-22-2009 21:28
Could this have something to do with group land and land options?
_____________________
-

So long to these forums, the vBulletin forums that used to be at forums.secondlife.com. I will miss them.

I can be found on the web by searching for "SuezanneC Baskerville", or go to

http://www.google.com/profiles/suezanne

-

http://lindenlab.tribe.net/ created on 11/19/03.

Members: Ben, Catherine, Colin, Cory, Dan, Doug, Jim, Philip, Phoenix, Richard,
Robin, and Ryan

-
Tre Ugajin
Registered User
Join date: 11 Aug 2008
Posts: 11
02-22-2009 23:05
From: SuezanneC Baskerville
Could this have something to do with group land and land options?


Well, I am on group land. But should that matter on this kind of script? I have a door in my skybox that is similar but much better and more advanced coding which has an auth list, but either way, only those I allow are able to open it when its locked, but unlocked, anyone can open.

And I have a tint controller as well that is currently open to all, and anyone who touches it can control tint on the same land.

Does it make a difference in this type of script?

Please understand I have no clue yet and so I am asking to understand more than anything, but trying to deduct with logic at the same time.

As for the ideas, I have initiated v2.0 of the script which so far only controls the box movement and texture change for the owner via voice commands, or anyone with HUD access. It is now flagged for open and closed state and will respond accordingly.

I am about to test it now. Will report when I have results.

If all works: NEXT ACTION: Test HUD control from single and multiple users. Possibly add "hud", "user1", and "user2", instead of "getOwner".
Tre Ugajin
Registered User
Join date: 11 Aug 2008
Posts: 11
02-23-2009 00:36
Well, I have tested the script and used a call command that only allows the HUD to control the system so voice commands do not work, which is good.

The HUD now works with any user who has the HUD. Also good.

Now, for my NEXT ACTION:

I do not understand, and am not finding anything that demonstrates understandably, a way to use parent/child scripts.

I have a box. It is the main (parent) prim that will listen for commands from the HUD.

It sends commands to child prims but they cannot be physically linked as the box moves and the child prims do not (they would have to move opposite directions which is just too much for me right now).

All of the Child prims can be linked with no problem.

But to call llMessageLinked? Will that still work from the box? Or will these objects have to be linked somehow... maybe LOCK the child prims in place, but leave the box unlocked, and link them all?

I could use a little help in understanding this concept and any ideas on how this will work together in this manner.

Currently, the box send a private message to the child prims (window shades - which are linked together but not linked to the box) to change their textures. it works, but it seems this is all open listening and this is something I do want to avoid... but I am also not TOUCHING any object to make this work, except the HUD itself. So how do I activate the system on touch?

The timer I can do... but the rest is confusing.

Thank you in advance for any further assistance in understanding these concepts and if they are at all possible in the manner I seem to be trying to put them together.
Ron Khondji
Entirely unlike.
Join date: 6 Jan 2007
Posts: 224
02-23-2009 02:02
Well if you're only going to use the hud you cannot get around using a listen, since it's not possible to use messagelinked outside of a linkset.
If you use a big negative number (or is that small?) for the listen channel, you should have the least impact on sim performance. Note you cannot use a negative channel for chat commands.

The easy, and best, solution would be to have all the objects just listen to the hud and do different things after hearing some command.

So lets say your hud does something like:
From: someone

touch_start(integer num)
{
llSay(-1234567, "Open";);
}


Then your box would do:
From: someone

state_entry()
{
llListen(-1234567,"hud", "", "";); // the more spedific the listen the less impact
}

listen(integer channel, string name, key id, string message)
{
if (message == "Open";) move_up();
else if (message == "Close";) move_down();
}


and the linked shades:
From: someone

state_entry()
{
llListen(-1234567,"hud", "", "";); // the more spedific the listen the less impact
}

listen(integer channel, string name, key id, string message)
{
if (message == "Open";) llSetLinkPrimitiveParams( LINK_SET, [PRIM_TEXTURE, ALL_SIDES, open, <1.0,1.0,1.0>, <.0,.0,.0>, 0.0]);
else if (message == "Close";) llSetLinkPrimitiveParams( LINK_SET, [PRIM_TEXTURE, ALL_SIDES, closed, <1.0,1.0,1.0>, <.0,.0,.0>, 0.0]);
}
Tre Ugajin
Registered User
Join date: 11 Aug 2008
Posts: 11
02-23-2009 08:55
What about something like a touch pad or button on a wall, instead of a HUD? Can i use commands/flags that would see a certain state and do the opposite of that state each time it was touched?

That could essentially be linked to some of the items, correct? But I still wonder about linking the box that moves with shades that do not. Unless I am just not getting a concept on this yet, it's my understanding that everything that is linked would move, if one object is moved in a linkset.

This would eliminate the HUD and control open listens as well, at least to the extent that only the box may still need to listen.

I would then need to go back to allowing multiple users to have access, and therefore might as well go back to my idea of an authorized users list, i think. Which I have a base script I can most likely get the right ideas from.
Ron Khondji
Entirely unlike.
Join date: 6 Jan 2007
Posts: 224
02-23-2009 09:31
A hud on your screen or a button on a wall is all the same.
Button script could be:
From: someone
CODE

integer flag; \\ True = open, False = close
list allowed = ["Your Name", "Friends Name"];

default
{
state_entry()
{
llSay(-1234567, "Close"); // flag = false (0) so shades should be closed.
}

touch_start(integer num)
{
if (llListFindList(allowed, [llDetectedName(0)]) != -1){
if (!flag) llSay(-1234567, "Open");
else llSay(-1234567, "Close");
flag = !flag;
} else llInstantMessage(llDetectedKey(0), "You're not allowed to control the shades.");
}
}


Or if linked to the shades:
From: someone
CODE

integer flag; \\ True = open, False = close
list allowed = ["Your Name", "Friends Name"];

default
{
state_entry()
{
llSay(-1234567, "Close"); // flag = false (0) so shades should be closed.
}

touch_start(integer num)
{
if (llListFindList(allowed, [llDetectedName(0)]) != -1){
if (!flag){
llSay(-1234567, "Open"); // for the box to move
llSetLinkPrimitiveParams(LINK_ALL_OTHERS, [PRIM_TEXTURE, etc, etc]); // change the texture on all but this prim
} else {
llSay(-1234567, "Close");
llSetLinkPrimitiveParams(LINK_ALL_OTHERS, [PRIM_TEXTURE, etc, etc]);
}
flag = !flag;
} else llInstantMessage(llDetectedKey(0), "You're not allowed to control the shades.");
}
}


With this last script you wouldn't need any script in the shades themselves.

If someone touches the button we first check if (s)he is allowed to control the shades. This we do by checking if his or her name is in the list 'allowed'.
If (s)he is in the list we open the shades if they're closed and visa versa.

And yes it is possible to move a prim in relation to the others in a linkset. Moving the rootprim and keeping the children in place is more of an effort than there's a benefit in not using a listen though.
A selective listen on a low negative channel isn't all that bad. It's those open listens on the normal chat channel that are a big drain on resources. As I understand it, the more a listen can hear the worse it is.