... More physics and all the things

I know this is a post that has been posted before... but WHY don't we have access to Kinematic bodies as well as other joint types- prismatic joints being at the top of that list.

It doesn't make sense. I see many questions on the forum saying how do I do this or that using physics... the answers or always hack arounds when the code in the box2d behavior already includes all the things... it just needs to be enabled to be used in construct 2...

I know. There are a lot of stuff I use physics for in other tools. Often pining for them to be in C2. But I don't think they are coming. In fact I just have to fight C2 to use physics with a handful of objects on mobile. Where as other tools just use physics2d so well with more objects and less fighting.

I am not sure why Ashley has never responded to this. It's been asked many times and i dont recall seeing an answer.

We currently maintain support for 3 different physics engines and it makes it very difficult to make changes while maintaining compatibility. If we dropped support for CocoonJS physics it would be easier, but then that would probably upset everyone using CocoonJS.

This makes sense. Diversity of platform over robustness of a single platform. I just think those two things (kinematic and prismatic) would go really far to help whats there. You can't really do a whole lot without kinematic bodies in terms of dynamic levels using physics and prismatic joints go along the same lines.

At any any rate, thanks for all the hard work Ashley

Ashley, Actually it doesn't make sense... I know nothing about box2d other than alot of assumptions on how it works but decided to add kinematics myself because I need them. I changed the Immovable property to body type in edit time and provided 3 options (static, kinematic, dynamic). Then, in run time, I declared the body definition to be whatever it was declared as in the property and presto: I have kinematic bodies. This took 30 minutes, most of which was finding the things I thought needed to be done and learning a bit about box2d. Obviously I need to create some expressions/modify some older ones for full functionality... but ultimately I don't see the complications everyone was saying would exist? Grant it, I only changed asm and not the other two. Is it really more difficult than simply exposing box2d functionality to construct? It seems really strange to me to have all the code in the behaviour to do these things but not be able to access it in construct.

More minor thing I had in mind would be to have option to make joint from position.

Ashley, Actually it doesn't make sense... I know nothing about box2d other than alot of assumptions on how it works but decided to add kinematics myself because I need them. I changed the Immovable property to body type in edit time and provided 3 options (static, kinematic, dynamic). Then, in run time, I declared the body definition to be whatever it was declared as in the property and presto: I have kinematic bodies. This took 30 minutes, most of which was finding the things I thought needed to be done and learning a bit about box2d. Obviously I need to create some expressions/modify some older ones for full functionality... but ultimately I don't see the complications everyone was saying would exist? Grant it, I only changed asm and not the other two. Is it really more difficult than simply exposing box2d functionality to construct? It seems really strange to me to have all the code in the behaviour to do these things but not be able to access it in construct.

The question being: will that also work in the cocoonJS physic engine, since it does not have the same functionnalities as box2D (and you cannot just throw it away, nor do things only for box2D I think, or else people will again be complaining that their precious cocoonJS is once again the victim)

LOL, who complains about a "precious" CocoonJS? We're all in the same boat here, trying to keep options open and find the best exporter. Potentially nerfing CJS export would hinder more than it'd help. Take your trolling elsewhere.

Aphrodite - I don't think exposing box2d functionality for just box2d is a bad thing or unfair, even if it can't be done in cacoon js. Making games for phones is a compromise in the first place and you can't always have it all. I actually didn't realize cacoon js a different physics engine... That makes things a lot more understandable. If cacoonjs can't do something box2d can, adding one would throw exceptions for the other.

GeometriX - nobody said anything about nerfing cacoonjs, just exposing box2d functionality to construct 2.

Ashley Now that the "precious CocoonJS" is deprecated, could this be a potential change to the physics engine in the short, mid, or long term?

I certainly hope so. Its way past due.

...not to mention a couple of asm.js bugs that need fixing as well, if at all possible.

Colludium - from what I think I know, those bugs may not be fixable in asm.js - Which ones are you referring to? Disabling collisions is the only one I can think of right now - Which would be nice to be sure.

As for Aphrodite's question, I hope so too

Ruskul, there's also a max of 8 polygon corners allowed per object iirc. Not so much a bug as a limitation that might catch you out.