Particles targeting avie attachments

I am very much still in the design phase of my newest project, and before I got too deep into things I wanted to toss a question into the Forum to make sure I'm not sending myself down a dead-end road. What I would like to do is this...

Construct a device that emits a particle stream, like a chain for instance, from the device to one of many possible prim attachments an avie is wearing. I know I've seen particles "aimed" at targets but I didn't know if things worked any differently if those targets were being "worn" by an avatar.

Does anyone see any issues with what I would like to try to do?

Thanking you in advance for not letting me go astray...

Bartiloux Desmoulins
Bartiloux's Den of Sadistic Madness

Nope, you can do that easily enough. I have just recently been working on a project myself that involved that very thing as one of the parts of it.

It has a particle system that generates a ball of particles, then 'lets them go' and makes a nice sort of soft glowing path of light over to the avatar from the one wearing the HUD in question.

I also know a person that makes clothes / accessories, and has a few items that if you were the bracelets or anklets... they produce chains that lead to other objects or people... yet another example of particles moving to other avatars or objects from attached items.

You should be all set to go with your endeavor, just plan out everything you want to do first... it will make your scripting life easier down the road trust me... I'm the worst for jumping in .. doing ok, then finding out I've just really messed up! lol

Take care!
-Hap

Thank you for the feedback. Now I just have to figure out all the parms on the particles. *lol*

Bartiloux

I've got everything all built and working for the most part. The main object does indeed fire particles at the object the sensor detects, but only when the objects/targets are rezzed on the ground. If the single-prim objects are worn as attachments, the sensor can't find them. Any ideas why or what I can do to get around this issue. Finding the attached prims are key to the whole project!

Thank you,
Bartiloux Desmoulins

The target object will have to communicate its UUID key somehow to the particle source.

Then you can send a particle stream to the target.

And that is how such accessories like master/slave stuff works.

Agree with Squirrel. It cannot find the prims on their own because as far as SL is concerned in that instance, they are part of the AV.

You could have the target listen for a message from the emitter and then say it's key when appropriate for the emitter to use that as a target.

So I would change my llSensor to include both the object name AND it's UUID key and then also change the type from PASSIVE to AGENT for this to work? Or would it need to be SCRIPTED instead, since the targets are now "talking?"

This is good stuff! Thanks for the feedback.

Bartiloux Desmoulins

Well it all depends on your application, but I think in this instance you would want to forego the sensor entirely.

How are you activating the particles? Do you just want it to be when someone comes near that is wearing the attachment? or is it something that you want to be able to click on? There are many variations of this that could change what you need to do.

If it's my first example, I would just have the sensor scan for an AV within your target range and then have it broadcast a confirmation/reply message asking for the attachment to identify itself at which point it would respond with its key.

If it's just a click and go, then I would get rid of the sensor altogether and just have it request for the UUID on touch in a message. You could even key this to authenticate by using the llDetectedKey(0) from the touch event in the message to prevent multiple responses, and just input the key it gets in response directly into the target of the particle setup.

But the sensor is the only way to get the target data to pass to the particle script, is it not?

llSay, llWhisper, llRegionSay on predefined channels are easy ways for nearby objects to communicater between each other.

For example:
Lets say you are wearing some cuffs on your wrists and when you get on some BDSM rack, you want particle chains to go from the rack to your wrist cuffs.
The rack, when sat upon could whisper a message (on your predefined channel)
The cuffs would be listening on that channel, and when they hear that, the cuffs would whisper any information they need to send on different reply channel.
The rack (while its sat upon) would be listening on the reply channel, and upon hearing it would check that the owner of the cuffs is the id of the person sitting on it, and if so could send the particle chains to the cuffs.

I dont know if that is how those devices work, but its a simple way of doing it.

... and all that's being transfered is the key (UUID) of the target--which is something the listen() event gets as a parameter. So the whisperer target just has to announce its presence in some agreed-upon way in order for the particle emitter to get the key of its target.

This is all coming very close to reimplementing the LockMeister protocol, or the open source LockGuard scripts. They push the particles in opposite directions of each other*, though, and are complex enough that I wouldn't necessarily recommend starting with either of them as examples.

_________
* That is, as conventionally implemented, LockMeister targets particles from rezzed mooring points to attachments, while LockGuard goes the other direction. (That makes it impossible for conventional LockMeister to target multiple attachments from a single prim, by the way.) Either system can go attachment-to-attachment, though, for whatever that's worth.

for what it's worth, I'm doing the same thing also.

compare ranges,see if you want to use whisper, say, or shout on a private channel, and, if av's don't need to start it off, use a negative channel # on the listen/say.

I've gotten the inter-communicating objects (worn or not) working, and I've gotten an object to 'fire' at another. Hopefully soon I will be merging the two scripts to make it work just right.

"Dwen"

Attachments can't communicate directly with each other using llMessageLinked (my preferred method for finding targets). Or, obviously, with llSensor.

Which pretty much leaves llSay and llListen as your options.

I've left 4 different free/public-domain 'How to Find a Target' examples in The Particle Laboratory, one specifically uses Say/Listen, (and gives an example of how to de-activate the listener if/when it's no longer needed!)

The 'key' thing to remember is that you never want to put asset UUID keys into your script for non-uploadables. They're fine for texture/sound/anim stuff, those keys never change. Prim or Object asset uuid keys DO change... anytime a new copy is rezzed it gets a new key, which will really bork up your script. This is why tricky key acquisition code is necessary for targets.

Anyway, probably all stuff that's obvious to you by now... Good luck with your Project! =)

Wow! You guys and gals are great! What a wealth of information you've provided! To paraphrase Yakov Smirnoff, "Second Life Forums... I love this country!"

Bartiloux Desmoulins