Psys_src_target_key

Hello,

I have created an object with many prim. Some of those prim emit particles that target several other prim identified by their UUID. All is well.

I need to move this entire build to another island so I'll take it into inventory and then rez it in its new home. I am afraid however that all of the target UUIDs are going to change when I do this.

Is this correct? If so, is there a way to move this without having to re-script all of my emitters with the new keys?

Rigt now, the script reads:

key SpermTarget4 = "3eafjgmdlcjl45kmlcmlg-aaldml-345pblahblahblah";

MakeParticles()
{
blah
blah
blah
,PSYS_SRC_TARGET_KEY , SpermTarget4
blah
blah
}

default
{
state_entry()
{
llParticleSystem([]); //Stop making particles
llListen(35,"",NULL_KEY,"";
}

listen(integer channel, string name, key id, string message)
{
if(message == "startParticles"
{
MakeParticles(); //Start making particles
}
else
{
llResetScript();
}
}
}
Is there a better way to code this?

Thanks in advance for any help or insights.

Doug Danforth

I usually do this kind of systm by having the particle emitters detect on rez which prims they should be targetting by prim name (llGetLinkName()), or with scripts in the target prims to communicate their key or link number. That way you can always make copies.

I believe if you ATTACH an object to yourself directly from in-world, then move around (and I think even teleport), then DROP it directly back in-world, it keeps its UUID(s). I strongly recommend testing this first with a new object that will not cause damage if this is wrong, JUST IN CASE.

The UUID issue is correct and I believe thats how some people get around the issues of using key ids as security in update servers.

In terms of particle effects I try to use link numbers as often as possible to ensure that if I do de-rez or copy the object it still behaves properly but I guess the communication method Hewee came up with would work just as well

Thanks Hewee and Django,

Unfortunately, for a number of reasons it's probably not feasible to link these things, so the link number approach won't work. I'll think on this some though.

I'm not sure how to accomplish the suggestion of having the targets communicate their UUID, and how to get the emitters to listen to that and then target appropriately.

Oh, and btw, the SpermTarget4 thing is not what you might think . I'm building a model of the testis for my class and I'm trying to depict the path sperm take in the seminiferous tubule.

Thanks,

Doug

Ok so if things can't be linked you will need to use listens and UUIDs.

Depending on the amount of sim drain you can utilise this can be easy or hard.

The basic idea is this

The target would need a script in it that calls out it's key on a specific channel acting on a timer. I tend to use minus channels as these are only used by objects and high numbers to reduce the likelyhood of crosstalk.

default
{
state_entry()
{
llSetTimerEvent(1);
}

timer()
{
 llSay(-12345,llGetKey());
}
}

This script basically says, every second say the objects UUID on channel -12345. You could use llShout or llWhisper or even llRegionSay depending on the range you need it to work over.


The object that emits the sperm ( your testicles as it were ) then needs to listen on the same channel and target the object that sends it's key. This is achieved with some listen functions

the word message can now be used as the target key in your listen event and if all goes well your sperm should be flowing nicely.

I think though that instead of using the MakeParticles() section the whole lump of the particle emitter code needs to be moved into the listen event and you would no longer be using

key SpermTarget4 = "3eafjgmdlcjl45kmlcmlg-aaldml-345pblahblahblah";


I must admit this is all in theory at the moment as I cannot get in world to check. Also as you might notice if you read my other posts I am not the sleekest or most elegent of scripters but mostly get the job done


Oops. Just noticed you are already using a listen. Amazing what fully reading a post does for your understanding.

I think basically you will have no choice but to re-script your objects unless you are only using this one version and can attach each and every object to your person before teleport ing and dropping them where you need them.

I would chalk this one down to experience and do the boring task of trying to re-code. At least then you would have a pair of testicles that would work every time you need them. (Now that's a phrase I didn't expect to say)

Thread /54/22/223162/1.html has an interesting article in this regard. An eye-opener for me anyway & pop it in here for interest value...

Highlights:

Awsom. Good find Debbie!

Not my find, tbh, but certainly interesting & important enough to refer back to the original thread here

There is no need to have the target say its position every second, unless it is a moving target. If you are going to have to recode anyway you could try this.

In the particle emitter script:

list targets;

default
{
	on_rez(integer start_param)
	{
		llListen(-4732689734,"","","");
	}
	listen(integer channel, string name, key id, string message)
	{
		if(message=="target")targets=targets+[id];
	}
}

and in each target:

default
{
	on_rez(integer start_param)
	{
		llSay(-4732689734,"target");
	}
}

Rez the emitter first then the targets in turn, the emitter will build a list of the UUID's of the targets in sequence.

What you do with that list depends on your code, but:

MakeParticles()
{
blah
blah
blah
,PSYS_SRC_TARGET_KEY , llList2Key(targets,4)
blah
blah
}

should do it. If you count from 1 rather, then subtract one for the index.

Snippus Maximus


Thank you Very, Debbie, Django, and Hewee,

I will play around with the code to see what works best. Since I (hopefully) will only have to move this thing once (or maybe twice) I might end up just rezzng the targets, finding their new UUIDs and plugging those into the emitter scripts one potato two potato.

Thanks again for all your help.

Doug

Yep probably easier. Just drop something like this in each object, one at a time:

default {
	state_entry() {
		llOwnerSay((string)llGetKey());
		llRemoveInventory(llGetScriptName());
	}
}