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

Ashley

I generally avoid addons due to the chance of losing support... but just used Skymens change FOV addon to add sniper rifle zooming. (Everything else so far is all vanilla c3)

Does changing FOV at runtime count as internal hacking or is there a chance this can be added to the main build of c3? 🤔

In an ideal world, I wouldn't touch third party addons with such a risk attached to them, but I want to make the game that I envision, that's what matters most of all.

There was a missing setting that I mistakenly reported as bug (as it was deemed a feature request). It's not an big feature, just a setting not exposed.

Might get lucky and post the suggestion and it gets upvoted, but what if it's a niche feature, yet required for my project? No chance. It seems risky to "wait months and it might get added".

But then I contacted an addon dev and they solved it within minutes! But the solution uses undocumented stuff and they warned me of the risk. But, it solved my issue, and I can now continue making my game.

The addon dev is my line of support for this solution. They warned me of risk, I know to go and pester the addon dev if a C3 update breaks the solution they gave me.

Would always immediately switch to the Scirra-provided solution if it gets added.

Single features changing or even disappearing is something entirely different to obfuscate all internals at some point.

And that was the question, "is it your plan to obfuscate all internals at some point?"

That's a big difference in quality and quantity.

Some companies strive to keep the community together and cherish community creators (addon devs in this case). Looking forward to seeing more of this from Scirra.

We already lost a lot of addon developers when C3 was new-ish and there were some arguments on forums about how locked C3 is vs C2 and a lot of other things.

One of them was rexRainbow who got fed up and moved to phaser where he's doing an amazing job.

Why couldn't this be for Construct 3 instead???

Dear Ashley,

Sure everyone knows that the definition of unreliable software engineering is, well, this topic. But when you cut off people's access to engine internals like you do right now, it makes it almost impossible to integrate with the engine. It takes me 3 hours to write a script that displays text! At least let people control the runtime, just not the engine itself.

A huge issue, is that when a feature is missing, there is no way to work with Scirra to get it added. no matter how simple or complex. There is no roadmap, no dialogue or discussion, and it has to be "popular", regardless of arguments to its necessity.

I always figured that if you could argue that a missing feature was absolutely crucial in order to do x, y, or z, and not just a nice to have item, that Scirra would add it, but they don't necessarily do so or it takes years. Even if you have the code to do it.

I would add, I would be totally psyched if the interal API broke because Scirra decided to modernize the architecture, add extensibility, and provided better eventsheet abstraction, and modularity. But simply breaking the internal api to obfusicate it, for the stated reason to avoid users getting hurt is so fundamentally backwards it hurts.

The only reason users engage in internal api calls and other hacks is because of a fundamental lacking on the part of c3.

Also, sometimes using the internal api is as simple as:

C3.MakeFilledArray

Because why would I redefine that functionality when every official behavior is also using it.

Option B in that case, is do more work and I'd prefer to do no extra work, unless I have to, ergo internal api call it is until it breaks.

Ashley I've always tried to create more complex plugins, but the SDK as many had mentioned, is too basic. If we'd like to incorporate our plugins through the "official way", I'd suggest you guys invest some time in documenting better the SDK and extending the features we need to use. For instance, if I'd like to create a specific plugin to follow bezier curves paths, I can't implement the "handles" because there's nothing documented on how to properly extend the editor, and not only this. We can't integrate our plugins with the custom tweening API you have because those features are not documented either. So please, consider investing some time to enhance the SDK in general, many other engines have a robust documentation allowing devs to create those features not available.

I can't imagine the SDK ever being flexible enough to allow addon devs to provide solutions like e.g. changing the FOV, because if Scirra puts the time into it they might as well simply add that feature themselves.

Or the ability to control the sampling mode and fullscreen scaling quality on a per layer basis. So many times I wanted to have a small scale render for automatic pixel perfect visuals and low cost for effects but also needed a high quality HD render for readable text.

There will never be an SDK flexible enough to providing these things that can't be worked around with other means and that Scirra would never add themselves if I made a feature request for it.

I'm not great at art and for me it opens up a whole host of projects that I put on ice because I wasn't able to use that art style without readable text in game and for menus.

If they obfuscate all internals, those (and future) solutions to my problems are simply gone, Scirra wont provide them, SDK wont fix it.

And for what, for the possibility that it might stop working in the future?

I rather have a period where a hacky feature is working than it never being available for me at all.

Every commercial game eventually sticks to one C3 + exporter version combo anyways, and that's not just a C3 thing Unity, Godot, Unreal, every game developer does this.

So you can guarantee the Runtime API won't become like the Editor API in the future where only the documented exposed stuff is accessible while the rest is obfuscated and impossible to use ?

The point of the warning is: we reserve the right to do that! You should not be surprised if we do, because we warned you.

People messing with undocumented internals causes disasters. This has happened. Who gets the blame, takes the reputational damage, and has to spend hours picking up the pieces and helping desperate customers whose projects are ruined? Us. How do we avoid that ever happening in the first place? By enforcing a properly supported API with language-enforced encapsulation. The fact the runtime does not already do this is in my view an architectural mistake, and we are continually running the risk of some change causing disaster. I would like to fix this architectural mistake (as it largely is for the editor, so we have removed the risk there), but I don't know if or when we would do that. As ever we are extremely busy and have to constantly prioritize lots of different work. If we did do it, I promise that we will try to do it in a responsible fashion, slowly rolling it out gradually in the API over time and where feasible fixing compatibility issues as and when they come up; but as the warning says, we reserve the right to say "sorry, you shouldn't have done that".

To be clear, obviously I don't want to make one big change that breaks everything deliberately - that would be irresponsible. But the problem is this could happen anyway for some other reason, such as simply by accident, or due to some major upgrade. In general the longer you leave it the worse the compatibility problems will be, so in general, the sooner we can bite the bullet and start imposing proper encapsulation and long-term supported public APIs, the better it will be in the long run.

For what it's worth, this is how we develop Construct itself. Supporting software for 10+ years is tricky, and involves taking great care and judgement over every change over a period of many years. We almost never use any undocumented, internal or experimental APIs in any of the other third-party software or services we use, and where we do so, we do it in the most minimal possible way and with the understanding it could be 100% broken at any point in the future and then it's entirely our responsibility to deal with it. In general if we need something but it's not supported, we file a feature request, and go away and do something else. Maybe it's added eventually, and maybe not. But we don't hack it in, because in the long run that's a recipe for disaster, and that's not how you build software that still works 10+ years later.

I think there is a simple analogy for all this: if you use undocumented internals, you void your warranty. If you buy a brand new car with a warranty, but open up the engine and put in a part you designed yourself, you void your warranty. It's the manufacturer's way of saying "we can't possibly support what you've done, so you're on your own now". If the car then explodes and renders it worthless, tough luck, that was on you. Welding down the engine cover so nobody can get to it is however a step too far in the other direction. Being able to access the engine, but specifying what is supported (such as a list of manufacturer-approved parts), is a sensible middle-ground. The software equivalent is: stick to the public, documented, supported APIs, and you're fine; use undocumented internals and you void your warranty, anything at all could happen for any reason, you're on your own, and you should understand that is a real risk and act accordingly.

People messing with undocumented internals causes disasters. This has happened. Who gets the blame, takes the reputational damage, and has to spend hours picking up the pieces and helping desperate customers whose projects are ruined? Us.

This sucks and Scirra doesn't need this headache. But, isn't it a similar situation to any support request that Scirra receives: if a project has correctly-made third party addons and sends it to Scirra to fix, Scirra wouldn't touch these until the addons are removed?

And if the person dissects their project to remove the addon and it happens to fix the issue they had, then Scirra prob would say "that's not C3's fault, try asking the addon dev"?

Yeah there will be the confused individual, much like how people got angry at C3 with that recent Chrome bug that crashed when you typed a function name. Whilst stressful, it's not Scirra fault and the rest of the community stood up for Scirra during this time. Informed people were annoyed at Google, not Scirra.

If there was 0 blame thrown at Scirra from users that are confused about a hacky addon breaking, would that ease this situation?

I really appreciate that we have a last resort to achieve things, sometimes minor things like the 3D FOV stuff. Yeah, Scirra is likely to add this one day especially if in demand and not a major project, but priorities matter and this may be months/years and may not ever come. Feels very hopeful to have a chance to have a feature even if it has a risk of breaking.