Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

target linked prim
Talthybius Brevity
Headshop Proprietor
Join date: 14 Nov 2006
Posts: 76
12-02-2006 23:54
Hi,

Below is a comment from one of Jopsy's templates.

After much searching in this forum and in the LSLwiki I'm still unable to make this happen.

I'm quite the newb (3 weeks) and so I'm still in a stage where I'm really needing to see examples to grasp stuff.

If someone could post an example of how to do what is suggested in the bolded text below (particularly the part about grabbing the key with the listen event handler) I'd very much appreciate it.

From: someone
// TARGET: Select a target for particles to arrive at when they die
// key TARGET = llGetKey(); // particles return to the emitter
// key TARGET = llGetOwner(); // particles home in on owner
// You can have another object llSay(999,llGetKey);
// and grab the key with this object by using the listen()
// event handler.


also how to limit the listening to waste as few resources/induce as little lag as possible would be groovy.

Thanks
Eloise Pasteur
Curious Individual
Join date: 14 Jul 2004
Posts: 1,952
12-03-2006 02:27
OK, low resource is a problem, because you'll need an open listen. You're also going to need 2 scripts, one for each object.

The target object can say, for example, "shoot me" using llSay(999, "shoot me";); or llSay(999, llGetKey()); or similar. The former is slightly lower in sim resources, but it's negligable.

The particle emitter needs several bits of code.

First, somewhere like the state_entry() event it will need llListen(999, "", "", "shoot me";); or llListen(999, "", "", "";); for the second version.

Then, the listen event.
CODE

listen(integer channel, string name, key id, string message)
{
    target=id;   //assuming target is the variable name in your particle system
    particles(); //assuming particles is the function call to restart the particles
}


OK, there's two bits there:

id is the key of the object (or avatar) that said the message that triggers the listen. That's why you can use a fixed message, which helps limit the false positive triggers.

Particles are set up by the llParticleSystem() call, and then remain passive, doing the same thing all the time, until the particle system is called again. Sometimes it can appear this is *not* the case, particles can do different movement things, like following a target, blowing in the wind etc. However, without changing the system you can't change the target, can't toggle following the wind on or off, so the system remains identical even if your computer draws the particles moving around differently as things change in world.

Also please note that updating the particle system causes a full prim update (particles actually become a property of the prime, you can take the script out if you never want to update the system, the particles remain) so whilst updating every now and again in response to a message isn't likely to be that bad, ripple firing updates on fast timers, or rapidly shifting targets adds a fair bit of load to the system.
_____________________
Eloise's MiniMall
Visit Eloise's Minimall
New, smaller footprint, same great materials.

Check out the new blog
Talthybius Brevity
Headshop Proprietor
Join date: 14 Nov 2006
Posts: 76
12-03-2006 02:35
From: Eloise Pasteur
OK, low resource is a problem, because you'll need an open listen. You're also going to need 2 scripts, one for each object.

The target object can say, for example, "shoot me" using llSay(999, "shoot me";); or llSay(999, llGetKey()); or similar. The former is slightly lower in sim resources, but it's negligable.

The particle emitter needs several bits of code.

First, somewhere like the state_entry() event it will need llListen(999, "", "", "shoot me";); or llListen(999, "", "", "";); for the second version.

Then, the listen event.
CODE

listen(integer channel, string name, key id, string message)
{
    target=id;   //assuming target is the variable name in your particle system
    particles(); //assuming particles is the function call to restart the particles
}


OK, there's two bits there:

id is the key of the object (or avatar) that said the message that triggers the listen. That's why you can use a fixed message, which helps limit the false positive triggers.

Particles are set up by the llParticleSystem() call, and then remain passive, doing the same thing all the time, until the particle system is called again. Sometimes it can appear this is *not* the case, particles can do different movement things, like following a target, blowing in the wind etc. However, without changing the system you can't change the target, can't toggle following the wind on or off, so the system remains identical even if your computer draws the particles moving around differently as things change in world.

Also please note that updating the particle system causes a full prim update (particles actually become a property of the prime, you can take the script out if you never want to update the system, the particles remain) so whilst updating every now and again in response to a message isn't likely to be that bad, ripple firing updates on fast timers, or rapidly shifting targets adds a fair bit of load to the system.

wow! thanks eloise!