[Suggetion] Per project plugins and behaviours

Hi, I've been developing with Construct 2 for some time and even developed some custom plugins and behaviours to give my games a personal touch and do some extra stuff.

One thing that I don't like about Construct 2 right now is having to leave all custom plugins, behaviours and effects whithin the installation directory. The way it is, I can't just install Construct on another PC and work with my projects unless I copy all the plugins. Even worse: it gets very annoying when you use some versioning tool and you want to version those plugins/behaviours. They have to be copied to/from the installation directory to/from the versioned directory at every commit/update.

My suggestion, therefore, is: leaving custom plugins within the project folder structure, so it can be freely copied to any other computer with Construct 2 installed (something similar to adding a lib to your project's folder in a coded project).

Thank you,

Azis

I agree. I downloaded my project from SVN to do some work on my laptop only to discover all the plugins missing. That made for a fun train ride <img src="smileys/smiley1.gif" border="0" align="middle" />.

The only danger I see is that now people have the ability to post a capx and automaticaly run possibly unknown or dubious javascript files. I don't know if any real damage could be done this way.

Great idea. Thumbs up. It would really make things easier when people looking for help post a capx with custom plugins.

Maybe a PlugIn-Extension folder in under the project folder would be nice...

Agreed, a plugin manager would be great too, thanks. ;]

Thumbs up! This is a minor thing for me, but if it improves project organization, I'm all for it! I even have some code specific to test projects and it would be great not having to delete them

It could even bundle the plugins along when you save the capx.

How would it handle a plugin/behavior that already exists in general? I'm guessing it would use the project-specific version, right?

plugin manager seems nice idea

This has been on our todo list a while but is pretty tricky. Currently the editor is designed to only load plugins on startup and never change them, so some rearchitecting would be necessary. On top of that it could become difficult to manage plugins - if you bundle a plugin with a project, then a new version comes out with a bug fix, you need to have a way to update the bundled plugin. I'm not sure we can do this in the short term, but it's still on our todo list.

Ashley, I don't get the second problem.

If a new version of an official plugin comes out with a bug fix, then it's automatically updated. The only plugins that are bundled with the capx are the ones not present in the global list of plugins!

When saving a project, it looks at the global construct plugins folder. If the plugin is there, it skips it (regardless of whether it's an official plugin or a third party one). If it cannot find the plugin there, or if the plugin in the project folder is different than the version in the global folder, it gets bundled.

It's not like it's supposed to pack *ALL* plugins in the capx... In fact, it shouldn't bundle third party plugins if they're on the global folder.

The only way to have a capx with a forced out of date plugin would be to manually copy the outdated version into the project folder.

This has been on our todo list a while but is pretty tricky. Currently the editor is designed to only load plugins on startup and never change them, so some rearchitecting would be necessary. On top of that it could become difficult to manage plugins - if you bundle a plugin with a project, then a new version comes out with a bug fix, you need to have a way to update the bundled plugin. I'm not sure we can do this in the short term, but it's still on our todo list.

Maybe move the plugin loader code to the Project Load events...?

Just a suggestion.

I don't know though, what if the newer version of the plug-in actually has new bugs? It might be better if construct asked you with a dialog box, notifying you that there is a newer version available and asks if you want to update or continue using the old one.

As Fimbul said, the original plugins could remain on the project folder so Scirra can freely modify them and all projects will remain with an updated version. Only custom plugins would be stored with the project.

Arima

Maybe that could cause some incompatibilities if the user decides to upgrade only some plugins and not others.

Besides, if a user doesn't want to use newer plugins, he would have the same option as it has today: not upgrading Construct as a whole.

If it's too complicated and risky to implement in C2 directly, a separate application should do the trick. 3rd party plugins include certain parameters for the app to be able to find and update them properly. I have seen this done like this on other software and I think it worked nicely. It was easy, fast and you never missed a newer version and no need to waste hours looking through the plugins to just update them.

Any news on this?

As a programmer, I usually add my own plugins, behaviors, even effects to my projects and it is really important to me to be able to version them to compare between versions of my work.

I couldn't care less about .capx support, but I think that when you save your project as a .caproj, you should be able to have a "source code" folder where you can put your code specific to the project.

Even if I make a plugin to use in one of my projects, I can't refactor it for use in another project, unless I want to duplicate it and rename it or I can somehow keep backwards compatibility (in case I still want my old project to work).

I love the engine, but for me this is ALMOST a dealbreaker, I am used to work with revision control since I started working in videogames, so this is specially frustrating. Only reasons I keep using the engine is because of the great editor and the focus on component-based design, which I think it makes great sense in the kind of projects I intend to do with Construct 2.

Thanks for any reply!

bumping this topic.

After some experimentation, I am able to work versioning the whole Construct2 folder, duplicating the .exe and all the engine files for each project. Then I only have to execute the .exe of the project that I want to work with, and it will use relative paths to look for the javascript code.

The problem I have when using this approach is that the sprite editor breaks, it seems this one uses absolute paths or registry keys to define where it should save the images, so I can edit images and save them to a path of my choosing, but they will never end up correctly integrated into the game, I have to manually copy them to the correct animation directory and rename them to 000.png before I can see them in the game.

Maybe adding support for per-project javascript folders is too difficult, but maybe fixing the sprite editor (so it supports running the .exe from a different path to where it was installed) would be easier?

Thanks for any reply!