[BEHAVIOR] Chipmunk Physics

That would be useful. Should the x and y returned be in layout coordinates or relative to the objects? I'm leaning towards "layout" but relative would be constant.

Layout coordinates would be more intuitive I think. If it is relative to the objects, you might be forced to choose the object and do something like obj.x + joint.x if you need the layout coordinate.

If it is already in layout coordinates, you won't need to pick the object to do that- and if you need a relative position, you'd more likely want to pick the object anyways.

so, yea I think layout coordinates would be better.

edit: I'm wondering if you need to access the joint through the correct object it was added to? Might be limiting if that is the case. Would be good if you can just find any joint regardless of which object is calling the expression.

You need one of the connected objects to get info about a joint. Makes sense since event sheets rely on picking, not to mention that's how chipmunk organizes the joints. I can add expressions to get the anchor point of the current object and the connected object. That would save needing to pick the other object.

ah, I see. I kind of figured that would be the case. Anything that helps not having to pick an object would be great.

***EDIT: updated the capx***

Here's an example that I thought might be interesting - it's a simple grappling hook that uses the slide constraint & raycasting:

[attachment=0:1tspm841][/attachment:1tspm841]

It's a stripped down version of a more complex system I'm working on (with rope wrapping) so there might be some usused variables & it's not commented very well.

Just a quick question: Is Chipmunk only meant to function, if you apply it to objects separately instead of applying it straight to a family?

I tried applying Chipmunk to a family of objects (a ragdoll), in a similar way I used to work with Box2d, but as a result I get black screen. Loading of the layout freezes at 30%. However, if I remove the Chipmunk behavior from the family and apply it separately to all the objects in the family, the layout loads and everything works fine.

EDIT:

I guess it was just some gibberish in the cache, now everything is working fine So one can apply it straight to a family for all the objects in the family inherit Chipmunk =)

I found a reason why it'd be better to use line segments for the tilemap instead of boxes..

So that you don't get stuck on corners of the boxes when collideing with walls.. here's a screenshot showing th eplayer standing on a corner without falling.

[attachment=0:16kt8117][/attachment:16kt8117]

here's an animated gif of the issue.. maybe theres a way to fix it?

[attachment=0:2itv4dpe][/attachment:2itv4dpe]

Update 1.9:

Download in first post.

* Fixed: If a shape or joint was destroyed more than once it would crash.

* Fixed: Expressions would sometimes return undefined if there wasn't any value. Now 0 is returned.

* Added: "set joint properties" action to change joint specific properties after the joint is added. Things like spring stiffness, pin distance, etc ... see note[1]

* Added: A bunch of expressions to get those joint specific properties: see note[1]

joint_PinDist(tag)

joint_SlideMin(tag)

joint_SlideMax(tag)

joint_SpringRest(tag)

joint_SpringStiff(tag)

joint_SpringDamp(tag)

joint_RotaryLimitMin(tag)

joint_RotaryLimitMax(tag)

joint_RatchetAngle(tag)

joint_RatchetPhase(tag)

joint_RatchetRatchet(tag)

joint_GearPhase(tag)

joint_GearRatio(tag)

joint_MotorRate(tag)

* Added: An expression to get the joint's type as text: jointType(tag)

* Added: Expressions to get the points that a joint connects to the objects. Either the current object or the other one:

jointAnchorX(tag)

jointAnchorY(tag)

jointOtherAnchorX(tag)

jointOtherAnchorY(tag)

Note [1]:

If the action or expression used doesn't match the joint type then the action will do nothing and the expressions will return 0.

Prominent

Line segments might help with that but I currently have no plans to implement it.

You could bevel the player's collision polygon a bit.

-cheers

Edit:

Last minute fix. Re-download version 1.9.

* Fixed: "Enable/Disable" and "Set immovable" actions would crash trying to remove a shape more than once.

Prominent

Here's a proof of concept in events to see how it would handle. The result is decent, but it becomes much more complex if we wanted to use tile collision polygons. It would also take a while to implement this in a good js way. So long term I may implement something into the behavior but not at the moment.

R0J0hound , thanks, yea I can probably just taper the sides of the player for simplicity sake for now..

btw, I found an issue- some reason this capx isn't finding the collision point..

Also, why can't we get new collision points after the first collision? if a line falls down, it only gets the first end that touches and never the last end..

I need to figure out a way to find both collision points when a line has both ends colliding, or when the new end collides.. some reason it only registers the first collision.

edit: I guess it doesn't register the second collision if it is already touching?.. hrmm..

"on post collide" is only triggered when two objects first collide (useful for sound). I need to add another condition to loop over all the collision pairs so you can check at any time.

R0J0hound , hm okay.

I'm having issues with the joints expressions.. not sure what is happening.. I add a tag to one object, and it is adding the same tag to another object, so if an object depends on whether a tag exists or not, it won't be accurate because it shouldn't have the tag.. maybe I can make a simple capx to show the issue...

R0J0hound , okay I found the bug..

the capx has two instances that fall.. one hits the tilemap which adds a joint called "test"

the other instance, when it is below y position of 300, will add a join to tilemap called "test2"

I have a text object that counts how many joints with tag "test" .. it should be one, but it shows two.

Update 2.0:

Download in first post.

* Fixed: Joint tags were not working.

* Added: "for each collision pair" condition. "on post collide" only triggers when an object first hits. This will loop through all the current contact pairs.

Document tidbit:

Joint tags can be any string when adding joints. When using it in joint expressions you can also use a number index.

So do this to get the type of the first joint

Sprite.Chipmunk.jointType(0)

Or the second:

Sprite.Chipmunk.jointType(1)

Also you can give more than one joint the same tag name. Using it in a expression will give the last joint with that tag. This allows you to modify the joint that was just added.

So if you added two pin joints, both with a tag of "". Then the following expression will get the impulse applied to the second joint.

Sprite.Chipmunk.jointImpulse("")

Also attached is an example using the new "for each collision pair" condition.