Edit: According to Ashley, c3 does not pool objects behind the scenes. Advances in garbage collection have made this practice not nearly as important as it was 10 years ago. c2 used a generic pool behind the scenes, and recycled objects, but in most cases this isn't a concern anymore. In specific cases, where 100s of objects are being created/destroyed, pooling them is worth it, though either addonsdk/js will have far superior results than doing so in the event sheet.

-----

Hey all, I'm wondering, when creating a behavior,

if I declare the following in the constructor for a behavior instance (instance.js):

this._state = [false, false, false, false, false, false, false, false];
			this._lastState = [false, false, false, false, false, false, false, false];
			this._enterTime = [0,0,0,0,0,0,0,0];
			this._exitTime = [0,0,0,0,0,0,0,0];

I know its a 2d game maker, and it excels at it, but i just wish they'd put a little more into 3d. With just a few more things it could be really great for 3d too.

Honestly, I have to totally disagree here. Given limited development time potential, the addition of 3d features when many crucial 2d features are still missing feels like a pointless distraction. Construct competes very well on the 2d scene with other engines, but it would start to be arguably the best in that realm if a few more crucial features existed (hierarchy view, for example). Adding to 3d won't allow c3 to better compete in the 2d space, and it really can't compete at all in the 3d space. We don't even have good support for working with 2d vectors at the moment, let alone 3.

Currently, I can think of a lot of good reasons to use c3 for 2d games... but 3d? There needs to be a lot more work than just a few features added and all of that would take away from the needed enhancements.

Back when c3 was still just a discussion, there was alot of talk about how c3 was supposed to add the ability to author behaviors and plugins from within c3 via events. That would have been massive. Instead we got scripting, and a limited api. Don't get me wrong, that allows for some cool stuff, but it can't compete with unity, its massive api, and the superior performance of c# over js (let alone the fact that js sucks for making games with for a plenitude of reasons - it has benifits, and c3 being on the browser is an advantage). But 3d requires way more work to lift off the ground, and being able to create custom tools is a huge part of the lift requirement. Even with the sdk, good luck extending the c3 editor. Good luck scripting your own render pipeline. Good luck extending anything in construct... because currently, you basically can't - not like you can in many other engines.

Making a 2d game engine is alot of work. 3d is exponentially more work., especially if you want full fledged support.

If construct doesn't add more tools to extend and customize construct (including the editor) there is no way you will be able to do anything outside of cookie cutter 3d work.

So... You have a server. Its serving addons. You have an issue with the server, but thats okay, you don't need to work with a project using those other addons at the moment. Except construct has a problem with that. Construct wont start if it can't load those addons.

You can't remove those addons, until you correct the server.

This is pretty much an idiot loop...

For some reason c3 wants 2 addons. It decided out of the blue it can't get A, despite the fact that I haven't had it hosted in a while and am not using A in my current project, and have b hosted instead.

Why must I exit construct and ensure it can load an addon, so I can unload it?

This is totally stupid. Why can't we open projects with invalid expressions? We have to somehow correct them, but not through the editor.

Not sure why, or how the project has an invalid expression, but I have to save as project folder, manually find the offending lines, correct them, and then open.

Why does construct not allow us to use the editor to correct errors?

The kicker is that I have no clue why it decided the expression was invalid and wouldn't open the project. I didn't have to fix it, because simply shutting it down, restarting everything and opening the project back up made it happy.

Hey all,

I have written up 3 suggestion on github. They are all realted, but to keep it simple I seperated them. Please go and upvote if you find these useful.

----

First, GetCollisionEngine is not included in the sdk API, meaning officially, we can't make behaviors like 8Direction and Platformer. This is a request to, at minimum add that call to the sdk, though I would like expanded access to GetCollisionCandidates, GetSolidCandidates, PushOutSolid, and a few others.

github.com/Scirra/Construct-feature-requests/issues/153

----

Secondly, PushoutSolid naively assumes users only wish to resolve overlaps with a solid object. It also is tied to Custom Movement, which limits its usefullness across families. I want this functionality available to any object, regardless of whether or not one has the solid attribute. Any object with a collision poly, should be able to perform these actions. Have you ever wanted two of your characters in a game to not overlap? Yeah. There is no reason PushOutSolid is restricted to resolving Solids, and is not simply, PushOut.

github.com/Scirra/Construct-feature-requests/issues/154

----

Lastly, PushOut action has a hardcoded max distance that it checks, if no solution has been found, it aborts. My suggestion is that an additional property is added that allows the user to define this distance. Each game is different, and this hard coded number creates performance issues. Secondly, many collision engines allow for partial resolutions, instead of a full solution in one frame. By adding an additional property "Should Always Resolve", if no solution was found, the instance will still be pushed in the desired direction, by the maximum specified distance.

The benefit is that for many collisions performance will be improved while at the same time the quality of customization and use will be increased.

There is no reason for the behavior to have hard coded assumptions about what the user needs, especially when it takes a significant performance hit to undo what it does.

This suggestion would allow dt based push-outs over multiple frames easy to implement, and importantly, much better performing.

github.com/Scirra/Construct-feature-requests/issues/155

---

TLDR: These should all be easy to add and will vastly improve the the usability of PushOut while increasing performance in specific cases as well.

---

Additional points. While I can't make a common set of ACES, I have made a behavior that does the above, and use it instead of custom movement. But it uses undocumented calls to c3 internals. It is not possible to make the above without at least having an expanded api.