[BEHAVIOR] Chipmunk Physics

Hey ouais25 hi.

Welcome to construct 2 community.

The best way to use the chipmunk and generally behaviors that involves physics is to use it alone ,dont mess physics behaviors with other behaviors (car behavior) because they will act strange (by the way you can easily create a car movement through chipmunk).

About the physics collision now and the 3d iso thing , well i think IMO chipmunk can handle physics collisions, joints and other stuff better than the build-in physics behavior (and of course has ,collision group-layer and the amazing Collision info). A tip about the iso collision is to make invisible objects with the chipmunk behavior to handle the collisions.

Thanks saour,

My assumption was correct and I will go with chipmunk and recreate a car behaviour.

It's a bit a pity that the behaviours are not compatible with each others (I struggled lately with the direction behaviours as they don't behave the same actually, i.e. with the management of the angle).

For the iso 3D, your tip is indeed interesting. Probably the way to go.

I am making a first little game in iso 3D for my kid and the design in ISO 3D is very time-consuming and constraining (i.e. if going for multiple part sprites with damage management), I'll probably go 2D from above for the more complex game I intend to do afterwards.

Ouais

I'm trying to build a simple ragdoll with this, but I am unsure how to use the joints? Like, what goes in the UID section, are the first set of parameters discussing the x and Y of a select point to offset the first object to? or FROM?

and the second set are they discussing the UID object you put in the parameter? if created a ragdoll or an object with parts (like a pulley) should I only connect objects FROM something or can I get the parts to connect to a master object by a reference and which field uses what?

I am sorry for the questions, I'm jsut a bit confused and not gettingthe results id like. Maybe I'm just too stupid. (happens)

Itenimum1

The uid tells what other object to connect to. I could have used an object type instead, but using a uid instead makes stuff like connecting to other instances simpler. As an example if you want to add a joint to Sprite1 to connect to Sprite2 you would use Sprite2.uid.

For the xy's they define where on the objects the joint is connected.

"rect" and "polar" are offsets from the object, but it's also relative to the object's angle. So for example if you used "rect" with x=32, y=0 and the object had a angle of 90 then the object would be connected 32 pixels below the object's center.

"imagepoint" should be self explanatory.

"layout" is a layout position, which in turn is used to calculate an offset. It's probably simpler to wrap one's head around than "rect" and "polar", since it's not relative to angle.

Depending on the joint there usually are two anchor points, one for each object. The only exception would be "add anchor joint at XY", but since ever field has a description so it should be understandable.

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.

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.

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

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:

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!

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?

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

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.

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

keepee

Thanks for the capx. Fixed now. Re-download in first post.

Awesome! it all seems to be workin great now.. thanks man, you are legendary