Containers full of sprites

I have the feeling I might be trying to run before I can walk here so feel free to call me out on it. I've gone through the Ghost shooter tutorial and the usual culprits but I can't figure this one out. The wiki mentions that containers can be used to combine sprites to use as invisible "detectors" or the like but I can't even persuade my sprites to move together.

I've got a 5x5 grid of sprites. I want to move all twenty five of them in unison and rotate them as one around the central sprite (marked with a P). Something like this.

http://www.schwoom.com/Engine/Illustration.jpg

(excuse the poor art skills there, I'm more of a 3D render guy)

I've included a basic .cap if it helps.

http://www.schwoom.com/Engine/FiguringOutContainers.cap

Three questions before we begin:

First, are you having multiple pink squares running around with many groups of orange boxes attached to them? Or do you just have one pink square with one group of orange boxes attached? (If you have just one pink square and one group of orange boxes then you don't need Containers.)

Second, do all of the little boxes perform the same function, or is there some special reason why you need to have each box be a separate object? (You may be able to make this grid out of many copies of one orange box... but then Containers wouldn't work that way.)

Third, do all of your orange boxes exist all the time, or will some be destroyed and/or created as the game progresses? (If you need to destroy some of them, then again Containers won't work. All objects in the Container must exist, or none must exist. There is no middle ground.)

The answers to all of these questions is important, as depending on what they are you may or may not need to use containers in the first place. Please be as detailed about what you intend to do in order to get the best help possible. We can find you an alternate method if need be.

Now then. I've gone ahead and shown a method here anyway that will allow your contained sprites to work as intended. But like I said, answer those questions just to be safe, you could be saving yourself some trouble:

http://dl.dropbox.com/u/529356/containers.cap

What I added:

1. Image points to your pink sprite. It would need 25 in total, one for each of your orange boxes. I got as far as 2C because I was lazy. Also, I just slapped them on there and didn't bother trying to line them up properly, so that's why they're crooked. Open the pink sprite in the image editor and select the image point tool to see where the image points are located. You will have to add the rest and line them up properly yourself.

2. I put all the orange boxes into a family (the Blue family).

3. I gave the Blue family a variable called 'myPoint' and populated that variable with the image point name that each box should line up with. Up to 2C, that is. The others default to the pink sprite hotspot at the center because they have no image point name to match up to.

Of course all of the orange sprites are contained with each other, and with the pink sprite, but that doesn't mean they will move together. You still have to tell them to set their positions and angles and such. So here's where we do that, and the reason why we've set up all this stuff:

4. I made the following event to set the placement and angle of each contained object...

+ Always
    -> Blue: Set position to pink sprite at image point Blue.Value('myPoint')
    -> Blue: Set angle to pink sprite angle
[/code:rg7lpncs]

Since all of the orange sprites are in Blue family, you can just perform all of the actions on Blue at once instead of having several actions for each object.

I've tinted the orange boxes for the group on the left with a red color filter so you can see that the container is separating them properly and the matching ones are lining up only with their contained pink sprite.

Oh, by the way that .cap uses v0.99.82. Sorry I forgot to mention that.

Three questions before we begin:

First, are you having multiple pink squares running around with many groups of orange boxes attached to them? Or do you just have one pink square with one group of orange boxes attached? (If you have just one pink square and one group of orange boxes then you don't need Containers.)

There will be one set of pink/orange boxes. This may be where I misinterpreted the purpose of containers - The containers page on the wiki says one use is "To connect objects with detectors for collecting passive input (detecting walls, floors, etc.) " which is what I'm going for here.

I assume that by not needing containers you mean that defining the image points and attaching the boxes to them is what will do the job and containers are redundant?

[quote:ti2v3vx9]Second, do all of the little boxes perform the same function, or is there some special reason why you need to have each box be a separate object? (You may be able to make this grid out of many copies of one orange box... but then Containers wouldn't work that way.)

I could have done a MUCH better job of explaining this so apologies.

The purpose of the grid is something along the lines of:

A non player sprite (enemy or wall or whatever) overlaps box 1a. This triggers an event which displays "Enemy in zone 1A!" warning elsewhere on the layout. If that enemy moves to box 2A the warning changes to "Enemy in zone 2A".

If a second enemy appears and moves in on box 4E then the warning will change to "Enemies in Zones 2A and 4E!". Different lights will flash, sounds will play and so on depending on which box is being overlapped.

So they all perform the same function (with the exception of the P sprite) which is that of a grid based radar. Once walls or enemies are interacting with P, P is in combat and a whole different bunch of events come into play. the 1a to 5e boxes exist to tell us where the enemies are before reaching p.

[quote:ti2v3vx9]Third, do all of your orange boxes exist all the time, or will some be destroyed and/or created as the game progresses? (If you need to destroy some of them, then again Containers won't work. All objects in the Container must exist, or none must exist. There is no middle ground.)

No, all the boxes exist or none exist, no problems there

[quote:ti2v3vx9]Now then. I've gone ahead and shown a method here anyway that will allow your contained sprites to work as intended. But like I said, answer those questions just to be safe, you could be saving yourself some trouble:

http://dl.dropbox.com/u/529356/containers.cap

What I added:

1. Image points to your pink sprite. It would need 25 in total, one for each of your orange boxes. I <Snip>

I've tinted the orange boxes for the group on the left with a red color filter so you can see that the container is separating them properly and the matching ones are lining up only with their contained pink sprite.

Thank you very much ! That appears to do exactly what I was thinking... and a lot more elegantly than the first few drafts I'd knocked together

I'll see if I can knock something together in the next day or so to give you a clearer idea of what I had in mind, hopefully it'll surprise and delight.

There will be one set of pink/orange boxes. This may be where I misinterpreted the purpose of containers -

you mean that defining the image points and attaching the boxes to them is what will do the job and containers are redundant?

Yes. Imagine you had a swarm of bees and they each had a separate hitbox. That's what containers are for... to keep track of which bee belongs to which hitbox.

And if a bee's hitbox gets picked (like with a collision) then you can say "destroy bee" and the proper bee will be destroyed because the container picks it for you.

[quote:2qn9s3y2]The purpose of the grid is something along the lines of:

A non player sprite (enemy or wall or whatever) overlaps box 1a. This triggers an event which displays "Enemy in zone 1A!" warning elsewhere on the layout. If that enemy moves to box 2A the warning changes to "Enemy in zone 2A".

You could do this with instances of the same sprite. Just give each sprite a zone variable and pick and set them according to what their value is. You could even re-use the myPoint variable I made - it has the zone info in it already.

[quote:2qn9s3y2][quote:2qn9s3y2]http://dl.dropbox.com/u/529356/containers.cap

Thank you very much ! That appears to do exactly what I was thinking... and a lot more elegantly than the first few drafts I'd knocked together

No problem, but keep in mind you could simplify it even further now that you know what's up . Here's a quick example of something similar that shows how you can use instances of the same object:

http://dl.dropbox.com/u/529356/nocontainers.cap

As you can see, even though they're the same, you can differentiate between them by their variables.