Collisions and linked objects

Hi,
Does anyone how collisions operates with linked objects?

example:
I have a group of objects that operate ok when something collides with them as individual objects, but when I link them (to make it easier to move/reposition) it looks like the collision system defaults to the base object and name.

Is there anyway around this, or is my setup incorrect for getting collisions on linked objects seperately?

ty,
kt

You probably want llPassCollisions. I'm in the middle of documenting its quirks as we speak, so if what's there isn't enough as it is, there should shortly be a table explaining what will happen under which circumstances. Linking is kind of a pain in the ass, to be honest.

I'd avoid llPassCollisions, unless you just want a generic "[something collided with] this linked set [collided with something]"

Make two objects (unique names to help denote which is doing what), put a script in each with a collision() event.

Link them. Collide with one, collide with the other. Both respond separately.

Toss llPassCollisions(TRUE); into the parent prim's script (state_entry()).

Now colliding with the child triggers both the child's script's collision() and the Parent's collision().

So, assuming you have a linked set with "traps" to spring when someone walks on them: main script is in the parent, but you want to know when someone hits steptrap0, steptrap1, steptrap2, which are children.

Put a collision() event in each child, then use llMessageLink() to tell the parent a specific child was hit (llPassCollisions() doesn't pass this info, a shame really).

Child script:

integer nLinkNum;
string sLinkName;

default
{
	state_entry()
	{
		nLinkNum = llGetLinkNumber();
		sLinkName = llGetLinkName(nLinkNum);
	}
	collision(integer num)
	{
		llMessageLinked(1,nLinkNum, sLinkName, NULL_KEY);
	}
}

Parent Script:

default
{
	state_entry()
	{
	}
	link_message(integer sender, integer num, string str, key id)
	{
		if (num == 2)
		{
			llOwnerSay("Something collided with \""+sLinkName+"\"!");
		}
	}
}

Easy to know that a specific link was collided with (or collided with something).
You might use llMinEventDelay() in the children to avoid massive spam, and/or a "bool"/timer routine to avoid spamming the main script (as collision() occurs very rapidly).

--Bos

Are you sure about this? I recently had a project that used llPassCollisions that worked fine in this respect. Why wouldn't this script do the same thing as yours do?

In the parent:

default {
    state_entry() {
        llPassCollisions(TRUE);
    }
    collision_start(integer totalNum) {
        integer i;
        for (i = 0; i < totalNum; ++i) {
            integer linkNum = llDetectedLinkNumber(i);
            if (linkNum == 2) {
                llOwnerSay("Something collided with \"" + llGetLinkName(linkNum) + "\"!");
            }
        }
    }
}

==A sorta confused Chris

ty

Does llPassCollisions() return collisions in link order? I know the Parent is the first object to respond to a collision event, even when it's the child that was collided with. If so then yeah you're method's as solid as mine (mine point being knowing which object in the link set was collided with).

Hrm actually I dunno about your method, I'd have to test. But, assuming a child is collided with, the parent fires off the collision() event, num==1, 1 is the parent link num.

Same if there's 500 objects in the set, bump #500 and the parent still is going to see only 1 collision num, no? Blah, now I'll have to go test cuz I'm curious. :)

--Bos

Uh, folks... has no one ever heard of llDetectedLinkNumber()?

Try this. Create a link set with, say, 5 prims, spaced out so you can collide with them all and linked together. Put this in the parent prim:

default {
    collision_start (integer num_detected) {
        llSay(0,"Collision with prim #" + (string)llDetectedLinkNumber(0));
    }
}

When you collide with each prim, you should see which prim number you hit. llDetectedLinkNumber() works for touch events, too.

cool, that works!

Unfortunately I can't use a linked solution, as the objects need to be close together (ie: not overlapped but seam to seam) and I've found the bounding boxes/spheres overlap leading to multiple object hits.

Ah well...I guess we don't have a way around this?

np, thanks for the help everyone.

Yup, make invisible objects that are 0.1m smaller to account for the physics overlap, then link them to bigger, visible objects that occupy the space you see now. As long as your visible objects each have a collision_start event with nothing in them, only the smaller ones will do anything.

(And yes, sorry, it's collision_start events without anything in them that you wanted, not llPassCollisions. I figured that out eventually.)

Wonderfully condescending. Great job, especially considering these people are offering their assistance.

No. I was actually asking if anyone's ever heard of llDetectedLinkNumber(), because I know I'd gone a long time before learning that trick. It was an honest question.

Damn learn something new every day. How new is that function? New to me! If it's been around since beta I'm gonna kick myself in the ass repeatidly, dunno how I'd have ever missed that.

Doh and I'm a double idiot, Chris used it in his example, I didn't even notice. That's what I get for skimming posts.

Eek, if you're a double idiot, that makes me a triple idiot for not noticing it as well. D'oh.

Except... now it seems that....

default {
    state_entry() {
        llVolumeDetect(TRUE);
    }
    
    //
    collision_start(integer number) {
        llOwnerSay("link " + (string)llDetectedLinkNumber(0));
    }
}

...consistently returns "link 0" which ever prim you hit.

I would check that this still works, Chris. It doesn't for me (yes, even with the forgotten llVolumeDetect.. )

I really hate to revive an old thread, but is this busted now? I mean, I can't for the life of me get a VolumeDetect() child prim to even acknowledge being collided with. It seems there's no longer any way to have a a VolumeDetect() prim detect a collision within a linked set. Am I wrong?

Here's the goal.. three linked prims... 1 and 2 are targets, 3 is the processor and they are all linked. Make 3 recognize the unique collisions of 1 and 2. Possible?