Killing a rezzed object - Need help
|
|
Ceera Murakami
Texture Artist / Builder
Join date: 9 Sep 2005
Posts: 7,750
|
12-15-2006 18:43
I need some help in scripting a two part object. It's a torch, with a flame that rezzes over the head of the torch.
When I touch part "A" (the torch itself), it should rez one copy of part "B" (the flame) above part "A". And if I touch part "B", it issues an llDie command on itself, and eliminates the part "B". If the flame is left burning more than one hour, it has a timer in part "B" that issues an llDie to allow it to 'run out of oil' and go out. All that I can do, so far... Touch the torch to light it, touch the flame to snuff it out. (Or use a chat command on a non-zero channel to snuff out all torches in voice range.) It is done as two pieces so that it rezzes the flame upright if the torch is initially at an odd angle, which it could NOT do if the flame was part of the same linkset, and I just tried to toggle visibility and local lighting properties.
BUT... As scripted right now, if I touch part "A" two times or more in a row, it rezzes another copy of part "B" each time "A" is touched. It doesn't know there is already a part "B" there.
What I want to have happen is if a part "B" already exists, spawned by that instance of part "A", then touching part "A" will order part "B" to do an llDie, deleting itself. essentially operating as an on/off touch switch in the base object, toggling the existance of the flame.
So far, the best I have come up with would be that each time part "A" is touched, the torch would first whisper the chat command to extinguish the torch, then rez a new flame. I would still have to touch the flame to extinguish it.
I am somewhat leery of using llWhisper like that though, because if a second one of these torches was within whisper range, I don't want one torch extinguishing or lighting the other. And I don't want an open listen when the torch isn't lit, if that can be avoided.
SO...
Is there some way to ensure that a rezzed object can communicate with the thing that rezzed it, and accept further commands ONLY from the object that rezzed it?
Thanks for your time. Ceera
_____________________
Sorry, LL won't let me tell you where I sell my textures and where I offer my services as a sim builder. Ask me in-world.
|
|
Allan Beltran
Registered User
Join date: 2 Dec 2006
Posts: 52
|
12-15-2006 19:45
In part "A", just place a flag that says it's on...or off... integer flame_on = FALSE; //Flame off when rezzed
default { start_entry() {//Do whatever here if you must }
touch_start(integer total_number) {
if(flame_on) { //Issue llDie to kill flame and reset flag //Not sure what your command is there so //I left that part out. //Important thing is the flag. This can also //be done using states from what I understand //but this is a quicker way IMO flame_on = FALSE; } else { //Rezz flame object in whatever manner you are doing so, //then rest flag flame_on = TRUE; } } } My first suggestion to help out, so be nice.
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
12-15-2006 21:15
What about making parts a and b a linkset and touch part a makes b visible or not? Doing that there would be no channels or listens to worry about. integer on = 0;
default { touch_start(integer num_detected) { if(on == 0){llSetLinkAlpha(LINK_ALL_OTHERS, 1.0, ALL_SIDES);on = 1;} else{llSetLinkAlpha(LINK_ALL_OTHERS, 0.0, ALL_SIDES);on = 0;} } }
THen to adjust the rotation, put this in each of the child prim:
default { changed(integer change) { if(change & CHANGED_COLOR){ if(llGetAlpha(2) == 1.0){ rotation root_rot = llGetRootRotation(); root_rot.s = -root_rot.s; llSetLocalRot(root_rot); } } } }
EDIT: Darn it works but not for what you want probably. Your flame is probably 3 flat prim rotated 45 degrees from wach other and this would make all 3 of them rotate around to the same rotation.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
12-16-2006 03:23
Best way would be to have B say something when it deletes itself, A can then listen out for that to know if B has deleted itself and when it does it can set the 'flame_on' flag to false, so it then knows to rez another next time it is pressed.
Thus, if A is touched when flame_on is true, it tells B to die and sets flame_on to false. If A is touched when flame_on is false it rezzes a new flame and sets flame_on to true. If B dies by itself, A hears it and sets flame_on to false.
My personal preference though is to use a particle system with a cone setting and radius that causes it to originate just above the torch 'head'. Then when you want to turn the flame on/off it's just a case of activating or deactivating the particles, and it requires no extra prims or listens.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
|
Ceera Murakami
Texture Artist / Builder
Join date: 9 Sep 2005
Posts: 7,750
|
12-18-2006 10:27
The flag idea helps a little, but still doesn't give me control over the specific flame for the torch I activated. I tried using llWhisper to extinguish the existing flame prior to a rez of a new flame, and that caused all similar torches within at least 10 M to also extinguish.
Yes, my flame is multiple prim planes, so the rotation adjustment idea will not work.
Making the flame merely toggle visibility only works if the flame is a part of the torch linkset. That loses the ability for the flame to remain upright when the torch is stuck in the ground at an angle. Also, I found that toggling off the visibility of a prim does NOT toggle off the local light that it casts! I'm fighting that issue on another product that I am developing, a touch lamp, where the light bulb needs the full-bright AND Local lighting properties toggled on when lit, and off when not lit. I believe I can do that with llSetPrimParams , or some similar command. Just haven't researched that yet.
The key seems to be that I would need to have the rezzed flame report back to the torch with it's UUID, or some similar unique ID code, so that commands sent by the torch will NOT affect a similar torch two meters away.
I wonder... If the 'rez flame' handler in the torch triggers a timer, allowing for only 5 seconds a listen for the flame saying it's UUID on a fixed command channel; and the flame, on rez, whisper's it's UUID? Then the torch, when touched a second time, can whisper the UUID of the flame on the same command channel, then clear the variable for the flame's UUID, and that will extinguish that flame? It would require an open listen in the flame, but I already have one for the "blow out" command to extinguish the torches en-masse. And I would only need an open listen in the torch for a few seconds after it rezzes a flame.
So... How can the flame, as part of it's on-rez event, get it's own UUID, and whisper that to the torch that just rezzed it?
Hummm...
_____________________
Sorry, LL won't let me tell you where I sell my textures and where I offer my services as a sim builder. Ask me in-world.
|
|
Ged Larsen
thwarted by quaternions
Join date: 4 Dec 2006
Posts: 294
|
12-18-2006 11:31
New scripter and SL'er here, but this should be a simple solution that might work for you. When a torch base it touched, pick a random integer, listenChannel. When the torch base creates the flame via llRezObject, pass the listenChannel random number as the rezzing parameter. The chance of two torch bases choosing the same random can be as low as 1 in 4 billion, so cross-talk shouldn't be a problem. Set up BOTH the torch base and the torch flame to llListen on that random channel. Be sure to also save the listening handle, because you'll want to be able to llListenRemove later. (Actually, LSL wiki suggests you remove the listen channel even before you start your llListen: http://lslwiki.com/lslwiki/wakka.php?wakka=llListenRemove) When the flame runs out of oil, on that random channel, it should say "FLAME OUT", and then llDie itself. The torch should hear that command, and respond by llListenRemove'ing that channel, to conserve listening resources. You might want to have the torch use either a global variable or a "state" to keep track of whether the flame is lit or not. I.e., initially, the torch starts in a "flame off" state. When touched, the torch goes to a "flame on" state, rezzes the flame, and listens on the random channel selected. You could even have the touch handler handle turn OFF the flame, if the torch is touched when in the "flame on" state (by talking to the flame and issuing a command to trigger an llDie). A further benefit is that when you exit the "flame on" state, all active listens are automatically cancelled so that you don't even have to deal with llListenRemove. Sheesh, I'm long-winded. I think the code to do this will be shorter than this post. If I'm totally off-base, remember I'm a newbie scripter and mean well.
|
|
Tiarnalalon Sismondi
Registered User
Join date: 1 Jun 2006
Posts: 402
|
12-18-2006 11:39
It could be part of the linkset if you set it to check the rotation of the linkset before it turns on, and make sure it rotates locally to an upright position.
|
|
Ged Larsen
thwarted by quaternions
Join date: 4 Dec 2006
Posts: 294
|
12-18-2006 12:10
Tested this in-world, and I think it does what you want. Clicking on the torch base repeatedly toggles the flame on and off. If the flame is on for enough time, the oil runs out, and the flame tells the torch base that it's about to die (so that the listen can be removed, and so that the next click will generate a new flame), and then the flame kills itself. Multiple torches in close vicinity do not interfere with one another. Note to self: do not set "self-destruct" timer to be so short that the object keeps on disappearing, before you can edit it. // Torch base script, in response to SL forum question // Ged Larsen, Dec 18, 2006
integer listenHandle; integer listenChannel; integer flameOn;
default {
state_entry() { flameOn = 0; }
touch_start(integer total_number) { if ( flameOn ) { // flame already on, so touching will tell the flame to turn off llShout(listenChannel, "LIGHTS OUT"); // objects can't hear themselves, so this should not trigger listen() llListenRemove(listenHandle); // don't need to listen any more flameOn = 0; } else { // flame not on llListenRemove(listenHandle); // per LSL wiki, OK to remove a handle that's non-existent, just to be sure listenChannel = llFloor(llFrand(100000.0)) + 1000; listenHandle = llListen( listenChannel, "", NULL_KEY, "" ); llRezObject("flameObject", llGetPos()+<0,0,1>, ZERO_VECTOR, ZERO_ROTATION, listenChannel); flameOn = 1; } }
listen(integer iChan, string sName, key kID, string sText) { if ( iChan != listenChannel ) return; // safety net
if ( sText == "OUT OF OIL" ) { llListenRemove(listenHandle); // don't need to listen any more flameOn = 0; } }
} // Torch flame script, in response to SL forum question // Ged Larsen, Dec 18, 2006
integer listenHandle; integer listenChannel;
default { on_rez(integer start_param) { llListenRemove(listenHandle); listenChannel = start_param; listenHandle = llListen(listenChannel, "", NULL_KEY,""); llSetTimerEvent(300); }
listen(integer iChan, string sName, key kID, string sText) { if ( iChan != listenChannel ) return;
if ( sText == "LIGHTS OUT" ) { llDie(); } } timer() { llShout(listenChannel, "OUT OF OIL"); llDie(); } }
If these scripts cause the painful demise of your avatar, inventory, and land, I take no responsibility. On the other hand, if they help you in any way, be aware that my sole source of income at present as a 2-week old SL newbie, still wearing freebie clothes, is by camping, and I'm (usually) not too proud to accept handouts 
|
|
Seifert Surface
Mathematician
Join date: 14 Jun 2005
Posts: 912
|
12-18-2006 13:43
From: Ceera Murakami So... How can the flame, as part of it's on-rez event, get it's own UUID, and whisper that to the torch that just rezzed it? Sounds like you want to look at the object rez event.
_____________________
-Seifert Surface 2G!tGLf 2nLt9cG
|
|
Ceera Murakami
Texture Artist / Builder
Join date: 9 Sep 2005
Posts: 7,750
|
12-22-2006 07:13
Thanks folks. Hopefully I will have some time today or tomorrow to try some of these helpful ideas and suggestions!
_____________________
Sorry, LL won't let me tell you where I sell my textures and where I offer my services as a sim builder. Ask me in-world.
|