There are 2 reasons this does not work:
BoundingBox on the body is not updated to all the attached sprites.
If if it is this way, it would not work, because boundingBox returns a rect. Thus it would crash in "caves" where it should not.

2 simple solutions:
Loop through each sprite and check for intersects after movement, but this would be n^2, so could grow slow.
Faster is a two-dimensional BOOL array. You just store the occupied fields and when a snake moves you check if the target is already occupied.

im making a little more advanced snake game, and im making the worms body by adding CCSprites at the heads position eatch 0,02 sec.

that works fine but when i try to add collision detection between the first worms body and the second worms body it wont work.

it only works when the last "spawned" body parts are colliding.

im using CGRectIntersectsRect([body1 boundingBox], [body2 boundingBox])

Maybe I'm not getting this right. but in your correction you have

float ret = RayIntersectionTriangle(position,direction,pos1,pos2,pos3,&success);

return ret;

Shouldn't it be

if(success)return ret;

?

Otherwise it would exit on the first iteration.

Sry: There was an failure, this is the correct way:

-(float)intersectMeshNode:(CC3MeshNode*)node:(CC3Vector)position:(CC3Vector)direction
{
    bool success;

    CC3VertexLocations* vertices = ((CC3VertexArrayMeshModel*)node.meshModel).vertexLocations;

    for(int i=0; i<vertices.elementCount; i=i+3)
    {
        CC3Vector pos1 = (CC3Vector)([node vertexLocationAt:i]);
        pos1 = CC3VectorScale(pos1,node.scale);
        CC3Vector pos2 = (CC3Vector)([node vertexLocationAt:i+1]);
        pos2 = CC3VectorScale(pos2,node.scale);
        CC3Vector pos3 = (CC3Vector)([node vertexLocationAt:i+2]);
        pos3 = CC3VectorScale(pos3,node.scale);

        float ret = RayIntersectionTriangle(position,direction,pos1,pos2,pos3,&success);

        return ret;
    }

    return 0;
}

And the RayIntersectionTriangle-Function:

float RayIntersectionTriangle(CC3Vector p,
                                   CC3Vector d,
                                   CC3Vector v0,
                                   CC3Vector v1,
                                   CC3Vector v2,
                                   bool* success)
{
    float a,f,u,v,t;
    CC3Vector e1 = CC3VectorDifference(v1,v0);
    CC3Vector e2 = CC3VectorDifference(v2,v0);

    CC3Vector h = CC3VectorCross(d,e2);
    a = CC3VectorDot(e1,h);

    if (a > -0.00001 && a < 0.00001)
    {
        *success = NO;
        return 0;
    }

    f = 1/a;
    CC3Vector s = CC3VectorDifference(p,v0);
    u = f * (CC3VectorDot(s,h));

    if (u < 0.0 || u > 1.0)
    {
        *success = NO;
        return 0;
    }

    CC3Vector q = CC3VectorCross(s,e1);
    v = f * (CC3VectorDot(d,q));

    if (v < 0.0 || u + v > 1.0)
    {
        *success = NO;
        return 0;
    }

    t = f * (CC3VectorDot(e2,q));

    *success = YES;
    return t;
}

Have fun!

Notice: position and direction of the ray are relative to the meshnode's, not to the world's coordinate system. But you could apply the meshnode's position and rotation to the Vectors pos1, pos2 and pos3.

-(CC3Vector4)intersectMeshNode:(CC3MeshNode*)node:(CC3Vector)position:(CC3Vector)direction
{
    bool success;

    CC3VertexLocations* vertices = ((CC3VertexArrayMeshModel*)node.meshModel).vertexLocations;

    for(int i=0; i<vertices.elementCount; i=i+3)
    {
        CC3Vector pos1 = (CC3Vector)([node vertexLocationAt:i]);
        pos1 = CC3VectorScale(pos1,node.scale);
        CC3Vector pos2 = (CC3Vector)([node vertexLocationAt:i+1]);
        pos2 = CC3VectorScale(pos2,node.scale);
        CC3Vector pos3 = (CC3Vector)([node vertexLocationAt:i+2]);
        pos3 = CC3VectorScale(pos3,node.scale);

        CC3Vector4 ret = RayIntersectionTriangle(position,direction,pos1,pos2,pos3,&success);

        if(success)return ret;
    }

    return CC3Vector4Make(0,0,0,0);
}

And the RayIntersectionTriangle-Function:

CC3Vector4 RayIntersectionTriangle(CC3Vector p,
                                   CC3Vector d,
                                   CC3Vector v0,
                                   CC3Vector v1,
                                   CC3Vector v2,
                                   bool* success)
{
    float a,f,u,v,t;
    CC3Vector e1 = CC3VectorDifference(v1,v0);
    CC3Vector e2 = CC3VectorDifference(v2,v0);

    CC3Vector h = CC3VectorCross(d,e2);
    a = CC3VectorDot(e1,h);

    if (a > -0.00001 && a < 0.00001)
    {
        *success = NO;
        return CC3Vector4Make(0,0,0,0);
    }

    f = 1/a;
    CC3Vector s = CC3VectorDifference(p,v0);
    u = f * (CC3VectorDot(s,h));

    if (u < 0.0 || u > 1.0)
    {
        *success = NO;
        return CC3Vector4Make(0,0,0,0);
    }

    CC3Vector q = CC3VectorCross(s,e1);
    v = f * (CC3VectorDot(d,q));

    if (v < 0.0 || u + v > 1.0)
    {
        *success = NO;
        return CC3Vector4Make(0,0,0,0);
    }

    t = f * (CC3VectorDot(e2,q));

    *success = YES;
    return CC3Vector4Make(t,u,v,0);
}

Have fun!

-----

Edit: It is important to use a non-sorted triangle-list in the COLLADA->POD-Exporter:

Primitive Type = "Triangle list" (disable "Indexed")
Triangle Sort = "None" (disable "Sort vertices")

That's why:

1. Face = Vertices{0,1,2}
2. Face = Vertices{3,4,5}
3. Face = Vertices{6,7,8}
...

Oh? Cool! Love to see the code :)

It IS possible. I did it! When I have some spare time maybe I will post the Ray-VS-Object-Collision code in a better condition than I use it ;)

The only current way to do this is to use a physics engine, which also isn't directly supported, but manageable with some research, also my wrapper may help. We (by we I mean Bill and I was going to help then life got hectic) want to include physics support but we want it to be interchangeable so you can use whichever engine you'd like as long as someone writes a "plugin" for it that would give cocos some info that it can use to sync itself with the physics engine as well as command it through objective c commands that feel like cocos.

Gray

@catdsnny

Code for accessing faces will be included in the next release, which will be out by the end of January.

...Bill

Definitely need a way to get to the poly list to implement any kind of collision detection.

I haven't tried it, but this post uses CGPath to calculate hits on moving, non rectangular objects, which I'd think would be easy to use for collision detection:

http://bobueland.com/cocos2d/?p=134

how to check intersection of two sprites(other than rectangles) in cocos2d

You can use Box2D to define the bodies of all your sprites. To detect touch and drag towards each sprites' bodies, you may want to look for mouse joint in Box2D as well. If I am not mistaken, in Box2D's TestBed, you can see the example for using mouse joint.

In my iphone app i need to be able to detect tiuches to drag around different sprites/b2bodys (im not sure which one to use for collision detection), at the moment when i drag them around they all stack on top of each other and im not sure how to detect individual sprites/b2bodys , any help is appreciated, thanks :D

roko, I had the same problem because I wanted to detect not only the clicked menu items but also swipes with origin on that items (via ccTouchesMoved:).
To be able to detect the touch events:

• ccTouchesBegan:
• ccTouchesMoved:
• ccTouchesEnded:

I had to extend CCMenu and override registerWithTouchDispatcher: since it was "swalling" all events!
Here you have the code:

// Configures menu to keep trowing touch events BUT not swallow them.
  -(void) registerWithTouchDispatcher
  {
  	[[CCTouchDispatcher sharedDispatcher] addTargetedDelegate:self priority:kCCMenuTouchPriority swallowsTouches:NO];
  }

I've started by just changing "swallowsTouches:YES" to "swallowsTouches:NO" in the "CCMenu.m" source code, but I recommend you to do not change the Cocos2d sources, since that can generate other side effects if you have other menus.

Wow... the guy really tells well on the theory of touch.
After watching the tutorial you showed me, I could understand clearly on the concept of touch!
I was having hard time understanding it for months!
Thanks abitofcode!

I started typing out a response but remembered Bob does a nice job of explaining touches in his screencast;

http://bobueland.com/cocos2d/?p=123

Once you've watched this one you'll probably want to go onto the nodespace one.

Thanks

touches is an array. anyObject returns an object from that array, any of them. you could replace that with objectAtIndex:0 or something else but it will not properly behave. It refers to the touch object in the touches array, not to the object on screen being touched.

KEventHandled is probably YES.

Hello people!
I'm here to ask questions about touch detection.
Generally, there is this code in every touch code:
UITouch* touch = [touches anyObject];

Without making it anyObject, how can I make a touch detection to a certain location or an object?
Also, what is KEventHandled?
Thanks!

hi skyhawk,

i am using sqlboy's A* : http://www.cocos2d-iphone.org/forum/topic/19463

i found the isCollision method and adding my conditions there. thank for the input. :)

Look at the lookup function for the A* algorithm you're using. Determine where it figures out a node is unpassable... ( I use a function called "IsMoveValid") then modify it to be NO for where your enemies are.

If enemies can move during the course of the pathfinding, then the pathfinder will have to be recalculated anytime an enemy enters the path.

hi again,

the collideLayers are all set in the tile map like:

[_pathFinder addCollideLayer:@"Collide"];
   [_pathFinder setCollideKey:@"Collide"];
   [_pathFinder setCollideValue:@"True"];

but how do i add a sprite (e.g. enemySprite) to the list so that the pathfinder detects the sprite as a collision and avoids it also?
Right now if i have my enemySprite in between the source point and destination point, the A*star just goes through it, i want the algorithm to avoid the sprite if it is blocking the way.

thanks for the help.

so i did the breakpoints and it turned out that the method that i added that highlights the 3 tile node radius around the sprite was the culprit. this method was still using the A*algorithm to show where the sprite can go. the problem was the way i coded it, my array was checking every tile on the map, i rewrote it to just check a 3 tile radius and now its much quicker. thanks for the help everyone.:)

I will try it tonight and give feedback thanks

Put breakpoint before calculation, and after calculation. If that's not taking "1-1.5 seconds", that's not the problem that is causing delay in your sprite moving.

If it is the calculations, follow the advice laid out here: http://www.cocos2d-iphone.org/forum/topic/20973#post-116544

Hi i probably don't know but what instruments in the simulator can I use to test this? I ran it both on the simulator and the iPhone 4. The simulator performs a bit faster than the phone. Thanks

It sounds like it's not the algorithm specifically, but this link has a ton of different ways to optimize or change the way you're using the A* algorithm.

Have you sampled this in instruments on the simulator? That could help a lot as well.

Hi, no drop on fps it shows 60fps on the device. No scheduler either, it's just a straight method that calcs the path from source to destination. I want to post a video of it, is there a way to do a video capture of the iPhone? Thanks

You don't see an fps hit on device? Are you calling your a* through a scheduled method by chance? That is quite drastic for a 150 tile tilemap. There must be a hang up in your code somewhere.