Ruskul's Forum Posts

  • I like the sound of alpha testing for changes to things like that. Is that possible though, it seems like a lot of this 3rd party software goes through a lot of changes.

    So I heard the issue was also related to chrome and not just nw- which makes sense as I have been having trouble with that... is there an update timescale on that or am I out of the loop already?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • rexrainbow - Oh my goodness, where have you been my whole life! this website is a gold mine!

    So then, nothing bad happens when you call a behaviors action and don't use the event sheet to call it?

    ...and it works with a behavior and not just a plugin?

  • TiAm

    I just came up with a way to test. I created a bouncing ball project and disabled construct 2 collisions. Physics ran without a hitch. This means any object with physics is having multiple collision algorithms run on it...

    I need to set up some tests... I am curious what this collision testing overhead is.

    steps 1 and 2 are fast so I am sure it is nominal... but it may add for some interesting optimizations that could occur in a project. Box2d supplies collision information, but it is not exposed to c2. If you want to know if an object is hitting another you have to use c2 algorithm.

  • Colludium - Well, to be fair, It is impossible to make the perfect tool that does everything perfectly. And I must admit that construct 2 has amazing features... I just feel that physics in particular needs a boost. I also think that in general construct 2 is more suitable for smaller projects due to the lack of pre fabs, compound object mangers, etc... so adding in physics features that someone making a really simple game can live with out may not be worth the time...

    Priorities

    either way, Ashley will be generous...

    Of course, if I was making construct 2, it would have been in xna, only export to desktop machines, etc... But then I would get alot of complaints about other things. and it wouldn't have been construct 2. It would have been much crappier for everything other than want I wanted at the moment... lol

  • Colludium - There are even the little things in the behavior that can easily be changed...

    you know how set position breaks the physics behavior? Basically physics sets the velocity to be the difference of the old and new position. Meaning your object blasts through space at an unreasonable speed...

    That isn't box2ds fault... it's how the behavior handles it.

    Even the fact that the behavior isn't using edge shapes for the tilemap boggles my mind. I told Ashley about internal seams being a source of collisions when they shouldn't and he said it was not a bug but a box2d thing and dismissed it. It is not a Box2d thing it is a Construct 2 physics behavior thing... am frustrated...

  • — -

    As it turns out, the box2d code for these features is in the behavior script already. I don't see what version of box2d it is (which I would want to know). I don't fully profess to understanding everything I mess with but adding in more features has been surprisingly simple... I just do it in quick and dirty ways... (for example, I added an action to set the object to be kinematic... I keep the programing simple, and usually work through such manners...) I hate to put the full effort to fully enable a feature. It takes a chunk of time (for me longer, because most of it has been figuring out c2 implementation, and making sure I am not messing it up) but even still, my first feature exposure took under 2 hours. Ashley could probably do it in 10 minutes. I just can't justify permanently changing the behavior until I know for sure Ashley won't...

    I figure there must be something I am not appreciating here, or some unknown.

  • -Answer-

    Construct does do this but only in specific cases.

    "...(disabling c2 collisions) will have no effect (on performance) if you don't test for collisions in events. If you make no collision tests yourself, then the C2 engine doesn't make any collision tests either, so it's irrelevant whether the object has collisions enabled or disabled.

    I don't think there's any way around having the two collision tests - not all games use a Physics engine, so C2 needs its own engine. But as I say if you don't use collision events on an object then it will only use the Box2D collision engine." -Ashley

    *** ORIGINAL POST ***

    Hey everybody,

    Does anyone know if construct 2 is using box2d internally for collision detection? Or is it using a custom system to test overlap.

    It seems efficient either way, but I wondered if it did implement its own algorithms, wouldn't it basically be doing double time when you are running physics on an object as well? Because you don't ask physics if something has collided... you have to ask construct 2 if something is overlapping...

    Just doing some exploring...

    ***END ORIGINAL POST***

  • QuaziGNRLnose - It turns out, Ashely said that is a very bad idea... I'm not sure why, just that construct 2 wasn't designed that way. Basically, calling a condition or action of another behavior (even on the same object) from a second behavior doesn't work. I asked for clarification but haven't heard back... I can't even find/remember what post it was in

  • Colludium - I meant to reference your work from another post. I have since set up tests as well and can't tell a difference between the two. I did it because the regular version is easier to add to the behavior because you can read it at the time of editing.

    If there is a dichotomy between full feature set and slightly higher performance... Then I would choose features in a heartbeat. A careful developer can easily work within the constraints of performance considerations, but if you haven't got a tool to use, you can't use. I know ray casting is expensive and shouldn't be done willy nilly all over the place, but I think that the c2 work arounds are much more expensive.

    The dumbest part is that I have devised a ridiculous method to determine a collision surface normal on a solid object that involves extra sprite objects, plenty of editor time placing these sprites and setting appropriate variables, all in the knowledge that box 2d can pass this info directly to construct 2. But I don't want to risk making a version of box2d that may become outdated when Scirra adds more features... Then my whole project would be broken.

  • 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