No containers? I just realized how bad it is...

Well, that's too bad.

I'm trying to create game with composite characters. Each character has cube sprite with platform behavior. But the whole mess begins when you trying to control _multiple_ instances of one enemy specie.

That problems could be easily solved by original construct's container system... which don't exist here.

I've suddenly realized how I am deep in troubles for now.

Yes, that's what's kept me from trying to do it. I've heart it is on the todo list, but when?

Containers' last mention.

I'm just broken till when it done. I thought that containers are so basic (well, after quite big possibilities of Classic 2 years or so ago), damn <img src="smileys/smiley11.gif" border="0" align="middle">.

Anyway, I should be able to achieve my goals with UIDs and IIDs picking. But containers were the one and only elegant choice for me just 1 hour ago - that's why I'm so upset.

As long as the number of objects add up to the same, going by iid is fairly reasonable.

As in this index = that iid, blah, blah, blah.

One draw back from CC's containers was that creation, and destruction were tied together.

It would be nice if there were some flag you could apply. Telling if a contained object should be created with its parent, etc.

Another drawback - more lines of code - which contradicts the basic idea of both Constructs.

I'm also bad at programming - that's yet another drawback.

Ahh, if we could only knew approximate release date for containers ( Ashley Tom <img src="smileys/smiley17.gif" border="0" align="middle" /> )...

Containers are easily implemented with events.

Say you want a container with 2 objects: Sprite* and Sprite2

* Sprite will be the primary object of the container. If you want to destroy or create the container destroy/create Sprite.

//first all container objects are created for each Sprite

+On start of layout

--- Sprite2: destroy

--- Sprite: spawn Sprite2

//creating a container

+Sprite: on created

--- Sprite: spawn Sprite2

//destroying a container

+Sprite: on destroyed

+System: pick Sprite2 instance Sprite.IID

--- Sprite2: destroy

//Then for simple container picking

+every tick

--- Sprite2: set position to Sprite

//Or when you want to pick the contained objects after some other picking has been done:

+for each Sprite

+System: pick Sprite2 instance Sprite.IID

--- Sprite2: set position to Sprite

good to know, must try this way, i for one always use a var and uid of the parent object, but i hate it when for some unknown reason they get misaligned somewhere down the road and they start to pile up when destroyed, uhhh

R0J0hound's idea works, but it gets quite messy! I have characters that have 8 "parts." Every time I want to modify the character as a whole, I have to create 8 events; it kind of sucks!

ROJOhound is the best programmer i�ve known on this forum, also Yann is the second place.

I remember wanting containers, but I think I'm fine without them now � I can't even remember why I wanted them. I feel there's more flexibility without containers, and only adds a few extra lines of code. I can have every enemy use the same detector object and attach what every sprite I want to it just using 'for each' and comparing to an ID.

I just use an array to keep track. I might knock out a relevant tutorial when I finish this project.

No containers -> good opportunity to learn "for each" and "pick by �" at last.

Containers are on the todo list, but I'm afraid we can't give an ETA!

I managed to create a nice way to spawn sprites with lifebars, using the Fors and Picks. You can download the game and .capx in here:

http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=11569

...but I guess you can also achieve it with the new "PinnedUID" expression. I haven't tried it yet, but I imagine it can be done.

I just found that Ashley don't have medal. I think if you trying to improve software, you should buy it, because there's only 100 lines of code possible and no families for free version.

It was a joke.