A special request: If it's all the same, please just don't ever remove support for SDK v1 addons

Not favoritedFavorited Favorited 1 favourites
  • 4 posts
From the Asset Store
Controller Support ,TouchScreen Support , Keyboard Support , Action Platformer, Lots of Animations
  • A special request: If it's all the same, please just don't ever remove support for SDK v1 addons. I don't know the technical details of why this is supposed to happen in a future update to Construct 3, but would it be alright to just let SDK v1 addon support remain permanently, so as to not cause needless problems? Spriter is such an awesome software, but as of yet only uses SDK v1. I just asked BrashMonkey if they can update it to SDK v2 as soon as possible, but I'm prone to anxiety, since my entire (aspiring) career is completely dependent on the combination of Spriter Pro and Construct 3. I don't think Spriter 2 will ever happen(?), and I wouldn't learn whatever Construct Animate is, after mastering Spriter, and all my work is already done in Spriter Pro and would be ludicrous to attempt to rebuild, as that work took years of pain and effort. Just in case BrashMonkey has no intentions of updating Spriter 1 to SDK v2, please don't needlessly remove SDK v1 support. Spriter is more than enough reason to let it be. I plan on using both Construct 3 and Spriter Pro for literally years to come, with no exaggeration. Please just let Spriter continue to function correctly permanently.

  • you must lock your project in SDK v1 with the end url rxxx

    example: editor.construct.net/r440-2

    If there are new features either from the SDK or from the editor above the rxxxx you locked, you cannot use them.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I'm afraid SDK v1 addons cause catastrophic compatibility problems and the risk of keeping them is unacceptable. Due to the lack of encapsulation, addon developers have written lots of addons that manipulate the internal details of the engine that were never meant to be used. If I merely rename something or move something around to better organise our code, it can break addons, causing problems for hundreds of customer projects, who then all contact support and blame us for breaking their project in the latest release. This has, and will, happen over and over again. In the long term all parts of the engine eventually change, and so eventually all such addons will probably break. It will leave us in the position of having to either stop making improvements to Construct, or break lots of projects.

    This is thoroughly understood stuff in the software industry. For these reasons no other professional tools allow unrestricted access to internal engine. The industry standard for decades has been to use encapsulation and enforce that only a specific documented API can be used. Then you can ensure everything keeps working in the long term, even when doing major internal upgrades, and even after the addon developer left the community many years ago. The only reason Construct ended up with a lack of encapsulation is historical reasons - basically JavaScript did not used to support it.

    I know this will be a painful transition but unfortunately I believe it is absolutely necessary to make Construct reliable and trustworthy in the long term. The next LTS release will be supported for another 18 months so there is still a long period of time that SDKv1 addons will still be continued to be supported in LTS.

  • Read the last posts here: brashmonkey.com/forum/index.php

Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)