Particle Emitter targetting a PEICE of another attachment

I have a pretty cool idea, but cant find enough documentation even on the Wiki to know how to do this.

I need to make a "Cord" that goes from one part of an attachment to another piece of another attachment.

It would be like this...

I need a "cord" that goes from an extrusion on the back of a leg, and it needs to target a peice on my hip object, a piece sticking out to the side.

How would I target it or fake it if I *must*?

OK, I'm working from a grand total of two personal experiments here, but I think you'll need to glue on a tiny transparent sphere at the target point...even right beneath the surface, if your object shape supports it. Then, you'll need to use that prim's UUID as the target key.

Otherwise, I think your particles are going to head for the center of the target prim.

I'll be curious to see what more experienced folks will suggest, but I'd suggest having the target object ping the particle source by repeating its UUID once every second or two on a private channel after a rez or attach event.

Once the particle source has rezzed or attached and received the new key, it can chat a message to shut down the target attachment's chat and listener and start the particle engine.

That would be nice. I'd like to make a 'cord' from a pair of ibuds to an iPod held in the av's hand. The AV would have an all-black appearance be surrounded by random color-changing bubble.

That would be wickedly cliche.

if you figure it out, let me know.

Also, how do I make a particle just point to a person?

I've done this. Basically, you do what Nonce said; you put a script in the prim you want to target, and then you have to decide on some protocol by which the particle source gets that prim's key. In my case, I think I had the particle source start in a "lost my target" state, and had it announce every few seconds that it was looking for its target. The target would always be listening for that, and whisper its UUID when it heard it, and also when it was attached for good measure. The script in the source would switch to the "run" state when it got the target's UUID, and start the particle system there. If it was detached, it would switch back to the "lost my target" state, because next time, the target's UUID would probably be different. It's tricky, but it can be done.

This may be handled automagically by the state change engine, I cannot recall, but make sure that one way or the other, after the bits have found their particle targets, ya shut down the listen handler. Lag is stanky.