Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Discussion: Regionwide switch using llRegionSay and some other interesting stuff

Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
05-26-2007 02:34
Part one, the sending prim
CODE

// Occupation Button script
// By Marcush Nemeth
// Copy for FREE use
// An example of how llRegionSay can let an object communicate with another object throughout the sim.
// Other interesting examples for the starting coder inside this script:
// - Using states to better control the flow your script
// - Changing the color of a prim
// - An alternative method to find the owner of an object
// This is the script you put in a button, that speaks on a regionwide channel, only announcing that it is on


// Editable variables

// The channel used for communicating between button and light.
// Make sure these are the same in sending and receiving script!
integer ChanNum = -123456;

// Just an extra prefix to every message, to make sure that different scripts on the same channel don't accidentally mix up.
// Make sure these are the same in sending and receiving script!
string MsgPrefix = "OccLight";

// This is the color of the button when switched off. A nice light green
vector ColorFree = <0.42, 1, 0.71>;

// This is the color of the button when switched off. A noticable red
vector ColorOccupied = <1, 0.39, 0.39>;


// End of Editable Variables



// Nothing much to do here. Just move to State Free for consistency
default
{
state_entry()
{
state Free;
}
}


// State Occupied. Switch turns red, and a message is sent out. On click, state changes to Free.
state Occupied
{
state_entry()
{
llSetColor(ColorOccupied, ALL_SIDES);
llRegionSay(ChanNum, (MsgPrefix + "t"));
}

touch_start(integer num_detected)
{
// This part makes sure the rest of the touch event is *only* handled if the
// person touching the switch is either the owner, or has the group which the switch is set to as his currently active group.
// I have chosen to use llGetOwnerKey(llGetKey()) because llGetOwner does not update without a script reset when the object is changing owners,while this method does see who is the new owner.
if(llDetectedGroup(num_detected - 1) || llDetectedKey(num_detected - 1) == llGetOwnerKey(llGetKey()))
{
state Free;
}
}
}

// State Free. Switch turns green, and a message is sent out. On click, state changes to Occupied.
state Free
{
state_entry()
{
llSetColor(ColorFree, ALL_SIDES);
llRegionSay(ChanNum, (MsgPrefix + "f"));
}

touch_start(integer num_detected)
{
if(llDetectedGroup(num_detected - 1) || llDetectedKey(num_detected - 1) == llGetOwnerKey(llGetKey()))
{
state Occupied;
}
}
}


part 2, the receiving prim
CODE

// Occupation Light script
// An example of how llRegionSay can let an object communicate with another object throughout the sim
// Other interesting examples for the starting coder inside this script:
// - Using states to better control the flow your script
// - Changing the color of a prim
// - A text filter on llListen
// - An alternative method to find the owner of an object
// This is the script for a prim, that listens for a button to tell it what state to turn to and changes it's color accordingly.


// Editable variables

// Make sure these are the same in sending and receiving script!
integer ChanNum = -123456;

// Just an extra prefix to every message, to make sure that different scripts on the same channel don't accidentally mix up.
// Make sure these are the same in sending and receiving script!
string MsgPrefix = "OccLight";

// This is the color of the "light" when switched off. A nice light green
vector ColorFree = <0.42, 1, 0.71>;

// This is the color of the "light" when switched off. A noticable red
vector ColorOccupied = <1, 0.39, 0.39>;


// End of Editable Variables


// Nothing much to do here. Just move to State Free for consistency
default
{
state_entry()
{
state Free;
}
}

// State Occupied. prim turns red, and starts listening for message to switch to the Free state again. On receival, state changes to Free.
state Occupied
{
state_entry()
{
llSetColor(ColorOccupied, ALL_SIDES);
// The last part means that the listen even will ONLY be triggered by messages saying exactly what I put here. As a result, the listen event will rarely be triggered fr this object.
llListen(ChanNum, "", NULL_KEY, (MsgPrefix + "f"));
}

listen( integer channel, string name, key id, string message )
{
// I have chosen to use llGetOwnerKey(llGetKey()) because llGetOwner does not update without a script reset when the object is changing owners,while this method does see who is the new owner.
// What basically happens here is this:
// if the object sending the message does not have the same owner as this object,
// then the message will be ignored. So other residents can NOT hack into your system
// by sending fake messages, should they somehow discover the channel you are using.
if(llGetOwnerKey(id) == llGetOwnerKey(llGetKey()))
{
state Free;
}
}
}

// State Free. light turns green, and start listening for message to switch. On receival, state changes to Occupied.
state Free
{
state_entry()
{
llSetColor(ColorFree, ALL_SIDES);
llListen(ChanNum, "", NULL_KEY, (MsgPrefix + "t"));
}

listen( integer channel, string name, key id, string message )
{
if(llGetOwnerKey(id) == llGetOwnerKey(llGetKey()))
{
state Occupied;
}
}
}


I basically wrote this for a friend who wanted a warning light on the ground she could turn on from her skybox 600 mtrs up in the air, incase she did not want to be disturbed there for whatever reason. So I was very happy with the new llRegionSay option to help do this, and threw in some other small tricks as well.
Lots of code comments, making it nice for new scripters to also find other interesting things to use.
Nada Epoch
The Librarian
Join date: 4 Nov 2002
Posts: 1,423
Original Thread
05-31-2007 09:49
/15/32/186529/1.html
_____________________
i've got nothing. ;)
Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
05-31-2007 13:27
Thanks for pasting here Nada. People are free to drop me a notecard ingame should they want some more help on this thing. And I'm more then happy to see comments about how this could be improved further, for example to reduce lag while keeping the same end result ;)
Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
06-05-2007 05:18
I had a question about the following part:

CODE

touch_start(integer num_detected)
{
if(llDetectedGroup(num_detected - 1) || llDetectedKey(num_detected - 1)


The question was, why would I put "num_detected - 1" in that if statement, instead of just putting 0 there.

num_detected is basically a counter, that tracks how many people clicked and activated this event. This counting starts at 1. However, the seperate people clicking it are assigned a number as well. For every time they click it, another number is actually added to their list. But this numbering starts at 0. So to find the last person in the list, we'd have to call him up by num_detected - 1.

As long as the script stays in the same state, everytime someone clicks it, the last person clicking it will be assigned a new number. So specifically stating the number 0 there would mean, you'd keep requesting information about the first person who clicked, NOT the last one who clicked, no matter how many people click on the thing.

I hope this explained this piece for the people who wonder. It's one of the things I take for granted nowadays, but which gave me a lot of trouble in the past as well. ;)
Ed Gobo
ed44's alt
Join date: 20 Jun 2006
Posts: 220
06-05-2007 05:56
From: Marcush Nemeth
I had a question about the following part:

CODE

touch_start(integer num_detected)
{
if(llDetectedGroup(num_detected - 1) || llDetectedKey(num_detected - 1)


The question was, why would I put "num_detected - 1" in that if statement, instead of just putting 0 there.

num_detected is basically a counter, that tracks how many people clicked and activated this event. This counting starts at 1. However, the seperate people clicking it are assigned a number as well. For every time they click it, another number is actually added to their list. But this numbering starts at 0. So to find the last person in the list, we'd have to call him up by num_detected - 1.

Sounds good, but the touch_start is only in effect while the script is in the state that it is in. So the second toucher would need to touch before the first toucher's touch_start was called (try saying that quickly!). In other words, unless there was a lot of lag, that would only be a fraction of a second and the two touchers would surely see each other. But if two residents raced to do the touching, it would be the last one touching whose touch would be noticed? Should it not be the other way around, or am I missing something?

Anyway, have you ever had to deal with a touch_start count greater than 1?
Marcush Nemeth
Registered User
Join date: 3 Apr 2007
Posts: 402
06-06-2007 01:23
Only on the cases where the state didnĀ“t change, because resident #1 was denied access.