Addon SDK v2

Replies Disabled
1 favourites
From the Asset Store
DATA+ (Addon Pack)
$22.50 USD
Data+ is the best Data Management solution for Construct 3. It contains 4 Addons (Plugin & Behavior).
Overboy's avatar
Overboy

    Ashley

    As far as I understand right now (and I could be mistaken) but based on previous conversations it seems the Event Manager classes in SDK v1 will not be supported in SDK v2?

    construct.net/en/forum/construct-3/plugin-sdk-10/sdk-v2-183377

    As a response only the looping condition was mentioned, but what about other use cases of using the Event classes?

    I was going to also bring up what piranha305 mentioned as that is currently an issue at the moment for me, and frustration there led to my last few posts. It seemed from other forum posts there was no intention of porting over the event sheet classes.

    -----

    Honestly though, It still seems like letting sdk1 slowly vanish organically by virtue of blasting warning signs not to use sdk1 would more than solve the problem, we could have cake and we could eat it too. Anyone using sdk1 gets no support. Warn them in the editor on load, etc... problem more than solved. We all move on to sdk2 and live happily ever after.

    I just don't the current move. You say this way solves the issue of people coming to you crying when their project breaks, but all the crying we are doing here is completely ignored. Its like poisoning the beehive to prevent hornets from attacking them, who cares about any of the bees. The fact is, there will always still be hornets tomorrow, so even the bees of tomorrow won't be safe.

    I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    Then once again, we will have a bunch of plugins that will all break just as soon as each update happens and we will be right here again.

    As a response only the looping condition was mentioned, but what about other use cases of using the Event classes?

    There were no other use cases for those classes other than for looping conditions, which are still supported in the Addon SDK v2 but with different APIs. If you have a different use case involving those classes which is still not covered, please let me know and we'll consider options to add a new API to support it in the SDK v2.

    Honestly though, It still seems like letting sdk1 slowly vanish organically by virtue of blasting warning signs not to use sdk1 would more than solve the problem

    Again, as I explained earlier in this thread, the entire problem we are facing here is in part caused by addon developers ignoring a big red warning in the SDK documentation saying not to do something which lots of developers ended up doing anyway. People ignore warnings. We're certainly not going to make that mistake again.

    but all the crying we are doing here is completely ignored

    Again, I've already spend many posts and thousands of words in this thread explaining in as much detail as possible our rationale for this and why we feel it is absolutely essential despite the serious disruption that we are keenly aware it will cause. If you describe this as being "completely ignored", then I'm afraid I must point you to the Forum & Community guidelines, which include under the section on bad faith discussion:

    Accusing people of ignoring you or not caring, after they have tried to help

    Ashley

    I Added a feature request, those event sheet classes have function to manipulate the SOL, maybe those are not needed verbatim, but some interface into the SOL would be a good use case

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

    Instead of manipulating the SOL from event sheet classes, it might make more sense to do that per object class instead.

    I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    It's probably best not to do this, this could incite more stricter changes to the API's which would not help anyone, and just create a worse ecosystem for construct, and create a worse relationship between addon devs and the folks making the engine.

    I think there is plenty of time, to migrate and test, and request api changes. before v1 gets sunset. I worry statement like these will just antagonize the dev's instead of bringing positive change.

    Ashley - Sorry, I donʻt seem to be able to find the rule in the link provided.

    Either way, you are right, and I apologize. I meant that statement as hyperbole, and not literally - which I agree is in bad faith to the conversation at hand. I meant that despite listening to us, you chose a path that I disagree, nor do I understand the reasoning from my perspective.

    You have obviously spent a great deal of time decidedly NOT ignoring us, and myself, and I am grateful for that. So sorry for being boorish these last few days.

    Thank you for the time you have spent dealing with this.

    > I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    >

    It's probably best not to do this, this could incite more stricter changes to the API's which would not help anyone, and just create a worse ecosystem for construct, and create a worse relationship between addon devs and the folks making the engine.

    I think there is plenty of time, to migrate and test, and request api changes. before v1 gets sunset. I worry statement like these will just antagonize the dev's instead of bringing positive change.

    I agree. I have no intentions of doing this. I already cleaned up most of my behaviors to avoid internal api use, and have stayed clean since. Most reasons for using internal calls arenʻt as applicable to me now as in previous years, due to better api around collisions, and the addition of particular features.

    I mention it because the major reason for sunsetting sdk1 will be irrelevant if such hacks are adopted, which I believe they will be unless every need of users can be addressed in sdk2. Due to the size of the construct team, I find that incredibly unlikely. Even getting feature additions, like vector math or expanded collision support natively takes forever if at all ever. (using a behavior to resolve collisions, or raycast has severe disadvantages over common ACES, for example, given how you canʻt nest families and such forces poor practices when it comes to architectural design.

    I already know of at least one easy way to hack around the sdk2 limitations and expand the api to include whatever internal calls I want anyway - its just "slightly" more bothersome than just installing a plugin - until someone releases tool to automate it. At which point, poor little Timmy IS going to use that hack.

    ...which will work until we go through the engine and use private fields everywhere, which we've been planning to do for some time, and would also have permanently broken all SDK v1 addons that access undocumented internal features - another reason nobody should break encapsulation, and another reason we need to retire the Addon SDK v1 beforehand.

    There are usually better workarounds to accessing the internal engine anyway. I've also seen cases where people claim they need to hack the internal engine to do something, but there was a straightforward and perfectly good alternative. I think a big part of the problem is people got used to it and started to do that over better options. By enforcing encapsulation people will eventually learn to use the better options first. Even if you have to import a library, or write some extra code yourself, that is better than accessing the internal engine, since that is absolutely catastrophic for compatibility - basically any other option is better.

    Ah... well... that makes sense then, Ashley

    And on point #2, I agree as well mostly, which is fundamentally why I took your advice last spring a cleaned everything up. I personally used internal calls because it was convenient - and more performant in some cases, but I also stopped prematurely optimizing everything and try to not worry about it.

    Here in a few months, I might actually be to a point where I can fundamentally prove whether or not the performance concerns I had are really concerns at all.

    As an aside, and just to further plug my agenda, Nested families or shared behaviors across families would solve so many problems (any way to prevent the cumbersome alternative of nested foreach loops and picking companion objects by uid.) Extending behaviors would also be a huge gain for scalable design and good coding practice. Custom actions are a start on this, but being unable to nest families or share behaviors creates a situation where you still can only go one layer deep into abstraction, which basically precludes any deeper/complex custom systems being constructed via events.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    until we go through the engine and use private fields everywhere, which we've been planning to do for some time

    Since you've mentionned this a few times over the past few years Ashley I went digging into the code to see what this would do concretely.

    Private fields would absolutely make it much harder to do some of the bigger hacks that I've done in the past. The bigger ones being the following:

    Layer Manager: construct.net/en/make-games/addons/1053/now-c3-layer-manager

    (Dynamic layers before dynamic layers were added)

    Layer Magic: construct.net/en/make-games/addons/886/layer-magic

    (Rendering hacks to do some cool multi pass rendering on layers. I still think this would be a sick thing to have, but I stopped working on it due to huge bugs the hack caused)

    Limit FPS: construct.net/en/make-games/addons/1188/limit-fps

    (Wrapper around the C3 ticking method to force some kind of arbitrary limit)

    Experimental XXX Fix:

    construct.net/en/make-games/addons/1128/experimental-touch-fix

    construct.net/en/make-games/addons/1094/experimental-9-patch-fix

    construct.net/en/make-games/addons/906/experimental-text-fix

    (Replaces parts of the runtime classes to fix annoying issues with these plugins)

    What all of these have in common is that the way these operate has been to do something close to the following: 

    let oldClass = C3.Path.To.Class
C3.Path.To.Class = class myClass extends oldClass {}

    This way of doing it has a big advantage because it's non destructive, and more importantly, it is way less prone to breakdowns when changes to the parent class are made. It also allows me to be very precise with the hacks and reuse as much of the original code as I can. With private fields, this becomes completely impossible, and the only way to do something similar would be to replace the entire class and rewrite everything, which would make it painful enough to warrant doing something else instead.

    However, I dug around the code of C3 a fair amount in the past few years, and I don't think that too many fields can be made private. The engine internal classes communicate with undocumented public fields of other classes all the time, and usually these are the fields we'd wanna mess with anyway. From what I can tell, using private fields all over the engine in an efficient way would require rewriting a significant chunk of the engine's code and I'm not even sure how that would look like.

    Also, since private fields would most likely make replacing classes a pain in the ass, a lot of these hacks would probably then just revert back to hooking to random parts of the engine, and trying to inject code wherever possible which would in turn be a lot messier. So really, to me the idea sounds like a lot of work for not a lot of return. At the very least, IMO it doesn't do much that the idea of SDK v2 doesn't already do, and IMO again, adding better APIs and more features to the SDK is really the only sane way to fix these problems.

    Another reason why I don't especially like that idea is that being able to mess with engine internals is a great way to prototype feature requests before I make them.

    I have mostly halted addon dev since SDK v2 was announced to give it some time to mature so when I get back to making addons, I can try to use v2 exclusively and start porting my old addons. However, I still use Construct and I still mess around with it's features, and recently I made a game that made heavy use of Dynamic layers and I found a bunch of tiny additions that could be made to the feature that would make for nice feature requests, but I first wanted to experiment with them.

    For example, here is a snippet I use in that game that adds a layer effect to a dynamic layer 

    	let effectData = [["skymen_DropShadow","DropShadow",[true,	[0,0,0],0.75,4,60]]]
	let layer = c3_runtimeInterface._localRuntime.GetMainRunningLayout().GetLayer(runtime.globalVars.layer_ui_gun)
	let renderer = c3_runtimeInterface._localRuntime.GetRenderer()
	layer._effectList = C3.New(C3.EffectList, layer, effectData);
	for (const effectType of layer._effectList.GetAllEffectTypes())
		effectType._InitRenderer(renderer);
	layer._effectList._InitRenderer(renderer);
	layer._effectList.UpdateActiveEffects();
	layer._needsRebuildEffectChainSteps = true;
	layer.GetEffectChain();

    This snippet is very hacky and a real implementation would require a lot more work, but in the meantime this allows me to test it in a real game and see how well it holds up so I can then come with a well thought out feature request that can prove that the idea has legs. With private fields everywhere, things like this are 100% impossible and I don't think that's a good thing, at least for me.

    Anyway, I hope that by the time SDK v1 is fully sunsetted and private fields are implemented, SDK v2 will be mature enough and will provide a good enough API to make these kinds of hacks unncessary.

    The point I'm trying to make with this post is that the bigger hacks are usually born out of necessity and rarely out of laziness to achieve a similar goal with legal means.

    Addons like Empty Shell, Limit FPS or Layer Manager are born out of a real need to do something that C3 doesn't do and while I understand that V2 aims to make it harder for these addons to be shared with people that don't understand the risks, I would still like being able to mess around with things at my own discretion, even if that means I stop publishing my code.

    I've also seen cases where people claim they need to hack the internal engine to do something, but there was a straightforward and perfectly good alternative.

    And there's also cases where people claim they need to hack the internal engine to do something, because they need it. Dismissing that the public API is limited is dishonest, as well as claiming that there's "straightforward" perfectly "good alternatives" for everything. For what I've seen, most of your alternatives are "don't do it".

    I don't have time to make a proper long response as you like to debate, but the problem really is: you.

    There wouldn't be a problem of the API being limited if the process of suggesting and actually adding features wouldn't be so long and stressing due to your constant arguing with the suggestions, specially when it sometimes feels you aren't arguing against the actual idea but against the dev who proposed it. Even here in your recent responses, you blame the add-on devs for everything, you always seem to have a bad attitude against them and a contrarian attitude when dealing with suggestions from them. Even with perfectly explained suggestions, that took a lot to elaborate to their authors such as the ones of Overboy, you dismiss so easily and in a very blockheaded way.

    I really hope you're working on that, because the addon devs, me being one of them, don't really want bad blood with Scirra. We only look to extend the power of Construct, I can only hope you have the same goal.

    Private fields would absolutely make it much harder to do some of the bigger hacks that I've done in the past.

    I'm afraid these also all risk major compatibility disasters and so consequently it is our intent to make them impossible if we can.

    Again, I'd point out in virtually all other software on the market, encapsulation is the industry standard and such things are impossible to begin with. It's only due to historical reasons of the development of JavaScript language that there was no encapsulation in the first place. If JavaScript had private properties and methods 10 years ago, we would certainly have used them from the start, and this situation would never have happened in the first place.

    For what I've seen, most of your alternatives are "don't do it".

    The compatibility disasters that hacking the internal engine risks causing are so bad, that yes: "don't do it" is a better option. If it really is impossible to do what you want, you can file a feature request and move on - which is what we do ourselves with all other software when we need something more than they provide, because hacking the internals is generally impossible, because encapsulation is the industry standard.

    If this increases pressure on us to improve the addon SDK, that's good - in the long term we'll get there but in a sustainable way, without risking ruining thousands of people's projects. But I also think in many cases people will also figure out other approaches that get the job done but don't need to hack the internal engine - options developers should have chosen in the first place, but ended up never trying to research them because they could just access the internal engine.

    The way I've accepted this situation is through a higher hope for suggestions to be considered. I do recognise Scirra are still careful with these and also have a boatload of other work to do, I mean just imagine manning C3 development, so so sooo many intertwined areas that must all synergise. But, demand would become higher, right? If X addon was made, won't work in future, then if it was in demand, noise will be made, and Scirra would consider it deeply?

    The one and only example of uncertainty would be the FPS limiter, which, has a long history dating back to C2 where an attempt was made but it performed awfully and was reverted, and ever since, there's been no ideal way to do this, until skymen chucked out that addon.

    FPS limit is a common feature in engines, turning vsync off is my go-to for every single game I ever play especially if using a 60hz display as its so noticeable with input delay, even more particularly twitchy reaction games or rhythm. games.

    Turning vsync off is possible now with nwjs and a chrome argument, or using C3's option to turn it off (designed for testing purposes), but it shoots up to max FPS and cannot be capped.

    I feel awkward to bring it up again or draw attention to it, as I believe I understand Scirra cannot do anything ideal about this, but then skymen's addon exists and it does the job... For me it seems flawless, but maybe it twitches or janks, maybe there's a bug somewhere with it, but from testing, feels like it's a necessity worth any risks involved and I'd keep the FPS limiter addon in my project even if it broke for many players, solely because it's that important to me and my games.

    And I would add that while I "can" do many things correctly when it comes to my hacks, but constructscorrect way is via very terrible coding practices, duplicating code, and other bad practices.

    The advice to not do something is actually advice to move to a different engine; An admittance that c3 is not the right tool for the job.

    Had a private api existed in 2014, I personally never would have bought construct 2. I never would have bothered with construct at all for that matter, as several rex plugins gave me the ability to jump in and start doing stuff that c2 wouldn't let you, and recently, I certainly wouldn't have made the decision to port my existing project into c3. I'll also point out that being able to download and tweak existing vanilla behaviors was also the only reason I started using the sdk in the first place. Without that, I would have surely skipped. I think many others would agree; The addon devs made construct viable for alot more projects than you can imagine, and the result was more paying users.

    Construct is great in a few areas, and very lacking in many others. Addon devs picked up that slack, and this isn't to underrate the work you have done Ashley .

    I don't have the data to make such claims credibly, but I don't think nearly as many people would have used/adopted or stuck with construct if add-ons had been limited the way you wish they were back in 2014.

    This whole issue makes staying with construct less advantageous than I perceived it to be 6 months ago. This CAN change with a solid API, but looking at the rate of development in the last 10 years, I'm not holding my breath, and I think that's fair.

    move on - which is what we do ourselves with all other software when we need something more than they provide

    You mean move on like giving GDevelop a try? Maybe you are right and the time has come. I will definitely not risk not being able to open my projects anymore. While you more and more close-source Construct I will look for more open-source alternatives where the community is actually given a voice.

Replies Disabled
Return to board index
Jump to:
Active Users
There are 3 visitors browsing this topic (0 users and 3 guests)