[BEHAVIOR] Chipmunk Physics

here's an exmaple: http://1drv.ms/1YvddfG

Seems like setting the angle before joining will mess it up. Any way to get around this?

Prominent

I do not understand what is happening here.

If in the editor

sprite2.angle = 95

sprite3.angle = 240

And you make an event like:

Start of layout

--- create gear joint with phase = sprite3.angle-sprite2.angle

Then sometimes the objects will rotate 360 before settling.

However if you set the angles with events then it's perfect.

Start of layout

--- sprite2: set angle to 95

--- sprite3: set angle to 240

--- create gear joint with phase = sprite3.angle-sprite2.angle

or you even can do this:

--- sprite2: set angle to self.angle

--- sprite3: set angle to self.angle

--- create gear joint with phase = sprite3.angle-sprite2.angle

EDIT:

Ah, I see what the issue is. Internally in C2 angles can be any value. When you access them however, they are always returned in the range [0,360). So it would be a fix from my end. Till I do that the above solution will work.

R0J0hound , Hm.. seems like that won't fix it in a specific project I have where I'm creating multiple joints on multiple objects (some of which may have more than one gear or pivot).. I try to set all their angles to self.angle, which helps sometimes, but other times they spin like crazy.

At the moment, I'm just resorting to using two pivot joints to join objects without the gear joints, since the gear joints appear to be unusable in my case. If you get around to fixing that, I can try reverting to the gear joints to see if the problem still persists,

hi rojo, i'm getting this error, it's erratic so sometimes I get it, refresh (changing nothing at all) and then it works fine. (happens about once every 10 times)

Javascript error!Uncaught TypeError: Cannot read property 'x' of nullhttp://localhost:50000/rojoChipmunkBeta_behavior.js, line 5173 (col 25)This may be a bug in Construct 2 or a third party plugin or behavior - please report it to the developer following the bug report guidelines. Subsequent errors will be logged to the console.

keepee

Do you have a capx that reproduces it? That line is run when applying forces, but it works here.

Hello,

I'm new at construct 2.

I have installed chipmunk and I intend to use it for a small racing game.

First, I notice that when used with the car behaviour, it's not working well.

So, I assume that I have to rewrite the car behaviour if I want to use chipmunk (same for physics behaviour).

Also, I am wondering if chipmunk is OK with 3d isometric graphics.

And if yes, how to do the transposition?

I mean, is there a way to manually handle the collisions?

Because in 3d iso, objects might be displayed "behind" and not colliding.

Ouais

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!