# [BEHAVIOR] Chipmunk Physics

Post your completed addons to share with the community

### » Fri Feb 05, 2016 5:36 am

is the math for discerning rate of movement while using polar force, is that y move to distance calculated at

1/10 of distance per 10/100 milliseconds < distance?
or
(distance * 0.1) * 10 < distance
that is until it meets the distance intended to travel, still carrying residual momentum to calculate towards this point, or perhaps I am looking at this wrong and they are indeed traveling at a set rate of pixels per whatever and it calculates it differently than what I perceive.
B
5
S
1
Posts: 68
Reputation: 515

### » Fri Feb 05, 2016 8:22 am

@Itenimum1
It probably should say magnitude instead of distance. When using a polar force it's just how strong the force is. It does not equate to the number of pixels moved.
B
100
S
38
G
134
Posts: 5,556
Reputation: 85,325

### » Mon Feb 08, 2016 8:53 pm

is there a neat way to get the UID of the other object within a 'for each collision pair' loop?

so kinda like .ContactOtherObj

.CollisionOtherObj does not work because:

1. Box comes into contact with Ground, so Box.CollisionOtherObj becomes the Ground.UID
2. Ball hits Box, so Box.CollisionOtherObj now changes to Ball.UID
3. The Box remained in contact with ground

So now, even though the Box is still in contact with Ground, and we can get other data about the contact with Ground, we can no longer get the Ground.UID. Or at least it doesn't seem like it?

thanks!

btw sorry for not getting back to you about that error message a while ago, it just stopped happening completely shortly after I posted and I have no idea ¯\_(ツ)_/¯

edit: also shouldn't "For each Collision pair" really be "For each Contact pair" ? or am I misunderstanding how it works.. it seems to run when things are in contact rather than just on collisions
B
28
S
8
G
1
Posts: 469
Reputation: 4,683

### » Mon Feb 08, 2016 11:22 pm

@keepee
That shouldn't be an issue with different object types. The object used with the for each collision pair is always the first object. So it just loops over collisions with that object type.

No, it's collision pairs. aka two objects colliding. Each collision in turn can have multiple contacts.

This is a example:
behavior-wip-chipmunk-physics_p868715?#p868715
B
100
S
38
G
134
Posts: 5,556
Reputation: 85,325

### » Tue Feb 09, 2016 3:02 pm

>The object used with the for each collision pair is always the first object. So it just loops over collisions with that object type.

i'm really confused by this sentence, it sounds like you're saying that on every iteration of the For each collision pair loop, that the CollisionOtherObj is always the same, first object? but i know that isn't true..

I made a tiny capx with my problem, it's a little different to what i originally said because I used ball/box for ease of explanation, but really it's multiple of the same type of object so maybe that's relevant?

I made it so For each Ball, For each collision pair, lower the opacity of the CollisionOtherObj. The behaviour I expected (and need) was for everything that is touching the ball to get lower opacity, and this seems to work until two balls touch (lol), then the one that stayed in contact with the ground somehow seems to be only be picking itself in it's CollisionOtherObj, or does it remain in the other balls CollisionOtherObj?

If this isn't a bug and i'm just misunderstanding, then how would I go about achieving what I described, where the ground below the ball remains low opac even when the ball collides with another on top of it

https://www.dropbox.com/s/3w1ibhpakix8l ... capx?raw=1

Here's a vid of what I described

https://dl.dropboxusercontent.com/u/533 ... oblem.webm

thanks!
B
28
S
8
G
1
Posts: 469
Reputation: 4,683

### » Tue Feb 09, 2016 5:10 pm

The ball staying transparent is odd, probably an issue with the physics library itself or maybe a typo on my part. You can fix it by adding a system compare: Ball.Chip.CollisionOtherObj != Ball.UID, so I guess the object is colliding with itself?
B
100
S
38
G
134
Posts: 5,556
Reputation: 85,325

### » Tue Feb 09, 2016 6:28 pm

Yea, I tested it a bit more and found that all of the objects' other collisions get replaced by itself:

https://dl.dropboxusercontent.com/u/533 ... bjBug.webm

https://www.dropbox.com/s/lp6i6sm0027vw ... capx?raw=1

Filtering out with CollisionOtherObj != Ball.uid is a good idea for the ball itself but my real problem is how it loses collision with the ground
B
28
S
8
G
1
Posts: 469
Reputation: 4,683

### » Tue Feb 09, 2016 7:05 pm

@keepee
Ok, I see what the issue was. Re-download on first post. The other object will never be the same object now.

In your example if two balls are stacked only one will get an opacity of 50, so you need an action to set the ball's opacity as well.
B
100
S
38
G
134
Posts: 5,556
Reputation: 85,325

### » Tue Feb 09, 2016 7:43 pm

The reason why only one gets opacity reduced is because one of the balls still has itself in CollisionOtherObject.

I changed the cap so both balls get lifted away from the ground and made the text display the first number is Ball.UID then the next numbers are CollisionOtherObject
So here, 12 and 13 are colliding, but they both have 13 as their CollisionOtherObject

https://dl.dropboxusercontent.com/u/533 ... jBug2.webm

https://www.dropbox.com/s/qkbi7a4amw3ap ... capx?raw=1
B
28
S
8
G
1
Posts: 469
Reputation: 4,683

### » Tue Feb 09, 2016 8:15 pm

@keepee
Thanks for the capx. Fixed now. Re-download in first post.
B
100
S
38
G
134
Posts: 5,556
Reputation: 85,325

PreviousNext