Exactly! Yet people is still thinking that r388 LTS is the solution. Ashley already stated LTS won't have support forever... eventually, our long term projects that uses undocumented features won't open.

Astral Ascent is still being developped on r232 or a version near to that. They locked the version more than 3 years ago and it's still working out for them. An LTS would provide updates for NW.js, SDK updates for mobile, and necessary security fixes and this would give us even more time.

So, with an LTS, you have 1 year until SDK v1 is deprecated, then that last stable gets supported for 18 to 24 months according to Ashley, then you can still keep using it for as long as you want. That's a minimum of 3 years where nothing will happen. If we assume Astral Ascent is a viable scenario (3 years working on an unsupported version with no issues) then you have 6 years ahead of you.

What Ashley means, and has always meant with "stop supporting" means stop giving it updates in the latest versions of the software. Every single "unsupported" feature Construct 3 has ever had in the past are still perfectly accessible in older versions. Why would you assume they would feel the need to retroactively change more than 350 releases of the engine to nuke all traces of the old SDK? That makes zero sense.

With his latest reactions, what's the real guarantee that he won't change his mind later on. This whole SDK v2 thing came from a simple question to access engine internals 2 months ago, which suprinsingly rushed Ashley to launch v2.

This is false. The SDK v2 has not magically appeared in Ashley's mind 2 months ago. It was definitely the trigger for doing it, sure, but he has mentionned the idea several times in the past few years. Nothing Ashley is saying now is new, and he's always said it would happen at some point in the future.

Again, I understand being annoyed and frustrated, but don't make up things to be mad at, and don't form facts from conjecture. This really just fuels more negativity, spreads misinformation which makes other people panic, and it makes discussing the issue harder for both addon devs and for Scirra.

Past a certain point of noise and anger, Ashley will just close the gates of communications and nothing will have been achieved. This has happened in the past, and it's counter productive for absolutely everyone.

If WebView2 becomes available on Mac and Linux - we won't get it. A new version of NWJS is released (which requires updated Steam plugin) - we won't get it. Scirra adds Switch export (haha, I know) - we won't get it. Google or Apple introduce some breaking change - we won't be able to export for mobile. And so on and so on.

WebView2 and NW.js exports are fairly easy to do on your own. You can just download the releases from their websites, export to HTML and put your HTML in the correct folder. If push comes to shove, you can just keep exporting with your own stuff.

NW.js export versions are not tied to editor releases and older versions should still be able to export to latest NW.js because the list gets fetched when you start an export.

Steam plugin compatibility can be done on your own by replacing the prebuild files and you can get them here: greenworks-prebuilds.armaldio.xyz

For Google/Apple changes, if you mean SDK changes that would be tied to 3rd party addons (i.e. Chadori in this case) and not Scirra anyway. Agreed that this does make it harder for addon devs to keep supporting old versions, but in the absolute worst case, nothing prevents you from just opening Chadori's addon and making the changes you need to do in there. From experience digging in there, Chadori's code is pretty well put together, so even if you don't know a lot about addon dev or SDK dev, you should still be able to find your way around inside of it.

For OS version changes, I am not very knowledgeable on mobile exports, but if you don't go through Scirra's server it should be doable to make your own thing. And I think the minimum supported version is a value to change in the app manifest? Anyway, this one I don't know for sure because I'm not a mobile dev, but everything else you can reasonably just keep doing it by digging in the right places.

Is it slightly more painful? Sure. But it's also still doable AFAIK.

I can't go to the an older version of construct because sdk v1 will be totally retired

No one has ever said anything about older versions ever becoming unaccessible.

In fact, Ashley has seemed fairly keen on providing an LTS version to keep compatibility for the last stable that supports V1.

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

if your worry is that you want to keep opening your projects in r388, you will still be able to do that, in the same way you can still open Construct 2 projects in C3 if you go back far enough in the releases

I understand being mad at this, but I really want everyone here to be mad for the right reasons, so make sure you understand what's going on. Otherwise all you do is create noise that makes the communication muddier for everyone else.

You are launching an Addon SDK v2 with an incomplete API and blaming plugin developers that we do not cooperate.

The new SDK is not even out of beta and has had a single week of updates, so IMO it really does not count as "launched". Missing features and requests are being added to the feature request board. If you need a feature, add it there please.

Once the SDK reaches stable in a few months, you will still have a full year to port the addons and request any missing features you might need. Sure, it's a pain to port the addons, but it's not like anyone is asked to start porting immediately. If the LTS does happen, this can buy everyone even more time before they absolutely have to update.

I'm gonna give one last thought on this subject. I personally think there is a huge difference between this, and what happened when C3 released, or with C3runtime or the modules change. For one the modules change often implied very minor tweaks so it does not count IMO.

For the two other cases, the changes were indeed drastic, but they also came with MASSIVE benefits. Everyone happily obliged despite the required effort specifically because there was no debate on whether the new thing was better than the old thing outside of minor technicalities.

Did we lose a few features in the move each time that made some addons impossible to port? Yeah, sure. But in return we gained a lot more, and C3 has evolved way beyond what we were hoping at the time.

My main worry with SDK v2 is not that it is a breaking change, far from it. It's that it's a breaking change, and so far I am unconvinced that it actually solves the issues it's trying to solve.

I can definitely see a scenario where everything turns out fine, and it actually leads to better cooperation between Scirra and addon devs, and we end up with a much cleaner addon ecosystem overall, but this relies on significant effort and goodwill from both parties. I wanna thank Mikal and EMI INDO for leading that march, by suggesting improvements to SDK v2 and upgrading the tools we use to be compatible with V2 already.

I personally don't have much time to contribute anything meaningful just yet as I'm busy with a billion other things, but I genuinely hope to see things move in a positive direction by the time I can.

At least, this is a good time to demonstrate the significant value provided for free by the goodwill of the people in this community. Many people (and not only addon devs) are working hard in silence to make Construct a better engine and to make its community more welcoming, and often don't get a lot of recognition for it.

I guess you haven't had to deal with desperate customers begging you to fix their ruined project and been unable to help?

I've been doing consulting work on Construct project for many many years. Dealing with panicked developers begging me to help them fix an issue that might kill their games is a thing I do fairly often.

Also, as a 3rd party addon developer, this is also a thing I do, and I've had to deal with it most of the time for free and on my free time.

Please, please, please please please please don't do that.

Please understand I am not saying that to make you panick, I am just trying to explain that things often take the path of least resistance, and with the way v2 is currently designed, I believe that this is a possible outcome that might happen.

Again, I will always do my best to cooperate, but I cannot tell you with a straight face that no other dev will ever attempt this.

The downside of accessing engine internals is ruining customer's projects.

Also, please take into consideration that often not doing these changes might also mean the end of the project as well. If the "good" alternative means rewriting large chunks of a game's system which might take months, then it's just not going to happen. These developers are always on tight deadlines, and often with publishers looming, or with player sentiment dwindling, which means that it's often perceived as just as bad.

Also, most of the issues regarding possible long term failure in the long run can be addressed simply by asking the developer to stick to a single Construct 3 version. This is also why I've requested multiple times in the past to let addons access the current version number to be able to properly gate against long term failure.

Even then, the more I think about it the more I realise that the way addon SDK v2 is designed right now can only lead to more issues, or less addons.

In the future, when addon devs will inevitably reach the same problems we've faced with v1 (aka feature exists in C3 but is undocumented because arbitrary reasons, and Scirra doesn't want to add it because of other constraints) we will be left with only radical options.

For example, I recently made a SetFOV addon that contains essentially 4 lines of code. These same 4 lines of code are now in C3, but at the time the only way to do that would have been to access runtime internals.

For such an addon, the new way to do it according to the ideal design is to write my own camera system. However, the camera system in C3 is deeply tied to the layout system and the canvas renderer. So I need to rewrite those as well.

So now, to be able to change the FOV of my game I am left with 3 options:

- Beg scirra to add it

- Do even more aggressive engine hacks

- Write my own renderer

None of these options are good. None of these options are workable.

Let's take another example:

In my addon Reset Variable, I access the class that manages the variables inside of C3's event sheet system. All variables (global, local, static) have an internal "reset value" function, but C3 only exposes an action to reset ALL global variables.

There is no way to reset ONE variable, and there is no way to reset local variables (static or not). Which means the engine has a feature that exists, works and is just there, but does not use it at all, and does not want me to use it.

With V2, I am left with the following choices:

- replace the event variable class with my own class that gives me access, which is a BIG engine hack

- write my own system that, every tick, tracks the value of event variables, stores initial states, and lets me set their values to the stored initial state. This would create a lot of issues related to state sync, because there is no way to be 100% sure the value I am currently holding is correct.

- write my own variable system that is completely decorrelated from every other feature in C3.

Again, none of these options are good, which means the only solution is to not make that addon.

Now you might think "oh well its fairly easy to do this with events, just use another variable" however if you're doing this on a project with several hundreds of variables, there is no way in hell this will actually be feasible. And it's especially a bad idea knowing the feature is already there and works perfectly fine.

One last example:

In my addon LocalStorage Snapshot I am trying to solve an issue where a game has every system deeply integrated with LocalStorage and now needs to save and load everything to and from a file instead.

What this addon does is use the undocumented features C3 has to get all the data currently saved to C3's localStorage system, package it all in a JSON string, and allows me to load that JSON string back into the system.

The only way to do this with V2 would be to copy paste C3's localstorage system on both worker and domside and mess with the final indexedDB it saves to and pulls from, which might create conflicts. Also, if at any point in the future, C3's localstorage system changes, my addon explodes and creates issues whereas the first implementation has good chances to keep working, and even if it fails, it's very likely it's just a matter of changing what functions to call which is far easier to maintain that to rewrite the entire thing.

These addons have all been made and published to solve very real problems people I've helped have encountered. The solutions are far from ideal, sure, but with addon SDK v2, the alternatives become far worse, and IMO, would lead to way bigger issues down the line.

It reminds me of how back in the Construct 2 days people would copy paste addons, change 5 lines of code and republish them as "Text+" and that lead to issues whenever the main Text object would get a new feature because we'd now have 2 separate codebases to maintain.

In Construct 3, this issue was largely avoided because the engine internals made it easy to do these simple changes while keeping the main code base the same, and while keeping the risks of failure relatively low. Losing access to this means the only alternative will be to go back to how things were done in C2 aka copy chunks of the engine into your addon just to be able to access one feature, or change one value.

The issue is not "not being able to customize the engine as much".

The issue is the lack in alternatives.

Currently:

1) the documented API is not broad enough to cover every use case, especially for niche but very important features

2) The ideas board is moving way too slowly to keep up with the needs of everyone, and there is no roadmap to even be able to tell in what vague direction Scirra is moving

3) There is no proper channel of communication between Scirra and power users, so there is no way for us to help even if we wanted to.

For years, this has left us with our only option being ignoring warnings and just using undocumented features.

Let's take a simple example that has been hammered a few times in this conversation: my SetFOV addon. The addon is something like 6 lines long. C3 perfectly supports a variable FOV by virtue of it being editable in the editor. Changing it at runtime is as simple as updating the FOV value and updating the camera. This feature has been asked repeatedly pretty much ever since the 3D camera was released, yet it has still not been added by Scirra.

In the future will we just be expected to sit down and possibly wait years for a feature so absolutely basic to be added, with no good way to even tell if it might be coming until it just appears one day?

90% of my undocumented feature usage is for features you have partially exposed and so that I know you will absolutely maintain, but where the specific thing I need just isn't exposed for some reason. This is done with the knowledge that in the worst case scenario you might just rework the whole thing but you're not gonna remove it because the feature exists in the software (i.e. I know changing the FOV will not suddenly stop being possible because you completely overhauled the camera system, it will just need to be done differently)