Hey, given that I've had this problem in my own project, can I request that the next tutorial (more AI, I think it was) cover having multiple types of enemies? Having duplicated code is bad after all, and being able to use containers AND families would be a big help.

Hm. The tutorials no longer work in the new version...

Would it be possible to specify multiple types of collision boxes? Street Fighter, for instance, has boxes to determine where you can hit others, and boxes to determine where you can BE hit.

Hm. Perhaps the object pairer might work? I'd have to link them individually, perhaps for each spawn, but after that it might work. When I get back on my construct computer later tonight I'll try it out, based on the example in the upload forum.

I'm bumping this because my project is basically on hold until I can figure it out. Please allow me to explain my question more expressly.

Before using containers, I had a bunch of sprites in a family with all the animations given to them, and the platform behavior assigned. When I wanted to have the monster do something, I'd have an event that said something like:

+Family member meets condition

-Set family member speed, position, whatever

-Set family member animation

Now, with containers, I have a problem. The hitbox is the family, and the animation is in a container. My event would look like:

+Family member meets condition

-Set family member speed, position, whatever

-HOW DO I SET THE ANIMATION FOR THE OTHER OBJECT IN THE CONTAINER?

It's a referencing question. Each animation sprite, though contained with the hitbox, has a different name. It's not enough to know that if I named the animation sprite, it would go with the hitbox in cases of cloning and spawning and such.

I tried implementing this tutorial, but found it confusing and inconsistent. I ended up writing my own solution, using just one Camera object. The private variables used are also basically just constants that I wanted easy access to!

First thing I needed to determine was where I wanted the camera to be located. I decided that the lower rear corner was a good place for the player to be located, but not at the VERY edge of the screen. So I want the camera to be a quarter-screen's width infront and above the player. That planned, I use these events:

+Start of layout
-Camera: Set 'Yoffset' to DisplayHeight / 4
-Camera: Set 'Xoffset' to DisplayWidth / 4
-Camera: Set position to Player.X + Camera.Value('Xoffset'), Player.Y - Camera.Value('Yoffset')

+Always
-System: Scroll to object Camera[/code:fsxtt0nv]

Now, we need to make sure the camera STAYS in the right position.  This would be a simple matter of moving the set position action currently in "Start of layout" to "Always", but, 1) That'd only work while you're heading right, and 2) Even if you split it up by angle, it would jarringly SNAP to a new position every time you turned around.  What we want is for the camera to remain fixed in place while moving in one direction, but upon turning around, we want a smooth scroll to the other side.

Some experimentation proved that simply moving the camera in the direction of the desired direction 1 pixel at a time was way too slow, but that any faster was... jarring.  The sudden jump to speed, and sudden halt at the end, both were a little obnoxious.  I want an acceleration to speed for smoothness... and furthermore, a DECELERATION at the end.

So lets get our final list of PrivateVariables going.  This is what my camera needs:

[b]Yoffset[/b] - A constant set relative to the window size, telling us where relative to the player to put the camera
[b]Xoffset[/b] - likewise
[b]ScrollRate[/b] - A true variable, determines how fast the camera is currently moving.
[b]ScrollAccel[/b] - A constant that determines how fast the camera accelerates (and decelerates) when turning.  I find that 10 is a good number.
[b]Turning[/b] - A flag to make our FSM (Finite State Machine) work.

And finally, the events to make it work.  + indicates conditions, - indicates actions, // indicates comments

[code:fsxtt0nv]//Always keep the Y value fixed
+Camera.Y Not equal to Player.Y - Camera.Value('Yoffset')
-Camera: Set Y to Player.Y - Camera.Value('Yoffset')

//Not turning, so keep the camera fixed
+Camera.Value('Turning') equal to 0
+Angle Equal to Player.Angle
++Player.Angle Equal to 0
--Camera: Set X to Player.X + Camera.Value('Xoffset')
++Player.Angle Equal to 180
--Camera: Set X to Player.X - Camera.Value('Xoffset')

//Set turning flag
+Camera.Angle Not Equal to Player.Angle
-Camera: Set 'Turning' to 1

//Turning code itself
+Camera.Value('Turning') Equal to 1
++Player.Angle Equal to 0
--Camera: Set X to Camera.X + Camera.Value('ScrollRate')     //Turning to the right, so increase X
+++Camera.X Less or equal Player.X + (Camera.Value('Xoffset') / 2) //Camera Acceleration until 3/4 there
---Camera: Add TimeDelta * Camera.Value('ScrollAccel') to 'ScrollRate'
+++Camera.X Less or equal Player.X + (Camera.Value('Xoffset') / 2) //Camera Deceleration for the last 1/4
---Camera: Set 'ScrollRate' to Max((Camera.Value('ScrollRate') - TimeDelta * 2 * Camera.Value('ScrollAccel')),1)  // The Max() part is to make sure scrollrate is never negative, which can lead to infinite loops of scrolling where the camera never stabilizes
+++Camera.X Greater or equal Player.X + Camera.Value('Xoffset') //Stop turning once the camera reaches destination
---Camera: Set 'Turning' to 0
---Camera: Set angle to 0
---Camera: Set 'ScrollRate' to 1

//And for turning left...
++Player.Angle Equal to 180
--Camera: Set X to Camera.X - Camera.Value('ScrollRate')
+++Camera.X Greater or equal Player.X - (Camera.Value('Xoffset') / 2)
---Camera: Add TimeDelta * Camera.Value('ScrollAccel') to 'ScrollRate'
+++Camera.X Less than Player.X - (Camera.Value('Xoffset') / 2)
---Camera: Set 'ScrollRate' to Max((Camera.Value('ScrollRate') - TimeDelta * 2 * Camera.Value('ScrollAccel')),1)
+++Camera.X Less or equal Player.X - Camera.Value('Xoffset') //Stop turning once the camera reaches destination
---Camera: Set 'Turning' to 0
---Camera: Set angle to 180
---Camera: Set 'ScrollRate' to 1[/code:fsxtt0nv]

So, that's how I did it.  I have no idea how it compares to the implementation at the start of this thread, because I don't understand it enough to implement it.  But this works.

What I'm saying is... do I have to do that for every Hitbox / Graphic combo I have, or is there a generic way I can do it with families? If I have 20 different types of enemies, each with a separate hitbox / graphic, do I need 20 different sets of events to keep the graphic and hitbox together, or is there just one I can use since they're familied together?

If it's the latter, it's going to be a pain when it comes to things like setting attacks and such. Before I was doing this method, I'd just make sure that all my enemies had animations named the same thing, and then I'd set the animation depending on the state, cycling through all the enemies via family. But separating the hitbox and the graphic would mean that each enemy would need a completely separate state machine, even if the behavior is the same as another enemy.

I'd like a list (and explanation) of all the embedded variables, like MouseX, MouseY, LayoutHeight, etc.

Check out the Platformer tutorial. It really helps.

I'm trying this out, and finding it quite complex. I can see how it'll be useful once I get an understanding for it.

I have a rectangle hitbox and a graphical sprite for each enemy type I want. Is there a generic way to make sure each graphic sprite stays on top of its hitbox? The hitboxes are all part of a family, so I can easily reference all of them at once, but how to make them reference their graphics?

I never got to hash tables in my classes. How do they work?

Is implementing bitwise operations really that tricky? (not a rhetorical question)

Bitwise operations can be very useful at times, particularly when dealing with long lists of flags. It feels like such a waste to me to designate 30 private variables, each of which only needs to check for being a 1 or a 0 anyway. Perhaps allowing a boolean type would also satisfy me, but there's just something elegant about a nice Bitwise OR.