Hi, if you want to crowdfund work done around the Construct engine, may I suggest donating to the Open Collective that was designed to do just that :)?

opencollective.com/construct-community

This goes to open source addon and tools developers in the community that probably need the extra funding, and you can already monitor how these projects evolve and you can also vote for your favourite projects:

construct-community-voting.dedragames.com

(To be clear this is unrelated to Scirra, and the funds go to people in the community making things for free otherwise)

Yeah that's fair.

In my version I was running it in about:blank and I used postmessage to execute any code that would have been blocked.

Let me know when you eventually start looking into it then :)

Just to get back on the topic of Editor tools,

Ashley should I spend any time doing this?

Alternatively I can also remove all of the code that handles the new dialog UI layer (which is most of the code) and only keep the code that opens a popup if you think that is safer in the meantime

If you want I can make a prototype and email it to you, or give you access to the private repo. The window manager addon is designed to be easily swappable in the future with any official API you might make, so if you think it's safe, I can make the window manager addon only manage popups and the message communication layer.

If you still think it's not worth working on until you sit down and decide what to do about it, I'm also happy to leave it be.

Of course in any case, I won't release it until you tell me it's fine.

What we want to do is develop reliable software that doesn't constantly break. Hopefully we can all agree that is a reasonable goal.

It is, and I don't think anyone would argue against that.

I suspect perhaps some developers got interested in the ability to access internal details, and thought it was cool or useful. However that was only possible due to the historic weakness of JavaScript encapsulation, and if you do that, you will end up with unreliable software that constantly breaks.

I understand your reasoning on that front, but I disagree with calling it exclusively a weakness. On one end yes it makes it very hard to build something completely closed off, but on the other hand, having constant access to the internals (even if all you can do is read them) allows for a lot of good things. Javascript I believe is a beautiful tool for rapid iteration, analysing other people's good ideas and learning how to build on other people's work.

In the case of Addon development, it's kind of a historical way developers around here were raised (including me) by messing around with other people's code and finding ways to iterate on things you were given access to. Of course having access to internal details is cool and useful if only for the fact that it allows us to imagine what things could even exist.

I could point at the long list of features that are now part of Construct that were initially developed by addon developers, often using knowledge of internal details.

I would even go as far as to say that "addons", "mods", "hacks" or any other kind of software that builds on top of other software naturally attracts the kind of developer that would find that useful and cool to know the internals of the thing they're working with. Sometimes it feels like you don't have an understanding of this and then get surprised when you meet developers that actually do this.

If you wish to develop quality software and build addons that are reliable and work in the long term

This is another misconception. Not all software is built exclusively with the intent of it being up to your standard of reliability. For game developers, most of their tools are meant to work for them and nothing more. If it's unreliable but they can deal with it, it's ok. If it breaks in 5 years after the project is long finished, it's also ok.

Now I will absolutely agree that in the case of addons that will be used by other users, there is a need for them to reliable and work without active maintenance.

SDK V2 has value in that it does make things work with less hassle, but that was never the critique of it. The biggest critique was the loss of a lot of things that have just as much worth as stability, like performance, and freedom to mess with things in private (for all the addons that are never shared with anyone else).

Still, yes I try to make all of my addons as reliable as I can make them and I deprecate them when I feel they aren't reliable anymore or when I feel I can keep maintaining them for free.

Also, another perk of Construct in this very specific case is that even if something breaks in a new update, users can always use a previous version as they are all permanently accessible. This is also standard in the industry where addons are designed for specific versions of the engines they are built for, and it is fairly commonly assumed that some addons will break over time and if you want to keep using them you should stick to older versions of the engine.

In the case of an engine such as Unity for example, it's actually even stricter as user made scripts can also break randomly from version to version. This idea that things made on top of an engine should never ever break is very unique to Construct in the game engines industry. Maybe in regular softwares this isn't the case; Perhaps extensions made for Audacity back in 1967 still work with Audacity 3 but that's not something I have seen commonly accepted in other game engines.

Anyway, I understand your point of view, I understand that you are the one in a position of dealing with the pesky users, and I understand why you would do these things. The only thing I ask is to not be thrown under the bus more than once every few years. The move to SDK V2 was a very painful time for me, I basically had to rebuild everything I had from scratch, and I still deal with the consequences of it to this day. I assume it is the same for other addon devs, so reading you wave around threats of an SDK v3 (because this is how it feels for us) is not something we take lightly either.

I am going through the work of porting all of my addons to SDK V2, I have rebuilt my addon framework from scratch, I have submitted countless feature requests, bug reports, and I have spent a lot of time reading the internals of V2 to debug issues I have found for you to make it as easy as possible for you to keep improving V2. I have also opened an open collective to try and help crowdfund development on addons and tools to try and get all of this done a bit faster.

I am not going through all of this again. I am not even saying this to be mean or threatening, but I have a business too. I have done all of this work for free out of passion for the engine you are building, but it has taken a significant toll on me the past few years to do this + manage my own business at the same time, so I am quite definitely never doing this again.

The editor is not designed to have UI extensions.

Sure. When I said "what are you even going to do" I was not talking about the fact that the editor's UI is not exposing an API. I was mostly thinking about the fact that browsers come with their own UI extension API and that it already allows things like events, DOM and Javascript to be completely isolated from one another. What I meant to say is that for as long as Construct runs in a browser I don't think it's ever likely that it will be impossible for Javascript running in the main thread from acting on the DOM.

Anyway, this is not me saying you can't stop what's happening. This is me saying I think it is quite absurd to want to fight the browser so much.

So I have to ask: do you intend to build reliable software that keeps working?

In the case of this editor tools addon, my intent was to experiment with what's even possible. Eventually, yes I would love for it to be reliable and this is why we are talking today. I came up to you saying "here is a solution I am experimenting with, what do you think about it, and what can I improve to make it work better long term?" not "Here is a finished addon that I have shipped to half of the Construct userbase and that I will never work on ever again"

If you do, you won't do this, because you can't guarantee to your users that it will keep working!

If I thought no amount of compromising or talking to you and asking for improvements in the SDK would ever guarantee reliability eventually I wouldnt be doing this indeed.

I've seen some experiments with making a 3D editor that operate on that principle, and it is a good approach.

Not sure which editor you are referring to. Are you talking about this? I don't think I've seen any external editor for Construct that actually provides a fully functional 3D editor.

I have actually experimented with this a lot this year and made this level editor for one of my games:

youtube.com/watch

This could turn into a generic 3D editor tool with some work but for now it's neither here nor there.

I agree that external tools are better when possible but so far Construct still has a lot of limitations. For one, if you want to do anything at all that affects anything in the project that isnt a project file or a script, you have to build something that can read and write project data. I started working on that a while ago with this project:

github.com/skymen/construct-crawler

There is also scope to extend the supported editor APIs to better allow integrating with external tools, such as the existing Custom Importer API

Yes, in fact the whole point of my initial message was: "Please just focus on extending the supported editor API as we try and figure out a proper way to make editors ourselves". If that ends up taking a different form than what I made in my initial experiment, it's fine.

Perhaps one less-bad option would be a supported option to open a popup window which can then show custom HTML and CSS content, and communicates with the editor via postMessage() - at least then the custom stuff is sandboxed within a separate window, it's still relatively flexible, and it's still a long way short of full editor DOM modification.

Yes! I proposed this as a solution as I genuinely can't imagine anything going wrong with this possibility.

Another possibility is having the editor tools run in an Iframe within a built in dialog, like the dialog popup that appears when previewing the game.

In fact, it could use a similar system of choosing between external tab, popup and iframe in a dialog and it would be perfect. From what I can tell, such a system already exists and works perfectly fine for Construct's preview which is also running arbitrary code.

Anyhow, my whole point was not "look I am actively destroying your beautiful editor UI, I am an evil addon developer", but rather "Do not worry about giving access to the UI system, literally give us the simplest possible form of it and we will build our own UI libraries and systems"

I want to finish with an appeal for co-operation. Please consider everything I've written, and do what you can to work with us. If you co-operate and work with us on supported features, such as perhaps a popup window API that is significantly more reliable long-term, perhaps we can end up achieving both some degree of the features you want, while maintaining our goal of making reliable software.

I would love to cooperate, as I always try to make clear. I don't think I've ever gone out of my way to go against your judgment and I have always been transparent about wanting to improve on anything I've made to see how we can make Construct a better engine.

Just let me know how I can better cooperate than what I'm already doing.

My goal (and I assume every other addon dev) is not to create headaches but to create new possibilities.

Sorry for causing all this drama guys...

This used to be a quite productive thread about 3D features in the engine, I really didn't think this would happen when I posted my first message.

I think it's best if we move this brand new discussion to a new forum thread as I really don't wanna clog the interesting discussion that was happening up to that point.

construct.net/en/forum/construct-3/general-discussion-7/editor-sdk-editor-tools-sdk-v3-187521

Everyone can go back to discussing cool 3D features and anyone interested in talking about the SDK stuff please move to the new thread.

Hi, I opened this thread for any further discussion on whatever happened in this thread:

construct.net/en/forum/construct-3/general-discussion-7/gdevelop-5-6-adds-real-time-187468

Quick recap;

Someone in the thread mentioned that it would be nice to have editor tools to allow 3rd party addon developers to extend the editor which in turn would allow creating powerful tools such as a 3D scene editor.

For the record this is also a stance that I hold as a 3rd party addon tool. I have also spent a LOT of time in the past making my own 3D scene editors, working on 3D tech in Construct and I made a 3D game where one of the core principles was pushing the engine to its absolute limits when it comes to 3D.

Ashley replied that he thinks making the editor UI extensible would represent a far bigger amount of work to do than just making the 3D view themselves, which I can totally understand. He went on to explain the several hidden challenges that would arise from making such a system, and how in comparison they've already done a good chunk of the work to get a 3D view working in the layout editor.

When I was made aware of this thread I thought I should mention to Ashley that I had actually been experimenting with a 3rd party solution to make editor UI extensions. This is a thing I have tried to do for years and failed to achieve in any satisfying way. In the past I kept running into issues that would make the system either too unstable, too hard to implement or too painful to use for end users.

Recently however I actually managed to break through all of that and I implemented my own system in a way that I though was very safe and very satisfying:

github.com/skymen/editor-window-manager/blob/main/docs.md

I even made 2 addons experimenting with this new system and found it to work really well. My plan was to then reach out to devs to get them to mess around with it, and then to reach out to Scirra to let them know about this addon (which I did on social media)

Admittedly, Ashley never saw my tweets (or blueskies I suppose) because he appeared to be very surprised about it in that thread, and immediately entered panic mode and talking about implementing a sort of SDK V3 to prevent addon devs from doing what I had just done.

SDK V2 was a very very painful time for pretty much every Construct user and Construct addon dev and it still very much is to this day. So throwing around threats of an SDK V3 so lightly unsurprisingly annoyed a bunch of people, as this is seen as Ashley actively undermining and disrespecting the time of addon devs such as myself who make tools (often for free) for the Construct engine, which a lot of users then rely on.

What to do now

Ok so now that we're all caught up, I have opened this thread so we can all discuss this issue in a civil way to try and avoid any further drama.

Ashley

Small update;

After deploying the quick fix I made on a few games, it doesn't seem like it has solved the C2P issue at all despite the fact that there was a good chance it could.

I'm still investigating other possible avenues.