I think fedca understands the point I was making better I think.

Ashley - I have used construct a lot in education settings, I have taught 3rd -> 6th and I think you misunderstand my point.

I'm not arguing you should have invented a language for construct. that is a hill I agree you should die on, I would do the same. I'm saying no other major game engine forces you to use a proprietary language any more than construct does. Gamemaker gets the closest to forcing you into gmsl, but you can create c++ libraries and sidestep that.

In unreal, you can use blue prints. Those won't translate out of unreal. Or you can use c++. In Unity, you can use bolt, playmaker, or any other graph tool to design logic. Or you can use c#. Godot offers both c# and c++, but some people like the built in language.

In construct, the primary selling point is no coding required, because speed and ease. So you use event sheets, and just like in the other engines, like gamemaker gmsl, that specific knowledge base won't transfer exactly.... but you can indeed use javascript, but using javascript in construct is harder than c++ in unreal and c# in unity. Milage may vary, but I can get 6th graders coding in unity much faster than in construct. Creating a functional asteroids like game all in code takes much less work in unity, unreal, and gamemaker.

Typescript has improved c3 coding times a huge bit, but it is totally disingenuous to use comparative language in marketing when the engines that are comparable don't have an issue that makes construct a better choice.

Construct is cool because you don't have to program. In that, I would argue it is the most advanced tool while also being super simple to pick up. When you are ready to "level up", it supports javascript, which learning that is a translatable skill, meaning you don't have to switch engines if learning to code is your ambition.

My point is that the marketing statement on the front page makes it sound like using other game engines is a bad idea for reasons that construct alone amongst its peers has solved. This just isn't true.

Liberador - I'm on Ashley's side on this, bringing up color spaces is relevant because the reasons for either are the same. Sorry if you feel frustrated by this but you are wrong - It was much more convenient for me to post here.

...great extent to which other developers have ignored the warnings in the SDK documentation have forced us to act on this to prevent disaster in future, and I can only apologise that addon developers who have always abided by our advice are impacted by this.

Ashley

First of all, you are not being forced. That is not how that word is defined. You are choosing. Don't shirk the taking responsibility by using a passive voice. It's pathetic and unbecoming of a leader.

Second, you aren't preventing the future disaster, you are making it happen now, completely and totally; For all behaviors written correctly, and the ones who ignored the warnings. You are NUKING every building in a city to address the ones that aren't up to fire code so we don't have fires in the future.

AND then you have the audacity to say you can "Only Apologise" for the fallout!?!?!?!?

You can bloody well do more than that. You can not force v2. You can provide better api exposure. You can listen to the community. Dude. I expect this level of word play from politicians, not programmers who whould understand logic and syntax . You can "only apologize". Lol ~ crying in tears while laughing hysterically~ I am so frustrated right now.

You promised the official sdk would be supported and now you claim the intent of that promise is preserved because there are equivalent commands in sdk v2. That "intent" was not clear in the words you used to convey that original promise. You seem quite proud of how incredibly backward compatible c3 is - but I have scripts written in 2015 for unity that still work, and they never made such promises.

The sdk manual currently sucks, there is no reference in the sdk v1 for each call pointing to the new one. I'm pulling my hair out trying to get these translated, but I don't think its worth it. and the fact that official behaviors haven't been translated to sdk2 only provides more evidence as to the weaknesses of sdk2 and that it isn't ready.

Construct looks like a poor choice going forward for advanced users.

Is there a manual entry for : createLoopingConditionContext()

I can't seem to find it.

Do you know where in the manual this is at: createLoopingConditionContext()

Both google search and website search bring up nothing atm.

Looking around, can't find. Google keeps landing me at sdk v1:

construct.net/en/make-games/manuals/addon-sdk/runtime-reference/event-sheet-classes/eventblock

Have these been overlooked for sdk2?

What kinda behaviours did you create? Maybe or hopefully there's workarounds or ways to solve this?

Mostly, behaviors for state management, custom movement / behaviors, physics, collision resolution, a stat system with dynamic buffs/debuffs, a custom input plugin, and a few others. Mostly just system stuff and non-particular library stuff.

Things like the toggles, stats, inputs, and state management tools actually should transfer fairly easy as the calls to c3 api are minimal (just tying the behaviors to each other so I don't have to create go-between events).

Having the abilities to create plugins/behaviors from within construct would be game changing.

But in the mean time, Have you tried c3ide2, by skymen there is currently a branch with some v2 templates, and the cli should be updated soon.

both of these are much better than the original c3ide and support v2, they are also more robust and imo provide a much better developer experience.

The thing I liked the best about c3ide was the auto generation of ACES through the gui. Click add paramter / add action, etc, and then fill in the relevant items once. I didn't think c3ide2 had that? I'll have to check it out again.

I know this has been discussed before, but it still seems like the most obvious thing to me.

With moving to sdk2, alot of the tools I used to author behaviors for sdk1 are kaput. The fact that I have to write 983746987245 files to make 1 behavior is still absurd, and tedious; c3ide was a huge boost.

I'm sitting here looking at the pros and cons of c3 again, and writing behaviors without tool assistance is making me favor unity again. since I have to recreate all my behaviors anyway for sdk2, I'm really thinking about just going back to unity. Especially since half the behaviors I was writing for this project were ports from my unity library.

This all just feels like I wasted the last half year for a game engine determined to shoot itself in the foot to prevent a broken leg.

Ashley

Thanks for the response!

As far as recreating vanilla behaviors, The runtime for Collision engine is missing the calls for pushing objects from collisions. I put a feature request in back in april maybe.

Is this something you are possibly planning to add?

As it happens, I have to push objects from overlaps that aren't solid, so the custom behavior doesn't work anyway and I have my own solution, but I think other users would benifit from having an api for that. Even better if it allows us to choose the max distance to test for instead of being hardcoded.

When I go the resources at Addonsdk , its a hodge podge of entries with some warning about being sdkv1, and nothing indicating whats sdk v2.

The minimal example available for sdkv2 hardly helps.

Am I able to simply use the same calls from the scripting reference for use inside construct 3?

example:

runtime.collisions.testoverlap(...)?