Sorry. I didn't achieved, so I can help you.

With Dropbox, for example

I'm not sure to understand the whole problem, but you can pick by the uid of the desired sprite: Family->Pick by UID->sprite.uid

If that doesn't help, can you share your capx or an isolated example of your problem?

I don't think there is any problem in having tons of different layouts, as they are loaded on demand.

The behavior is still in the repository: https://sourceforge.net/p/mchiz-constru ... /behavior/

C2 does it now, through Edge browser.

Chowdren caught my attention and I had a look at the source code. It is A LOT of work. Mainly, it replicates ClickTeam Fusion 2.5's engine. However, it has an advantage over Construct, because the plugins are C/C++ code also, so Chowdren can link to this libraries and it just works.

I was thinking about doing something similar for Construct, but it is not viable, mainly because of the plugins. If you want to support every plugin, you should recode it in C++, and it is not a good idea.

As I see it, there are only two "good" options:

1.- If someone wants to do a Chowdren for Construct, in the sense of native performance, instead of coding it in C++ I would code it for Unity, because you would have the engine part done for you, having access to all the platforms that Unity supports. You still have the plugins problem (you would have to replicate the functionality in Unity for each one of them), but for a closed game (where you know which functionality you need) it can be doable. In other words, I would do a Construct->Unity translator. If I have the enough will to finish the game I'm doing right now, I will try this solution for myself.

2.- Do a wrapper for each platform you want to support, embedding a Javascript interpreter. This could be A LOT of work, because every platform has its own set of private APIs (graphics, audio, etc.), and they can differ a lot.

In my opinion, there is no good generalist solution to this problem, and I doubt that Scirra will dedicate resources to do the wrapper thing (the first option is not scalable), although it would be awesome.

I'm starting to use a lot of families, so I can feel your pain

+1 to folders for families

Hi! Nothing new for now, mainly because I'm working in a game and I didn't needed anything else from this behavior.

Is there something that you need and is missing?

I know this is an old thread, but I think this event should be per instance. It is not intuitive to have to put a for loop in some events and not in others.

That said, is there any place in the documentation where you mention these kind of events? I'm finding myself adding for loops inside the events when something is not working as expected. That's how I found this problem with timers.

Thanks rexrainbow!

I'm sorry to bump this old thread, but I have a related question to the subject.

I'm doing some tests for a new plugin which outputs some audio, and I would like to access the 'context' variable of the Audio plugin to do it, but I can't find the way to do it.

The info in this post (http://c2plugins.blogspot.com.es/2014/02/reuse-ace.html) is very useful (thanks, rexrainbow!), but I still don't know how to access these kind of variables, the ones declared as "var context = null". These variables seems private to the anonymous function of each plugin/behavior. Is this correct or can I do what I need?

Thanks a lot!