Aphrodite - I was under the same impression... Though I didn't mean to say that Ashley was hinting that there would be anything anytime soon, just that there may be more features in a situation where Scirra only had one physics exporter to deal with.

I just really need to know if anything is on the horizon. To my knowledge there has been discussions surrounding this topic for a long time. A long time ago, I said to myself, "cool no need to worry about these features I don't have because I just might get them in a future update." So I haven't let it worry me except to post my two cents on the forums here and there. But I am at the point where I actually have to make a big decision. continued development is tied wether i decide:

to commit to my own version of the physics behavior for the next 1.5 years (give or take 6 months), or continue all further development in Unity...

If Ashely does indeed have a concrete plan, then knowing that may save me a lot of work. Knowing there is no plan will also properly motivate me to make a decision as I will know what needs to be done if I stick with construct through this particular project.

It just comes down, "It would be really, really nice to know".

Each decision has its own problems in my project... I have considered going back to simple libraries where I have more control over everything, but that would be equivalent to throwing out the last year's work... and lets face it, I'm not here for the fancy no scripting event editor; I am here because construct is an amazing product that speeds up dev time considerably (I wish one could actually script events... it would take less time than the dialogue window business... anyway...off topic lol)

Ashely : Is the physics behavior going to be updated, ever? Is it in the plans? And I mean a meaningful feature update... ? I simply want a yes/no response. and if yes, what the plan and timeline is? I feel that construct 2 saying it has box2d powered physics support is like saying hot air balloons fly...

The physics behavior is a shell of what it could be. You know this, I know this. Everybody who knows what box2d is capable of knows this.

If you have no concrete plans for expanding physics support in construct 2 then please let me know. You have hinted that it is a possibility, but I can no longer develop under that speculation. I either need to solidly move my project to unity or commit my changes to the box2d behavior and apply it to the objects in my game.

There have been numerous forum postings expressing interest in the features that box2d already has... and that construct 2 could have. It simply is not possible to make a robust physically enabled game without at least a few more joints and kinematic bodies, edge shapes, pre/post solve, and collision filters (even if done manually during pre solve).

Thanks,

Dito on Lato 's post. does (r195) fix the problem or are people still using workaround. Also, I don't understand why nodewebkit has to be updated to the most current version every time there is a construct 2 release. Don't fix what isn't broken...

Ashley - In the context of "plugins should be independent"... what you said makes sense to me, however I have become very tired with wiring objects together via events over and over, project after project. Since we can't package events together in a reusable way, that leaves only sdk to make behaviors do these things... How then can large scale projects reusing the same events be effectively managed? I need over 350 events simply to get my custom box2d platformer working... I have saved the basics of this to a template file, but its still a lot of tedium. I have also toyed with the idea of putting the code in the physics behavior as an enable-able constraint but that brings up many problems(I am sure you know what I mean here). The final, most sensible, thing to me would be to make a behavior that can call another behaviors functionality via actions, conditions, and expressions. Even writing an AI that then calls a behavior using another behavior attached to a specific plugin isn't a bad thing at all...

And it's not like we all are writing for the community or trying to make behaviors that work in any way. Each game is it's own thing, but I am fond of not having to do the same work again and again.

TiAm - I have noticed I seem to find gripes well after someone else has settled the conversation, lol.

I have been reading through the examples and thats actually what got me frustrated... The more I read the more I realize I am missing alot after having gone through the sdk. It would be nice if the template included more comments and empty functions with descriptions.

The problem I am having is getting behaviors to talk to each other... and the only example of that is with solid/platform/jumpthrough (and a few others). But it seems that behaviors are meant to run in a more isolated fashion...

Okay... so I have this object and it already has physics behavior applied to it. I created my own behavior, but I need to access information in physics behavior. I should think I should be able to simply say something like this.behaviorInstanceIWant.someCondition ... but I can't find it in the sdk.

In reality, I am basically writing controllers for physics objects. It seems like the sdk is usefull for making isolated behaviors but interactive ones seem much more difficult compared to other engines. Is this correct or am I missing something.

Thanks

Hello,

I have been going over the sdk as of late ( not the first time) and feel there is a lot of information missing.

For example, in a plugin or behavior you could include code in tick2 or pretick or even posttick. When are those called? Do I need to use posttickme or pretickme? or do they run automatically? Do I need to un tick them some how when they are destroyed?

You won't find that in the sdk. You have to figure it out yourself. And there is alot more. Did you know, for example, that in preview.js there are explicit references to certain behaviors (such as solid and shadowcaster). This means that if you want to write attributes like "solid" and have them work with a behavior like platform, then you have to edit the core engine running your game.

I haven't yet fully read through the relevant code (I would be happy if someone has and can shed some light on this) but it seems to me the way behaviors works is sort of messed up if I need to edit preview.js to really get things working. Every time there is an update I would have to edit it again. Is this really the case????

I know this isn't a fair comparison, but it took like two days to learn how to code for unity, whereas construct is a pain to code for... I feel like I need to make an auto coder to just add get and set actions, conditions, and expressions for variables... Anyway, I'm off topic...

The point is that I find the lack of documentation on the sdk somewhat annoying... especially compared to the main manual, which is very comprehensive.

/rant

QuaziGNRLnose Thanks, I didn't think about pin referencing another object. It's funny, this sort of thing is super easy to make in something like unity, but I have so much trouble coding for construct.

Hey fellow devs,

I had a quick question. would it be possible to create a behavior that affects more than just the object tied to it? I want to make a behavior that creates additional objects to function as collision and pickup boxes. I'm tired of setting this up in project after project when it is the same thing.

The behavior would also affect other behaviors such as physics in post tick.

I just need to know if a behavior can do this before I start figuring out the hows...

Has anyone done some benchmarks for this? How does it compare to box2d web and ams.js?

Ashley - when will that be released in construct 2? I'm in no real hurry at the moment but will be exporting a project soon.

Problem Description

If you change an objects friction via action in the event sheet, and the new friction is different than what it was and it is not 0, the object will freeze position for 1 frame following the change. The position is not updated but velocity and forces are still calculated. The object can be frozen in place via friction changes indefinitely. If any force is being added to the object over time, the moment friction stops being changed, the flies as though it has been in movement the whole time.

***Edit - Changing density also causes the same problem! - more on this below /edit***

The one frame freeze is noticeable at 60fps and extremely noticeable at 40 fps

Using either box2d web or ams.js makes no difference.

Attach a Capx

https://dl.dropboxusercontent.com/u/114 ... oblem.capx

Description of Capx

This capx is running a physics simulation with friction set to 0 by default. The ball should bounce around forever as there is no damping and elasticity is set to 100%

Any frame in which you are pressing space key, the ball object will have its friction set to random(0,1).

Notice the freeze.

Steps to Reproduce Bug

• Step 1 - make a physics object
• Step 2 - change its friction to a different number than what it was and not 0

Observed Result

Objects freeze when changing friction

Expected Result

The object should not freeze... >.>

Affected Browsers

ALL

Operating System and Service Pack

Windows 7 service pack 1, windows 7, windows 8

Construct 2 Version ID

190 64 bit and previous versions (I have been aware of the problem since June 2014)

This bug makes it unreasonable to change friction at runtime in the best of situations. I have checked box2d forums and could not tell if it was a problem with box2d or contruct2 (my hunch is that it is box2d... but I really can't say.

***EDIT***

My hunch is that it is the behavior to blame. It looks like the body is being recreated after setting this.friction. it could be that recreating the body induces a one frame penalty given the way everything updates. Also, Box2d has a built in SetFriction that should be called here, if I am not mistaken. I think you also have to update contacts that are already occurring between the object being changed. Box2d stores the friction in the contact and does not regenerate that information on continued contacts. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">