Is there a method to access engine internals from JS blocks?

So, as I said before, we are not actually going to remove all undocumented features in the next release. However we will move forwards with a plan for a v2 SDK over the next year or two, which should give enough time to design a suitable SDK and deal with the inevitable difficult backwards compatibility issues that come up. Let me be clear: we did not have to do this, as we reserved the right to say "tough luck". However as it is clear this is untenable and obviously unpopular, we are promising to do the necessary work to make sure this transition goes smoothly. This does mean designing a new API in co-operation with the addon developer community, and I would hope this ultimately ends up a comprehensive, capable API that does pretty much everything addon developers could reasonably want to do, short of unfettered access to the internal engine. I would ask for co-operation during that process so we can end up with a reliable, robust, maintainable SDK in the long run, and not the risk of disaster that we are constantly running at the moment.

Ok that's a bit better. (The part I quoted above I mean... in disagreement with everything else as explained in previous messages)

Still worried about this decision, we're just loosing possibilities with no benefits, we'll depend on the feature request process for everything not knowing if and when we'll be able to fix our issues and overcome the limitations we'll face...

But I think everyone here is hoping for a cooperation in the transition process, as you plan to remove access anyway. Please let's not make it a Scirra VS C3 users again. You can't just hurt our trust and faith again and again. I think we're hoping to see notable improvements in the communication and the way our feedbacks/concerns are treated.

Open source is not the same as compatible with hacking the runtime. In a native engine, you could do things like identify memory addresses where useful things are and overwrite memory addresses with custom data to achieve new things. Anyone who knows anything about reliable software engineering will be cringing at that idea because it is obviously a disaster and you will end up with a total nightmare with everything breaking all the time. The main reason people don't do that with native engines is because it's particularly difficult. JavaScript lets you do something similar, but more easily. It does not make it a good idea. Again, this is not the same thing as whether or not the engine is open source. It is a matter of maintenance and long-term reliability. Being able to look at the code does not mean that hacking memory addresses in a native engine becomes reliable, and likewise, being able to look at the code does not mean that hacking internal JavaScript APIs is reliable.

I'd say the open source equivalent would be forking the engine and making a bunch of modifications to the internal engine. Now you have a compatibility nightmare as the main branch diverges from your customized codebase. You might try to occasionally merge over changes, but then you might end up with merge conflicts and a huge mess in the codebase. The easiest thing to do is never update the engine. Now it's game over for support - nobody can support your customized engine, and you cannot easily merge in any new features or bug fixes in the main engine. Anybody who has been through this process knows the only good approach is to merge any changes upstream in to the main open source project, so you are still working with the single shared codebase shared and supported by everyone. If you have your own hacked fork, you do so at your own risk, and it will probably end in disaster for you, but that's on you.

The difficult thing for me here is that this is all well-understood stuff learned over decades of the software industry. But right now people are already doing it with Construct, it looks like it works, and why would Scirra go and break it? It's because in the long run, it ends in disaster. This has already happened with Construct 2, and it is obvious to anyone else who has maintained a software platform for a long time, but it may not be obvious to people tinkering with the engine right now. So you can downvote and argue all you like, but our responsibility is to make sure the engine is reliable and will continue to be reliable even a decade ahead from now; we know what that involves; and we are advising people accordingly.

The exception to all this is the documented, supported APIs. If you use those, we promise to support them indefinitely. That's why part of my advice is to stick to those.

Totally agree with Ashley POV. Is thanks to this experience and POV that Construct supports old project way better than the competitors.