bladedpenguin - Yeah. You are getting on to something. Physics needs raycasting, the base system class needs raycasting, and the overlap methods needs updating to be a little more situationally robust. (you should tell ashley as I am sure he has heard it enough from me, lol)

I have read the source code for both box2d (which is the code runs the physics behavior) and as much of the core classes that runs construct 2 as I can. Changing the physics behavior is perfectly possible. It would be quite easy to add raycasting (most box2d features are easy to add). But you can't mod the system files for construct, so you would have to create a different behavior to handle raycasting vs. solids. This can be done fairly easily as the algorithms for raycasting are easy to find on google.

But, the biggest problem with all of this is the fact that the tile map generates collision polys in a smart manner. For example: if you have a bunch of square collision tiles, the tilemap will group those up and make it so it uses as few collision shapes as possible. This is awsome for optimization, but this means when you hit a poly, and that poly is a large one that makes up an entire group of tiles, finding the tile still requires some mucking about.

This actually becomes a sort of dichotomy between performance and a particular function. Does this all make sense? I am saying that the solution to this problem is going to be, somewhat more nuanced than it appears at first look.

lol That comment made my day

Ashley - As far as I can tell, contactedge.get_next() is only supposed to go through the contacts connected to the body in question. if you use contact.next(), that will go through all contacts in the world. But without using box2d.getpointer() the loop will run forever and contactEdge.get_next() keeps returning empty b2 contact edges.

I edited the code to count how many times the loop is running... It runs only as many times as there are physics contacts affected the body. So it looks like it is running as it should.

Okay, I wasn't sere if there was anything in the error report that would tell you what was wrong. On the plus side, nothing seemed to be wrong other than the error message.

Also... I find that it is easier to get technical advice on the unity forums. Construct 2 has a super nice community, but 9/10s of us here don't know a switch from a loop... which is important if you decide to go the sdk route or have deeper problems with c2 than the average user.

Also, javascript. I don't like javascript. Games don't like javascript. But if you go the sdk route you get all the fun that comes with it. I would take c# or c++ anyday of the week over javascript... yet, here I am with javascript. I figure everyone needs something to keep them passionate though; and I loathe loosely typed javascript...

newt - a better implemented work around to be sure but still using overlap... which is part of the problem. It won't work with physics.

If you want to get into a discussion about whats better for what, that all comes down to preference in the end. I prefer working in c2 because I can make things so fast. But, I prefer unity because I can do more. I also think given the amount of games released on unity... you get the idea.

I would classify both the binding of issac and Mario as fairly straight forward games, and yes, you could make exact clones. However, here is the thing; You are going to need to write your own collision detection and resolution code to get an exact mario clone. Which brings us to some of the problems with construct. Because there is no way to edit, modify, or otherwise mangle the inner workings of construct to suit your designs, you have to make everything work as custom behaviors, plugins, or through the event sheet. I like c2, but when it comes to something like this, I would much rather sit down in an environment that is as flexible as possible. Coding collision response in events would suck. Using the sdk isn't as well documented as scripting in unity. Also, unity offers a better environment for that type of development. On the other hand... If you make it using the sdk, you will have constructs editor side speed when you are done. But then you may have to concern yourself over janking in NW.

If contstruct 2 offered an IDE and everything was component based, and physics was better integrated as part of the engine... I would choose construct 2 100% of the time. But right now I flop back and forth between the two.

The major letdown of construct is that it lacks true ObjectOrientedness which is the major problem with it. Using Unity, you can blast apart any problem needing inheritance, scalability, or virtual functions and the like... if you can code. In construct, since families can't inherit from families, and functions are kind of awkward, you lose the speed advantages.

The best example I have is a game Framework I worked on in which I had dozens of characters who could either be controlled by an ai or player. The characters were all as different as in smashbrothers (and as equally the same) and required multiple FSMs. Using families, and passing around UIDs in functions at a high level of abstraction makes c2 lose its charm. It took me two weeks get things to start working, but I had to sacrifice alot of future flexibility. Unity, on the other hand took much less time, as I could simply write abstract scripts how I wanted.

For small things, I use c2. For convoluted projects, I use Unity. I hope this changes in c3, which it may.

newt - you can't use else after a trigger

This is the type of thing more people need to learn the sdk for. I applaud your first behavior.

I made a behavior simply to quickly add a few common instance variables to objects that I did in every project. It saves a load of time in the long run. Health is a great idea.

There seems to be a flood of responses going on here, but I didn't notice some important info on first glance.

Nobody here seemed to mention the problem c2 currently has with work flow scalability. Creating a robust frame work for a large game that leaves you with plenty of options can be a chore with c2. It's not to say you can't do it, but lets say you wanted to create smashbrothers... Creating a multi state machine that each compound character can use is going to be funnn fun fun , and way more complicated than just cracking out the code and coding.

I am an artist btw, but if you can use logic, then you can code. I recommend c2 for quick dev of prototypes, an indispensable tool for making small games, but a headache for organizing large projects. The work flow simply decreases as the needs of the game become more flexible.

Also, if you plan on pushing a unique idea, construct 2 may impose a number of limitations of which there are too many to list... but its not uncommon on the forums to be told you just can't do x,y, or z due to x, y, or , z.

But alas, the only way you may discover these things and if they pertain to you is to start working. Construct 2 is a great tool, and you can try out alot with the free version. Make something then see what you think. Make the same thing in Unity, and see what you think. In the end I recomend both. c2 for speed, unity for sophistication. and if you want, there is always the sdk, but lets clear something up right away, you can't make "everything" with the sdk. There are limitations there as well.. .. But lets face it, you can't make everything on one thing, that's why there are all the other things... It also depends on how much "out of the box functionality you want" . Construct 2 has a ton of pure awsomeness from the get go, but it may be a little more difficult to expand that via the sdk than in, say, unity or unreal.

Sorry to muddy the water.

— - Either I don't understand what you mean or we are on separate problems. This is how I essentially create an end state for collisions:

OnCollision

------------- this.collided = true

NotIsOverlapping

------------- if (this.collided = true) then this.EndCollision = true

If EndCollision & triggerOnce

------------- // Do Stuff

------------- // this.EndCollision = false

As far as I can tell you need two state tracking variables and the use of IsOverlapping. But as I stated in the OP IsOverlapping doesn't work with physics enabled objects (a separate problem needing addressing). Meaning the workaround now requires sensor objects. potentially doubling the amount of active objects in a scene. Seeing as construct lacks scaleability in the compound object department, I can't see as adding another object to the list as being very desirable.

Essentially, I said workaround exists but problem with workaround exists... which is why the workaround is not a suitable sub for the existence of a new trigger.

Hey everyone,

The title says it all. It is easy enough to create a workaround to not having this trigger, but it would be faster and more suitable to have it included in construct. As it is, the work around will not work for physics objects without creating an extra sensor object.