Addon SDK v2

I am of the belief that, overall, you can make whatever 2d game you need with whatever system the game needs, whether stacking buffs, equips, anything. Maybe not one-click out of the box, but, idunno, I don't touch JS and yet to hit any dead ends with some wacky ambitious ideas. I'd be curious to know what isn't possible in events or sdk-safe JS that can't be done for making any 2D system. Or is it to eek out more performance by using these undocumented js functions?

Different story with 3D, I can see the benefit of, say, loading a 3d object, which is only possible with 3rd party addon.

Same old arguments from Ashley.. Over 12 pages he's trying to convince us that his priorities — limiting features for easier support — should be ours as well.

Construct creators have a long history of not listening to their customers. C3 will remain an excellent tool for education and hobbyists, but sadly it will most certainly lose its potential as a serious engine for professional game development.

Limiting features for easier support - it's features that Scirra relied on addon devs to not touch, unsupported stuff, hence Ashley's repetition of the "red warning box" that was ignored, which yeah, fair, tinkerers be tempted, but now there's a bountiful selection of addons available to download that did ignore that red warning box. I made post about FPS limiter and not noticed bugs, I just read the description of the addon, didn't realise it was plastered with experimental, may break, has gpu schedule issues. Am I being stubborn by thinking "well OK but I still want it even tho it's literally a hacky addon where the dev says they're not sure why it is buggy", I think I am being stubborn, there's something incorrect about this addon, otherwise Scirra would have added FPS limit a decade ago.

"Not listening" feels wrong, I've been here for over a decade and that's one of the great things about this engine, the lead dev literally responding to all sorts of queries. Definitely could be improved but to say having a history of not listening is not true. Ashley not changing his mind doesn't count as "not listening", he's written and listened to so many woes in this thread. Nice to actually hear why this is happening and it's not a money grab thing like unity and we sit on our hands wondering what happens next, you can email Scirra and always get a response. They listen, doesn't mean they bend over.

C2 was open source briefly, and Scirra made decision to close source, THAT should have been the writing on the wall for anyone interested in open source, and has been ever since. Cool, whatever, maybe people left back then due to this, they wanna choose what they do with their business and make a living however they feel was best, much like we want control over how we handle and sell our games. I hated sub being introduced, I hate the sub now, but it gives me value because the event sheet editor is top tier.

I totally understand the concern and will be affected too as I use a bountiful amount of experimental addons (not even realising they are experimental because missed the descriptions) and pay my sub too, but now this has been known and people are still going apeshit, goddamn the entitlement echoed by many is just trash.

How about being productive cooperate like Scirra said they would, hold Scirra up to that, make a push for those sdkv2 things. Suggestion platform barely gets more than a classroom of people voting on things, where's the demand and community cooperation?

LTS exists if there's no possible workaround. Not ideal, I fear rolling back, but that's a form of literally listening to the community.

And, above all, make your goddamn games. Hobbiest and education? I'm neither, and have not hit a dead end with designing games. Prove me wrong.

I am of the belief that, overall, you can make whatever 2d game you need with whatever system the game needs, whether stacking buffs, equips, anything. Maybe not one-click out of the box, but, idunno, I don't touch JS and yet to hit any dead ends with some wacky ambitious ideas. I'd be curious to know what isn't possible in events or sdk-safe JS that can't be done for making any 2D system. Or is it to eek out more performance by using these undocumented js functions?

Jase00 - ugh, I wrote a novel. TLDR at the bottom, but I'm not sure it makes sense with the context. Nobody should feel the need to read this, but I'll post it anyway. The reason I tended towards using internal api is to increase performance where I could, or avoid repetition. More on that later

I think you are already familiar with some of my complaints, and I'll clarify as best I can. If you have a game with a fairly rigid organization, known ahead of runtime and before devtime, then producing it in c3 is fairly straight forward. Producing a game like Mario is a breeze. Making a game like pokemon, only slightly more difficult.

The stacking buffs example is actually a good one. If you know in advance the types of buffs that can exist, and the number of stats they affect, then making a system for that is easy. When things become difficult is when you don't know how many types of effects will exist before hand(or the number is high), nor the objects that can be affected. Some a problem is best solved by a completely abstract system to accommodate designers future ambitions.

Take mario as an example: We have a character that can walk/run, duck slide, wall jump, and a few other things. Now lets give mario an inventory for items that can alter his stats, and even add completely new abilities. Without deep oop, or ecs architecture, the easiest way to solve this problem is to embed conditional branches in mario's behavior logic that checks for items containing abilities. Not too bad... so far... especially if the number is low.

But now extend that to all characters and allow any character to have any ability. Now every character needs conditional branches. Now keep adding abilities into the game. With new abilities might come the need for new stats, etc... and the base class for characters is getting hefty.

The issue at this point isn't that you can't make the game, Its that you've created a situation where adding a new behavior to a single character requires a deep understanding of all characters and all abilities in the game so far, typically requires modyifying the code base in multiple places, and if you want to remove an ability, you have to remember all the places it has code for it. This becomes unmaintainable. A single developer likely can do this if well organized- but only to a point; and as part of a team - this is nearly impossible if you have two people working on the same system.

The second issue is that every character, from a performance standpoint, no matter how simple, is as complicated as the most complicated character, as every character needs to have a conditional tree for every ability it could posses and the stats to go with it. Every object is bloated with data it doesn't need and this can hurt performance. We haven't even gotten to input support, ai support, or flexible and dynamic stats, etc... which also has to balloon to fit the conditionals. If you take a game like vampire survivors, and require bullets to also have abilities or dynamic effectors, you now have a code structure that kills performance so completely you have to do something about it.

So the need to change can be 1 or both. Poor performance, or difficultly adding, maintaining, or removing code.

Enter ECS or OOP. The problem outlined above is a fairly classic problem and there are multiple ways to deal with. My favorite is ECS, but i'll cover both and why they aren't great in c3.

In either system, the goal is to create a framework that efficiently facilitates adding functionality to objects arbitrarily at runtime, and reduces the complexity of maintaining and creating new functionality in this environment. Good for the game, good for the developer.

But construct makes this incredibly difficult, as it can't natively do OOP or ECS.

As will be pointed out, you can code javascript. Construct has a great event editor and that is a major selling point. It is fast to iterate with and I like it. That is why I use it. But coding in c3 is more verbose and difficult to learn than pretty much any other engine I have used. I started in c2, so I should be biased to it, but I am not. Creating addons is painfully slow compared to creating editor integrated scripts in unity, and simply coding bare functionality in c3 takes more writing to achieve the same results in unity. That isn't to say some people may still prefer c3 in this regard, but it is a factual claim to say it takes more typing to get the same thing done in c3 than in a program like unity. Other game engines are much better organized at a architectural api level, so the power and flexibility is also typically higher than in construct. Compare the unity collision api to constructs and you'll get a simple overview of just how tiny construct is in comparison.

OOP in c3:

Families currently allow only one layer of abstraction in construct, (since you can't nest families in families), so to create a better OOP system in events, you have to get creative. You can simulate deeper structures by adding objects into multiple families, and then use a uid picking framework to select multiple families from a single object. The organization of these families and which objects go in them has to be documented and remembered by the dev. You then can assume (as the dev) that any objectA in some family will also be in another family that it "inherits from". If you want that base functionality, you then pick that family by the object uid you currently have picked. But this forces every object to now require complex picking boiler plate and for each loops (which reduces performance). Worse, you also have to repeat the boiler code events for every level of depth you wish to add for an object, and for every structure you create, meaning the exercise of abstraction isn't itself abstracted - this also creates significant event sheet performance overhead. If you also want inherited custom actions, you now have to repeat the creation of those actions for each family in a tree, and link them together. Every object added will require this boiler plate. The deeper the structure being simulated, the more events per object that have to be run and the more boiler plate you need to set it up, increasing dev time per object added. So even if things were running okay, once you add this system to ease development, your performance may likely go down. It will depend on how many abilities you have in game, vs the average number per object, contrasted to the depth required to simulate OOP. The processing power per empty event is not trivial when duplicating structures like this with nested loops. I have found this method to be cumbersome to set up and don't recommend it. It creates less complexity to add and modify abilities or effects, but is itself difficult to maintain at any scale and tedious to expand.

If construct allowed families to inherit from families, this would be a non-issue. Another solution would be containers, but containers don't work with families. So you have a weird dynamic where you have to pick your poison.

ECS

:

Setting up ECS is easier imo, but similar to simulated OOP, it requires repeating boiler plate for every system you need to handle ECS. In a nutshell, you have to use some OOP style systems like described above, but you use it only for attaching the ecs behavior to objects. The depth of the oop is shallow, but it still requires boiler plate per added object type. Basically you create a family for "systems", and family for "components". The raw requirements for these families is that the system handles component addition and removal, and routes functionality to the components. You can connect this via UIDs or create a parent/child graph and use that. In a platformer example, a system could be a character handler, and a component would be the ability or behavior. The handler performs the abstract task of routing input and state to the active behavior. Some people use state machine type logic where the components define transitions to other behaviors, but I prefer the transitions to be handled without a component specifying the components it transitions to.

At the end of the day, for ECS, you will have to use a Foreach loop for every system, and then loop through the components, running various custom actions like "Check" "Enter" "exit" "update" etc... The overhead of the small scale OOP to pick related families, dictionary lists of components, etc... and then dynamic routing of state/input through components, means that the performance overhead of each system scales with its complexity and its possible to achieve better performance than the simple/basic branching conditionals if the project is complicated. Also, adding functionality is as easy as the system is designed for, and allows the functionality to be self contained. apart from the fact that you still have to boiler plate every object.

In other words, if I want mario to be able to do a ground pound one day, I clone the object type "BehaviorComponentsTemplate", name it "Behavior_groundPound", copy the template eventsheet for the boiler plate (replacing appropriate code), and then manually add every action needing overridden, and then add in specific functionality. The actual functionality is faster to write than setting up the boiler plate. Then add an include in the correct event sheet and go.

The payoff? All the functionality for ground pound is now a component I could add to any character, without having to add conditionals, and all contained in one place instead of being in multiple locations.

The downside: This system requires a lot of nested loops and picking so you do take a performance hit over a manually crafted rigid system. Any character that has rigid abilities should still be manually coded, meaning you now potentially have duplicated code all over or need a simple light weight router system. Again, this is alot of work to set up, and requires ongoing boiler plate management; Meaning if you change the system, you may have to change every single bit of boiler plate through the entire project.

BOOM. That is BAD, BAD, BAD.

TLDR

So basically, c3 forces bad types of programing in order to avoid bad types of programing while solving complex/advanced problems, and the solutions themselves are difficult to maintain or scale. You avoid one issue, but create a different issue.

The takeaway? Construct isn't the right solution for a sufficiently complex project with high dynamic object counts. It literally becomes a case of, this isn't possible, and better off in a different engine.

For my own project, I really wanted to finish a game with construct, so I went from a bullet hell style game with high numbers to a game with fewer but much more impactful threats. It actually turned out to be good for game feel, as it reduces noise and makes choices more meaningful. Each enemy is an intimate threat, instead of one of a 1000.

ugh, I wrote a novel.

Honestly, it's cool, I find this all interesting to learn about and understand, and took the time to read this. My replies come from someone with no experience with JS or traditional programming languages, and simply an event-sheet guy lol.

The stacking buffs example is actually a good one. If you know in advance the types of buffs that can exist, and the number of stats they affect, then making a system for that is easy. When things become difficult is when you don't know how many types of effects will exist before hand(or the number is high), nor the objects that can be affected. Some a problem is best solved by a completely abstract system to accommodate designers future ambitions.

If designed right, couldn't this be future-proof? 2 different ways pop to mind: A data-driven way to handle buffs (i.e. you have an array of "CurrentBuffs" that grows/shrinks, and stores a Dictionary/JSON string within the array that has a list of stats to alter, maybe another dimension for timer so 10x2x1 size array, 10 being 10 different active buffs, Y0 being the JSON string, Y1 being the timer), a loop to iterate and subtract from the countdown timers in the array, but you'd only "apply" that JSON string in a function, so not needing to constantly load the JSON data every tick (e.g. players have instance vars for "Speed_Default", "Speed_Current", then can always mathematically get the final buff result when this function runs by taking the default vars and applying a buff equation). The JSON data can have keys like "Speed : 10", "Damage : 120", "ParticleType : Smoke" and whatnot, to allow you to apply these values to the player upon a buff changing. Overall being the idea of not constantly reading from the array/JSON/Dictionary, unless required such as a buff change/add/end, and a hefty yet tightly designed function to apply all stats found.

2nd idea being same thing but likely worse idea as you later mention conditional branches - An Array but with the name of the buff, and then within events, applying whatever effects based on the buff. This is also future proof as you can always add a new buff name like "Poison" and then add a new line in a function for your "AddBuff" function that checks "Array.at() = "Poison"". Again though, I get this would quickly balloon up into a huge list of subevents.

Take mario as an example: We have a character that can walk/run, duck slide, wall jump, and a few other things. Now lets give mario an inventory for items that can alter his stats, and even add completely new abilities. Without deep oop, or ecs architecture, the easiest way to solve this problem is to embed conditional branches in mario's behavior logic that checks for items containing abilities. Not too bad... so far... especially if the number is low.

But now extend that to all characters and allow any character to have any ability. Now every character needs conditional branches. Now keep adding abilities into the game. With new abilities might come the need for new stats, etc... and the base class for characters is getting hefty.

This, depending on the type of game, could be redesigned - Does every enemy really need to have all the base functionality of the player? Perhaps a fair chunk of it, yes, say you made a platformer behaviour within events and want to apply this to both Mario and Goomba enemies, then yeah I follow the paradigm of wanting to keep it all under one roof - However couldn't a single boolean to say "IsPlayer" with much of the enemy-only code be done within the loop, to dramatically lower event checks? This would of course mean you'd have to pick and choose what works for enemies and what works for players, maybe not ideal in a specific type of project.

Again I'm an event guy, but from what I've gleaned from looking at source code of C++ games, there's so sooo so many booleans checking things, state of player, state of A B C - Could be similar to what could be done here, despite the desire to lower conditional branches, one way or another you have to check some sort of value to determine whether the entity can do an action or not.

The issue at this point isn't that you can't make the game, Its that you've created a situation where adding a new behavior to a single character requires a deep understanding of all characters and all abilities in the game so far, typically requires modyifying the code base in multiple places, and if you want to remove an ability, you have to remember all the places it has code for it. This becomes unmaintainable. A single developer likely can do this if well organized- but only to a point; and as part of a team - this is nearly impossible if you have two people working on the same system.

Would the question be "why would abilities be stretching far across your event sheets"? If it was abilities such as wall jump, double jump, wouldn't this all be in the same area/group/event block sub events? I understand where maybe you need to alter the camera or something for a fast "dash" ability, but then designing this neatly is doable, functions in the general player events to affect the camera (then C3 lets us right-click the function and jump to the function event block, making this smooth to navigate).

If some features do need to stretch everywhere, then yeah it's difficult to navigate. One trick is to have a unique comment that is text that is never used anywhere else, like "@@@WallJump" then pasting this in all areas of all event sheets that are relevant, and then any dev can do CTRL+F, find this string, and the "find" dialogue presents itself as a neat list of all areas to check if you need to edit the walljump code.

The second issue is that every character, from a performance standpoint, no matter how simple, is as complicated as the most complicated character, as every character needs to have a conditional tree for every ability it could posses and the stats to go with it. Every object is bloated with data it doesn't need and this can hurt performance. We haven't even gotten to input support, ai support, or flexible and dynamic stats, etc... which also has to balloon to fit the conditionals. If you take a game like vampire survivors, and require bullets to also have abilities or dynamic effectors, you now have a code structure that kills performance so completely you have to do something about it.

I agree with the balloon moment here, lets take multiplayer game example rather than "players and enemies" as you'd expect to have exact same abilities for multiple players, it does start to impact performance when you have all these checks to do for each player. This is where I feel, lol, even more booleans to "break it down" could help. I'm not a "group disable/enable" type of user, but I often see folks use this and find there's a lot of benefit to performance - I feel booleans give you that little bit more control over things rather than groups, and utilising the booleans as much as you want for each player is a great aid, can reuse whatever you've found from collision checks such as "IsOnGround" across your ability events, even if these checks are later on and such.

Even if it's ballooned into a hectic mess of abilities, all those conditional checks don't need to be checked if a player is standing still/doing this and that. Breaking things down so that a typical tick is just going "Ok, for each player, first player, moving around, so gotta check X Y Z, do this do that, ok done... Next player, only moving right, not near walls so no wall jump checks (and wall collision is baseline check so get the data from the wall collision to help lower addition checks later)... 3rd player, they're in air, against a wall, are they pressing a key, they are, do this, do that".

In either system, the goal is to create a framework that efficiently facilitates adding functionality to objects arbitrarily at runtime, and reduces the complexity of maintaining and creating new functionality in this environment. Good for the game, good for the developer.

(Also replying to general "family" stuff here).

I agree that at face value, you cannot arbitrarily add functionality to objects at runtime - You have to know in advance, yes. And I agree with the family thing, it's not like you can make some families such as "PlayerMovement" "PlayerWallJump", etc, and then dynamically throw any object into these families at runtime, PLUS the downside of having "PlayerMovement" family with all it's instance vars like XSpeed and YSpeed, so then the "PlayerWallJump" family comes in, you cannot affect the vars from PlayerMovement family, meaning UID picking, which I agree needs to be minimal or else you're cycling through many player objects for seemingly no reason just to change a single var. Nested families would be great here.

Dictionaries almost solve this, esp with containers, but yep, cannot use containers with families so you cannot add a dictionary to a family, and definitely we all want to avoid doing "For each player, pick dictionary with var "PlayerUID" that matches player.uid", as then this has to cycle through 100's of dictionaries to pick the correct one, not ideal, almost like doing a 2nd for each loop but worse since the 31st player in the "for each player" loop, sure, it's cycling the players, but the dictionary UID check would be checking ALL dictionaries each time until it finds the correct one (or if it's based on order, then sure the first few players will find the matching dictionary quickly, but then the later players in the loop will be checking essentially all dictionaries).

Definitely room for improvement, feels so close to being attainable!!

At the end of the day, for ECS, you will have to use a Foreach loop for every system, and then loop through the components, running various custom actions like "Check" "Enter" "exit" "update" etc... The overhead of the small scale OOP to pick related families, dictionary lists of components, etc... and then dynamic routing of state/input through components, means that the performance overhead of each system scales with its complexity and its possible to achieve better performance than the simple/basic branching conditionals if the project is complicated. Also, adding functionality is as easy as the system is designed for, and allows the functionality to be self contained. apart from the fact that you still have to boiler plate every object.

I am not so fearful of "for each" loops. I tend to have a base For Each loop that contains all Player functionality, so in my mind, this is cycling each player once per tick - Of course this gets hectic and bad for performance when you need to pick a dictionary or something like I mentioned in last paragraph, in my case I haven't used families so that I can take advantage of containers (Only in recent year, after 12 or so years of Construct lol), having a base "Player" object with a dictionary in container, kinda works like an adaptable runtime-editable version of instance vars, add and remove at any time, keep it small if needed but can expand into a huge list if needed. Again though I do wish families could utilise this, hope we get to see this.

For a more "trigger-based" project, I find I use a lot of for each loops and doesn't ruin performance, mostly because of filtering down the picked objects list and rarely putting "for each" at the top of the event block - Just checked my project and I have apparently 600 for each loops (it's an 8k event project), but few are running "every tick", perhaps I've added them in some events that weren't necessary, but overall has no impact on performance. If I did have many for each loops at the base of event blocks, then yeah this would be hell on earth.

The takeaway? Construct isn't the right solution for a sufficiently complex project with high dynamic object counts. It literally becomes a case of, this isn't possible, and better off in a different engine.

I humbly disagree with "this isn't possible", could maybe agree with "better off in different engine" although for my case, what engine has a god-tier event sheet editor, GDevelop I revisit, but I cannot shake off the opinion of "clunky" and working against me (not to say it's just awful, there's cool features within the workflow), but, I have no completed project to show for this. I have made some great strides being event-only, performant platformer behaviour with custom jump-thrus and Sonic-style physics supporting up to approx 12 active online multiplayer players with equipment that both "applies buffs if holding weapon" and "applies buffs if equipped even if not currently holding weapon". I fear to come across as arrogant, but I note this as more of an explanation as to why I get a bit passionate when folks say performance is bad in C3 and such - I do see the other side though, I imagine if I recreated whatever I've done into Unity/Godot, it would let me have 24 or more players, but the project's goal wasn't to support 100 players, just 8 players was ideal! I'm making a game, not benchmarking (although it's fun to benchmark!). If I wanted a gamemode with a lot of Bot players for the 8 players online to battle, then those bots could be the same "Player" objects, but then can think outside the box to save on CPU, lesser collision checks (always the biggest CPU eater in my experience), hiding abilities that the bots never use in a boolean, or in an online multiplayer case, letting the host be the more heavier collision handler whilst players see a more broken collision bot but gets updated due to syncing from host.

For my own project, I really wanted to finish a game with construct, so I went from a bullet hell style game with high numbers to a game with fewer but much more impactful threats. It actually turned out to be good for game feel, as it reduces noise and makes choices more meaningful. Each enemy is an intimate threat, instead of one of a 1000.

Both projects sound cool - I bet the bullet hell one was a tricky moment, can't utilise Collsion Cels due to being all onscreen and such - I suppose a bullet hell is always a tricky one due to collision checking, almost feels like the type of project where you need to solve it in a minimal way, once you get that right combination of events, suddenly it will all just perform wonderfully, but cracking that sounds like an interesting challenge.

So basically, c3 forces bad types of programing in order to avoid bad types of programing while solving complex/advanced problems, and the solutions themselves are difficult to maintain or scale. You avoid one issue, but create a different issue.

I thought a lot about design patterns within C3, and while I agree with all of what you said, I think there is one major takeaway you're not seeing; traditional programming patterns are never gonna be a good fit for C3 even if it had some of the features you mentionned because I think at the end of the day C3 has bigger flaws than just support for arbitrary design paradigms.

C3 works far better with something like composition where a single family is an isolated feature, and you can compose an object by adding it to families. In this case, family inheritance is still useful because there will still be cases where you'd want some amount of inheritance within general systems.

IMO even with all the features you want, it doesn't answer C3's 2 major flaws that it needs to address before any of this can even be tackled.

- C3 is horrendous at dealing with data. When you have to handle a JSON, I feel like while C3 has some amount of solutions in place to make it possible to do, in general data management feels like an afterthought that was handled by an external addon rather than by a system implemented directly within the engine. This creates a large bottleneck of sorts whenever there is a need to treat and transfer large amounts of data because it needs to be serialised to JSON first, or it needs to be transfered through archaic picking systems that make the code way too hard to read.

- C3 lacks an abstraction system. There is no way to refer to instances without knowing their type and without picking them through the SOL. This means cross family picking is hard, storing instance references is hard, and it's one of the main reasons composition systems fail so easily. As soon as you need 2 families to synergise when they are both being used on a given type, it becomes problematic.

IMO if C3 had a way to store SOL as a variable and do more complex SOL manipulations, it would make C3 far more powerful. Also, if C3 had a way to make cross type families for types that share actions like set position and set size, it would also allow for very useful abstraction to be done.

What I've ended up doing fairly often is relying on JS for complex data management and that kind of inheritance when necessary and using instances as just the visual aspect if it can't be done nicely with events. Still I think it's not a great solution and I wish C3 had systems in place for that.

On further reflection, I'm not even sure the discussion is still about the Addon SDK v2 and encapsulation. It seems to have broadened out in to an extensive discussion about the overall design of Construct. You may discuss that if you wish, including being critical if you really see things that way, but it isn't really relevant to this thread any more, which is specifically about the process of migrating Construct to a new addon SDK and the reasons for doing so.

I suspect this thread has outlived its usefulness anyway, and that further discussion will no longer be productive. We try to lean towards allowing people to freely express their views on the forum, and I'd point out this thread started in May so there have been about 4 months of largely unrestricted discussion with everyone offering their (sometimes strong) views, but discussions like this end up producing more heat than light. As per our Forum & Community guidelines, under "reasons we may lock threads", we do state a couple of reasons that are happening here, such as chaotic changing of subject and repeating the same discussion points in a never-ending thread. On that basis I am closing this thread.

I'm still happy to support any developers who have questions about how the new Addon SDK v2 will work and how to use it. However please start separate threads for those queries, or for any other general discussion points. I am not particularly willing to continue to discuss the rationale for the move to the Addon SDK v2 any more as I've already made our case ad nauseam in this thread; I will refer any future questions to my existing answers here, and if you are not persuaded then I suspect nothing I say will do. My previous post will probably suffice as my last remarks on the subject, as in summary we are moving from an unsustainable SDK that will end in disaster, to an industry-standard approach used by all professional software. I am fully aware of the disruption this will cause but I believe it to be absolutely essential for the long-term future of Construct, and so I am asking for the co-operation of addon developers to help the transition go as smoothly as we can manage. We have also introduced LTS releases - the first one came out today - in part to allow for more time for the transition to happen. This idea mainly came from feedback in this thread and elsewhere, so we are listening and thinking about what we can do to try to make things go better where feasible.

I will keep the original post updated with the current status of the Addon SDK v2 for informational reasons. Any other key updates I will post separate sticky threads for in this SDK forum.