Does C3 team cares any about 3rd Party Plugin?

I am so curious.

In my opinion, a friendly environment for 3rd party plugin developing had made C2 a great engine.

I am so curious, does C3 team cares any about 3rd Party Plugin?:

https://construct3.ideas.aha.io/ideas/C3-I-395

This made volunteers depressed.

I'd be more worried about what the new runtime is going to do to the sdk.

If they don't scrap the existing one, and start over again that is.

i see nothing wrong with things being there for internal use. They added it for a special case optimization and likely could remove it or change it on a whim if they wanted. It gives them lots of freedom to be able to freely change everything but exposed sdk functions. It really can bog down development if everything in the runtime needed to always be supported in all plugins.

I know I’ve used runtime specific stuff in many of my plugins and I fully expect it to break if those things change in the runtime.

Anyways I’ve always found Ashley to be pretty good balance at keeping backwards compatibility. It’s his porogative to keep stuff undocumented so it can be changed or even eventually depreciated if the normal trigger gets made faster or the way functions work get changed entirely.

As to breaking comparability, I have nothing against it. If the new version is surpirior then it’s worth it.

R0J0hound

Ashley

It is not a good reason that scirra won't release that feature. I agree that some functions are used internally. But "fast trigger" is worth to release because it could improve the performance (that's why scirra add it).

A possible solution is making the "un-documented" feature to become "documented", not only post a response said it is "un-documented". It does not solve any problem.

Of course we care about third-party plugins. We went to lengths to release the addon SDK early on in the public beta so developers could get a head start. In this case R0J0hound is pretty much spot on. Some features are quick hacks for single features. In the case of the Function plugin fast-triggers have some pretty bizarre limitations because they're designed for exactly one use case. Rather than fix the limitations or document them, they're just undocumented and not intended for any third-party use. We're a small company perpetually pushed for time with many users demanding various bug fixes or new features all the time, and it could take 3-4x as long to flesh out a quick hack in to a proper fully-documented general-purpose feature. There's no clear reason to do that and even if there was, it'd have to be a really good reason to justify prioritising it above something else, like working on the new C3 runtime, fixing C2/C3 bugs, etc.

Ashley

I know that there are some limitations (i.e. mot a general-purpose feature) in fast trigger, just write them down in SDK. It's fine.

I had used this feature in function2 plugin, which have string-index parameters and default value feature, since official function object only has number-index parameters.

I don't even know what all the limitations are. It would take some time to inspect the code and think about what they all are. This feature cuts a narrow path through a large and complex engine, to optimise one very specific feature. I basically have no idea what will happen if you use it any other way than identically to the Function plugin.

Ashley

I could tell that nothing wrong in my rex_function2 plugin with fast trigger in c2. My friend even made some templates sold on scirra store with this rex_function2.

( Sure it might be broken someday, or never )

If you use it identically to the Function plugin, it's probably OK. But I don't know, the bigger problem is that it's unknown which circumstances it works exactly, so it would be tough to document it and I don't want to have to support it if someone uses it in other cases. E.g. if someone uses it in some other way, then files a bug because it's broken one way or another, that's exactly what I want to avoid. It's meant to be a single-purpose shortcut that nobody else knows about.

One of the big problems with the C2 SDK is basically everything is public and people go nosing around undocumented APIs and relying on them. This is pretty bad for us, especially if people start asking us to document or better support random hacks in the engine that were never meant to be used anywhere else. I mean, what next - is someone going to start fiddling with the WebGL batching engine and asking us to document what various command parameters are for? It gets pretty obscure in that part of the engine, mainly because a bunch of stuff is recycled and repurposed to relieve GC pressure. Nobody's meant to care about it, but in theory someone could end up writing a plugin that uses all that.

In the long term it also risks making the entire engine inflexible - if we can't change the code without breaking some random third-party plugin, we could end up struggling to make any changes. For example it could end up that we can't ship a 2x performance optimisation, because several third-party plugins ended up depending on a particular algorithm that we used. This could well be the case with fast triggers: we might be able to speed them up further by making its restrictions even tighter, which is OK with the official function plugin, but not OK if it was a documented general-purpose API that we have an obligation to support forever, or put through a lengthy deprecation-and-removal process. The end result could be everyone's games are stuck running slower and we can't make optimisations to improve it.

By the way, this is why for the C3 SDK we've taken a consciously different approach. There is a much more focused (and limited, at first) set of APIs available. We hope to broaden it out over time, of course, so it can do everything C2 did and more. However this takes time. These APIs will be much better designed so it still allows flexibility in the engine, will be comprehensively documented, we'll support them with bug fixes etc., and we will provide backwards-compatible support for the foreseeable future (unless we put them through a deprecation process). In the long run this is much better for everyone, but in the short term puts us under pressure to work on various API features (like the text rendering API I just filed an issue for). We'll do our best to keep up with that.

Finally one extra thing to note: the C3 runtime will in many cases use identical APIs to the editor. For example IWebGLRenderer will be identical in the editor and runtime - and it will actually be backed by identical JavaScript classes, since we can share editor code with the runtime. Hopefully this makes it a lot easier to develop plugins, since the editor code can be shared with the runtime. For example we already have a particle engine in the editor for the live preview feature; when we come to port the plugin to the C3 runtime, we'll literally copy-paste that to the new runtime, saving a lot of work.

Maybe I should've written a blog post about this

Ashley

Take fast trigger flag for example. It is only a flag, not specific code of implementation, you could still maintain implementation behind this flag. i.e. it does not decrease the flexible of engine code.

(the other issue is -- official function had been released several years, why it is still unstable like a bomb in your statement?)

I agree with you about not using engine code directly, but it is not a good solution which only said "Don't do that", it will drive 3rd-party plugin maker away. A better solution might be -- finding a way to meet user's requirement and keep engine code flexible, like, adding a new (abstract) function interface in SDK, to isolate engine code.

(or maintain SDK first, then use this SDK to build engine/IDE)

There might be a big trouble if 3rd-party plugin still tie to engine deeply -- 3rd -party plugin tried to improve/correct engine itself, not to extend the feature of engine, i.e. there are some defects in engine. In this case, isolate engine code won't fix it.

Take fast trigger flag for example. It is only a flag, not specific code of implementation

No, it is not just a flag. It uses a whole different path through the triggering code, which is deep in the internals of the event engine. Just because it's exposed as a flag, doesn't mean it's as simple as flipping a bit.

Ashley

Let me explain more detail,

I made rex_function2 plugin few years ago, to have

• string-index parameter ( official function plugin only has number-index parameter )
• default value if that parameter is not assigned

These features is useful in large projects which might have large function interface.

I started from official function plugin, try to add few logic to implement these features, so I could claim that my rex_function2 is as fast as official function plugin.

Sure I could remove fast trigger flag in C3 plugin. But the performance will lose, performance is an urgent resource in large projects. Therefore rex_function2 is not worth to use in C3.

Will scirra improve official function plugin to have these features? No, we all know there are too many TODO items.

Can 3rd-party improve official function plugin by themself? No, the performance is not good as official function plugin.

----

Sorry I was not in discord channel yesterday, I would like to share some ideas about "Does scirra team provide enough SDK api for 3rd-party plugin?"

It is not a good question, imo. "What kind of feature could be implemented by plugins?" might be better.

Someone suggest that crowdfunding to have more resource for TODO items, I agree that it is not about money only for scirra team. But what if some requirements could be made by plugins? 3rd-party plugin maker could implement these requirements into plugins and sell them in scirra store. Users could get these feature from 3rd-party developer directly, scirra team won't take any resource on them ( or take money for outsourcing ), and engine keeps growing.

In this situation, 3rd-party plugin maker is not only an api consumer, he/she could be a partner of scirra team.

What if most features are made by plugins? Then all developers including scirra team are plugin makers. Don't worry that no one will use these SDK api, scirra team itself will use them definitely.

Well, this puts us in an awkward spot. Nobody was ever meant to use this feature. I'm also generally not a fan of the fork-official-plugin-and-tweak approach to plugin development, as it's a perpetual source of compatibility problems, as it has unsurprisingly become here. We could add fast triggers to the C3 SDK, but then there's nothing stopping new plugins being released using it, meaning the compatibility risks I described earlier get carried on in to C3 as well. This is frustrating since a new product is a good opportunity to make a clean break and remove old compatibility cruft from the code base, but this will bring in some awkward compatibility stuff right at the beginning of the product lifecycle.

We do intend to redesign the function feature after the new C3 runtime which will supersede the official function plugin and any other third-party function plugins as well. Hopefully this will then make the issue irrelevant, since everyone will migrate away from all function plugins to the new feature. Because of this, I think the best compromise is to port the plugin to C3 using standard triggers rather than fast triggers. It may not be as fast as in C2, but it shouldn't be terrible, and it will only be a problem in the period between now and the new function feature in the C3 runtime.

Ashley

...It may not be as fast as in C2, but it shouldn't be terrible...

Thank you for confirming it, you don't need to add fast trigger anymore. I should not care about performance too much.

About "fork-official-plugin-and-tweak approach", it is not a good solution I agree, but how to add these features with best performance without "fork-official-plugin-and-tweak approach"? Will scirra improve official function plugin?

Again, "Don't do that" does not solve any problem.

Well, as I said we plan to introduce a whole new feature anyway, so yes we will improve it and it should become a moot point in future.

Fork-and-modify inherently causes compatibility problems, so if possible we should try to think of a way to extend existing addons from a different addon. Perhaps there could be a way to tag ACEs to appear on a different plugin instead, which receives the instance to operate on as an extra parameter, or something like that.