R0J0hound , also, I'm noticing that if a line is created overlapping another object so that it extends across two sides, it'll position the line twice the depth rather than just once- this causes the line to be pushed out way too far. I'm guessing that it somehow positions it for each collision point, which is why it pushes it out too far.

edit: actually.. to be more accurate, I tried to push it out via collision depth * normal.. but it seems to be pushing it too far out when it extends across to sides. If it extend across one side it pushes out fine.

edit2: actually maybe it's fine. Since I move it to the collision point, and then push it, seems like I don't need to push it out. For some reason though, sometimes the collision point is inside objects, and I'm not sure how to get the collision point on the edge of the object when this happens..

Also been getting this error.. not sure what is causing it though.. edit:seems to occur when a line collides in two places at the same time...

Error: Assertion failed: Cannot remove a shape that was not added to the space. (Removed twice maybe?)

at assert (http://localhost:50000/rojoChipmunkBeta ... or.js:51:9)

at Space.removeShape (http://localhost:50000/rojoChipmunkBeta ... .js:3889:3)

at behinstProto.updateShape (http://localhost:50000/rojoChipmunkBeta ... js:6642:16)

at behinstProto.changeShapeCheck (http://localhost:50000/rojoChipmunkBeta ... js:6956:10)

at behinstProto.getBody2 (http://localhost:50000/rojoChipmunkBeta ... .js:7598:8)

at Acts.addPivotJoint (http://localhost:50000/rojoChipmunkBeta ... js:7643:20)

at Action.run_object (http://localhost:50000/eveng.js:1843:10)

at EventBlock.run_actions_and_subevents (http://localhost:50000/eveng.js:929:38)

at EventBlock.run (http://localhost:50000/eveng.js:886:9)

at EventBlock.run_subevents (http://localhost:50000/eveng.js:994:11)

at EventBlock.run_actions_and_subevents (http://localhost:50000/eveng.js:933:8)

at EventBlock.run (http://localhost:50000/eveng.js:886:9)

EDIT: seems to occur when a line collides in two places at the same time...

if it helps, this is the error I get about the angle thing..

Error: Assertion failed: Internal Error: Attempting to set body's angle to NaN

at assert (http://localhost:50000/rojoChipmunkBeta ... or.js:51:9)

at Body.setAngleInternal (http://localhost:50000/rojoChipmunkBeta ... .js:1725:2)

at Body.position_func (http://localhost:50000/rojoChipmunkBeta ... .js:1768:7)

at Space.step (http://localhost:50000/rojoChipmunkBeta ... js:4998:14)

at behinstProto.tick (http://localhost:50000/rojoChipmunkBeta ... js:6983:17)

at Runtime.logic (http://localhost:50000/preview.js:2346:29)

at Runtime.tick (http://localhost:50000/preview.js:2066:8)

at tickFunc (http://localhost:50000/preview.js:629:38)

R0J0hound , awesome..

found a bug when you set object to immovable yes after adding a joint, it will cause an error.. I did this during on post collision- not sure if it happens outside of that.

I'm also getting some errors sometimes- not sure why yet.. saying that can't set body angle to nan.. I think it happens when it tries to set angle towards position and the position is ontop of itself.. or something.. not sure though.. this happens during on post collision.

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.

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 , 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..

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

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

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]

depends on the type of game.. if it's a game that can easily be cloned, then it probably will be if it shows any signs of success. If it's a game that takes months and months to recreate, then you're already ahead of other people, and if your game is successful, then who cares about the imitations- people will want the original.

Making easy quick simple games just makes it easy quick for others to copy..

So in other words.. the simpler it is, the less can get in the way of others cloning it..

the more complicated it is or time consuming to make, the more gets in the way, and people that spend considerable amount of time on it would probably want to personalize it a bit and not copy everything.

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

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.