It would be a better solution to use new animations for every skin and animation type. You can add folders to your animations to help you keep organized.

This is why I said "in theory, yes". But that would require to rewrite almost everything (for removing references to C2). To even make changes to the game in that code, big parts have to be rewritten. Just as Whiteclaws said it is basically unreadable. Your employer would be better off to hire you to maintain the game instead to have the in-house programmers commit suicide while tinkering with the program made code.

The short answer for your questions:

• Removing C2 references: Forget it, doesn't worth the time/effort.
• Editing the game from exported code: Nope, if they want source access, provide them the capx.

Could this be an engine bug? I think this topic got too little attention. Ashley did you experience anything similar with big projects?

...Assuming the latest releases work OK, I think it would be better to add another table to the scirra.com/nwjs page listing all the Greenworks plugin releases available and the NW.js & Steamworks SDK versions they use, and then you can download whichever you want to work with, instead of being stuck with some fixed built-in version. So I think that would be the best we can do for officially providing the plugin....

That would be a much better solution that we have right now. Thinking about the users who don't necessary use the forum or know about this topic, you could also add some reference into the editor (like a new faded out object) that let's users know where they can download Greenworks (just like with NW.js). Or you can make bundles with the working NW.js and Greenworks plugin versions into a separate installer and create a new export option. Just thinking out loud.

In theory, yes. But that would be highly un-practical. C2 is designed to program your game using the editor.

...I understand that that may be used in bad ways, but that's not an excuse for not having this feature. If someone can't use Construct properly, that's not your fault, but theirs. ...

While I do understand Ashley 's intentions about this, I have to agree with skymen . Making a general purpose engine will come with the possibilities that users may use features the way they are not intended. This is not something you can or should try to avoid completely in my opinion. You could always put a warning text in the feature's description or in to the manual.

If the problem is caused by other applications or the system of the device then you can't do anything about that from the developer's side.

You can easily achieve this functionality using variables or groups. I don't see the purpose of having this "on signal" event.

384 mb. As I stated, it won't load in NW.JS which is why I can't use it.

Try with the newest beta. If the problem still persist, file a bug report.

Me too. It works without any problems.

— While I haven't used Appodeal yet, I think you should start with these tutorials for some information:

https://www.scirra.com/tutorials/4896/s ... arning-ads

https://www.scirra.com/tutorials/4979/a ... onstruct-2

(The latter is for Cocoon.io, but you might get some useful information out of it.)

When I used AdMob, it wasn't necessary to upload to Google Play just to test the ads. I think that should be the case with Appodeal too.

Please always attach a relevant .capx; you could have included some group names and a 'set group active' action to demonstrate this better. I managed to reproduce it anyway, so the next build disables space as an autocomplete character for function name, group and animation parameters since their names can include spaces.

Thank you for looking into this. The next time I'll make sure to attach a more detailed capx.