Download Construct 3 Built-in Addons?

I was wondering how we can download & inspect the builtin addons (Pin, Platformer, Multiplayer etc). I used to do this a lot to add small behaviour changes, understand how things actually worked (most notably the multiplayer plugin) etc.

I might just be missing some download link, but if someone could point it out that would be great!

(I reallllly don't want to have to port the C2 versions of the builtin plugins if I can avoid it )

After some more searching I found:

Seems it is intentional that the plugins are more or less closed source

I understand that Ashley wants to keep compatibility issues down... but this still makes me sad. Looks like il convert some of the addons myself!

Same here.

I'd like to create plugin interacting with native SDK and it's hard to know where to start. That's why I'd like to access some build-in plugin too.

I hope it will change in future.

You can see the runtime.js of the built in plugins on c3 to see how they work through the chrome debugger. That is what I have done to see how a few things are done.

You just have to run your game in preview and open the chrome debugger on the preview window.

Go to the source tab

Expand the edit.construct.net part of the tree

Expand r85, or whichever version you happen to be on.

Expand the behaviors or plugins sections.

Each behavior or plugins runtime.js file will under separate folders. You can click on it, set break points, inspect variables, and get ideas on how things work.

*Note: If you start to create your own under developer mode and a local http server, those runtime ones will appear in the one of the entries under (no domain) and will be in one of the blob items.

Hope this helps

p.s.

I forgot to mention that you will only see the plugins and behaviors that you have included in the project. Also it helps to create a test project with only one of the item you want to debug. This makes it easier to debug so you don't have multiple objects calling the same runtime script.

The SDK download does come with some samples. Are there any new samples you think would be useful to include? What exactly is it you're trying to do?

Ashley, here's what I was alluding to in the blog comments thread. I hope this makes sense:

There are literally dozens of useful functions, variables and features that are not referenced in the manual. For example:

this.inst.getImagPoint(number, getXpos)[/code:1bfou0jf]

There is no way for a plugin developer to learn about the existence of that function (unless I am mistaken, I could not find it in the sdk manual) without reading the Sprite runtime.js and/or possibly the commonace.js.  With obfuscated plugin code as the only relevant reference, one is left to haphazardly read through the 1500 lines of a copied version of the commonace.js to find it - and it is not obvious that it only applies to Sprites....

Alternative view:  Let's consider my Box2D+ plugin that works on Sprites, TiledBackgrounds and Tilemaps.  I was able to learn about how the c2runtime manages its collision system for each of those 3 types of object only because I could read the files in those plugin folders.  If I had to reverse engineer from the obfuscated code that is all I can see in the c3 plugins, then I would not know that:

[code:1bfou0jf]this.inst.tilemap_exists[/code:1bfou0jf] 

is quite a useful boolean (!).  I would not have been able to make my plugin without knowing about it, and I imagine that I am not the only one.  

I believe that there are literally dozens of other examples I could cite, but I am sure you get the picture.  I don't know why you would ever support people who've hacked standard plugins, when it's so easy to change the name and work on something that's not going to conflict with the main editor.

Thanks rhg1968 I'm sure it will help

As far as I'm concern Ashley basically I'd like to access:

• native iOS framework such as haptic engine. (feedbackGenerator)
• And access Facebook Core SDK to log custom event with FacebookEvent on iOS (client needs)

As far as I understand I need to communicate with a Cordova plugin. It seems it's what you did with Game Center plugin for example, isn't it?

I didn't see in example how to achieve this. Maybe I missed it.

OK, but the solution to that is better documentation, not enabling compatibility nightmares through copy-pasting official addons wholesale. It's a fair point that the C2 runtime is not well documented and it's definitely something we'll be looking at improving for the C3 runtime. The C2 runtime has a very ad-hoc design and as a result largely lacks formal APIs which is part of the problem. Also the old C2 code is already out there and there's no point trying to put that genie back in the bottle. So for C3 we're trying to move to a better approach. We want to keep the official addons closed to avoid the associated compatibility nightmares, but we will compensate by making sure the C3 runtime has much better documentation.

I think the solution is to not support any project that is based on hacked official plugins. Then that problem goes away and a whole world of developer access opens up. Simples!

That's simply not an option if a customer comes to us in a panic that they're going to miss an important deadline because their project is corrupt. In that situation we will obviously do anything we can to help regardless of what they used in their project. But we want to take steps to prevent this in the first place. Other than that, we already don't offer any official support for any third-party addons of any kind, but even then I think it's irresponsible to allow users to get entangled in difficult compatibility problems and shrug it off with "sorry, we don't support that" - we'll still take steps to try to prevent that in the first place.

I'd add that as far as I'm aware, no other software on the market allows third-party developers to copy-and-paste all the official features to tweak and re-publish them, because it's fundamentally a terrible idea. It violates the "don't repeat yourself" (DRY) engineering principle and causes ongoing compatibility problems as each copy of the feature has to be maintained in parallel to the changes made in the official version, but inevitably isn't maintained, or is done incorrectly and adds bugs. This was basically a big mistake made in the early days of C2 when we were literally coding on our laptops in our bedrooms doing whatever we can to get the company off the ground. Now we're trying to reverse that mistake, which can cause some awkwardness in the short term, but is absolutely the right thing to do.

Maybe I'm missing something here. Can I just check that you mean that you don't want people to replace the standard plugins with modified versions of the standard plugins? If that's the case, why not just lock access to the standard plugins in the c3 editor: make them non-replaceable (if that even could be possible using the addon manager)?

I mean the ability to release addons that are based on modified official addons. Actually replacing the official addons is even worse! That gets you in to situations like not even being able to open projects that don't even use any third-party addons! That's so irresponsible that as far as I'm aware nobody's ever advocated for that.

Just wanted to make sure we were both talking about the same thing...! I understand your position and reasoning.

One of the strengths of c2 was (is!) its accessibility to amateur coders. That meant that it was easy for amateur devs to create the many plugins we now see, all to fill the gap between standard plugins and what event sheets could access within the runtime. And they were all educated into the ways of c2 by learning from the offical plugins. As soon as the new c3 runtime comes out I am afraid that will cause the list of unofficial c3 plugins in the addon repository to be tiny... But maybe that's not the market that c3 is aimed at. In either case, it's a crying shame, IMO.

This was such a terrible mistake with such poor consequences for reliability and compatibility that I will be very glad to get rid of addons that are modified official addons. I simply cannot entertain arguments in favour of such a disaster.

I still want the SDK to be accessible and useful to amateur coders - we'll aim to do that with more SDK samples and better documentation instead.

Also there are other ways that built-in features can be modified. I'm happy to talk about alternatives. So far though, nobody asks me about alternatives and just forks the built-in addons, causing compatibility disasters. I fully intend to force people to find other ways of achieving that without the downsides. There are definitely ways of doing it and it's possible we can add some more extensibility features to make it easier while keeping compatibility. I'm sure as we further explore this we can achieve the same results we had previously, but with far better compatibility. I don't intend this to be a permanent closing off of that capability. I only want to put an end to copy-pasting official addons.

I'd also add that if you copy-paste our code, you can't release it under an open-source license, because the runtime is not open source licensed and you don't have permission to do that. I'm not going to start chasing anyone over this, but it should be obvious that it's not exactly brilliant from a copyright point of view either.

If we force everyone to use a solution that doesn't involving copying engine code, then that's actually better for open-sourcing addons as well - you actually have permission to use the license you want