Is it possible for C2 to implement some sort of animation iterator?

Ashley - But if the instance is not creayed in the first place, there would be no UID. sirLobito was asking for a custom constructor as a function. Correct me if I have misinterpreted the question.

I am currently using strings to check for which object to create in my function. The thing is in any Object-Oriented Languange, it is impossible to pass an object into a function without first creating the object(it will throw exceptions). You can use an enumerator or string and based on that to create the object in the function.

I wonder if it is possible to expose an expression like gravity direction from the official plugin?

If you have a number of independent states like "running", "jumping", etc..., use a number to represent those states, rather than a boolean IsRunning. It simplifies your event sheet by a few blocks.

You can try adjusting the hue per tick, I got a rainbow fireball using that trick

This is what I meant:

dl.dropbox.com/u/104500051/ObjectSelection.png

Ashley, if possible can we get imagepoint name from the imagepoint number?

I just wanted some expression like imagepoint_name(number), if that is possible.

Is there a way to iterate through or get the number of image points for a single sprite?

I am using the licensed version. What I'm referring to isn't the folders, it's the object selection when the dialog box appears for selection of objects. The selection does not organize the objects into the folders that the objects are in whereas the expression dialog box does.

I was just wondering if Construct 2 would implement some sort of object management during events when asked to chose an object. For example, when wanting to pin an object to a second object, I have a huge list of about 60 sprites, to scroll through. Is it possible to make the object choosing interface similar to that of the expression interface where the objects are placed in their respective folders? The same could also be said for adding/editing families.

It's not really an issue, as the edges share the same pixel when they touch each other. And besides, some of the games that people make are also relying on this overlapping condition. Hence, just as justifun mentioned just make the collision area smaller or you could actually give buffer spaces using the animation editor to make the sprite height and width larger while keeping the collision area the same so that when you place side be side the buffer space will separate the sprites so that the overlapping conditions would not trigger.