Here's what's wrong with the pause:

<img src="http://i38.tinypic.com/rvf05f.png">

The first event activates when you hit P, and changes the Pause variable to 1.

Then it moves on to the next event. Since the Pause variable is now 1, it triggers this event too, which changes Pause to 0. So you're pausing and then immediately unpausing again in the same tick, so you never see it. You need a toggle in there:

<img src="http://i33.tinypic.com/23vc01z.png">

The toggle always resets to 0 before it checks your On Key events. When your On Key event is reached, it makes sure that pauseToggle is 0 before performing the action. If it is 0, it will change to 1. That way when it reaches the next event, it won't trigger.

I'll take a look at the other stuff really quick, but just a heads up I can't seem to play your game. I don't know what's up, but nothing moves.

Check your PM's, I fixed your jump.

It seems that Containers and Families aren't communicating properly somewhere, I had to pick instances by object instead of by family. When you try to recreate your bug for Ashley, focus on that.

Also, I changed some things around and made some notes for you. It's all in the comments.

And something I did made it so that the regular preview runs now too, it doesn't just run in debug any more. I have no idea what it was though.

One piece of advice: I know that organization is a good thing, and I admire your tenacity with naming everything properly, but you've taken it to extremes. You have one layout and fifteen event sheets. At least three of those are for player actions. I think you might just be making more work for yourself there... most (if not all) of your player controls should be under just one event sheet, if only so that you can access them more easily. It'll be harder to keep track of how actions interact if you have your them spread across so many event sheets.

Also I only have 2 ground enemies but it made 3 terrain trackers....

You should make sure you have an equal number of enemies and trackers in your layout, since they're contained together. I created a second tracker for your second enemy and it seems to have sorted out.

Or, do like I did and check "Destroy on startup" for all of the contained objects that go along with your enemy, then use spawners to create your enemies at runtime.

In fact, I'd go so far as to say you should probably look into making a level editor/loader for this game. It seems that you want to make something big here. Once you get your engine down, concentrate on making a level editor instead of placing all of your stuff in the layout. It'll keep things lean when it comes to the final build.

Weird, it won't run at all for me. I click Run, and nothing happens. There isn't even a Temp.exe in my task list. No error message, no nothing.

Drasa's right, if you can do it easily without collision events then that's always better. The distance expression is just one line of code, so it'll be easy to implement.

+For each enemy
   +distance(enemyX, enemyY, playerX, playerY) is less than 100
     -> move away code (or flag)
   +else
     -> move towards code (or flag)[/code:2i585vw1]

where 100 is the number of pixels radius you want.

You might need some sort of intermediary event to smooth out the moving towards/moving away actions though, or your enemies might jitter back and forth at the edge of the boundary.

Okay, so you got your TerrainTrackers lining up with your Ground objects correctly? All right then...

but now if one terrain tracker overlaps an object with the terrain attribute they all jump...

and if I add a for each ground object it crashes...

Hmm... try adding the "jump" action to the main For Each loop, like so:

+For each Ground
   +Ground X Greater than PlayerSprite.X
      ->Ground: Set 'Facing' to -1
      ->TerrainTracker: Set position blah blah
   +Ground X Less than PlayerSprite.X
      ->Ground: Set 'Facing' to 1
      ->TerrainTracker: Set position to blah blah
   +Ground Platform: Is on ground
   +TerrainTracker overlaps Terrain
      -> Ground Platform: Jump[/code:oiw5hk3w]

The reason I included "+Ground Platform: Is on ground" is so it picks the proper instance of Ground, even though it should be doing that anyway with the For each loop.  I did have some trouble keeping track of picked objects in my AI so you might need to remind Construct which Ground you're talking about.  Theoretically picking TerrainTracker by itself should also pick the proper instance of Ground to go with it though, so test it without that at first and see if it works.

(Note for the devs:  I haven't had a chance to do any testing yet on the loops and picking problem.  It might not be a problem at all, just bad code on my part.  It's on my list of bugs to check out though, I'll get to it eventually.)

Oh, and if you still can't get it working, PM me the .cap.  Tell your friend I won't steal it.

Edit:
You do know that setting it up this way will make all your enemies jump the moment they hit the ground, right?  They'll be bouncing like rubber balls all over the place.  If that's the effect you're going for, that's cool, just a heads up.

What do your containers look like? Is TerrainTracker in the same container as GroundCollision? Or are those families, not objects? It's kind of hard to tell exactly how things are set up from your screenshot.

Also, reverse the order of your For Each and X Greater Than events. It should look like this:

+For each Ground
   +Ground X Greater than PlayerSprite.X
      ->Ground: Set 'Facing' to -1
      ->TerrainTracker: Set position blah blah
   +Ground X Less than PlayerSprite.X
      ->Ground: Set 'Facing' to 1
      ->TerrainTracker: Set position to blah blah[/code:29u6a9ks]

That way you only need one loop.  And get rid of the Always under your For Each, it's not necessary because the loop will run every tick regardless.

Final question: were you able to get the AI working for one object without families?  Just to make sure it worked in the first place.  If not, give that a test first.  And if you can't get it to run, try posting a .cap so someone can take a look.

Okay, I PM'd him.

Edit:

Ah, you sneaky son of a...

Well.. I don't really mind that he calls Construct buggy, he did encounter an annoying bug.

Saying it's buggy is one thing, but the whole tone of his thread is "Sorry my game is so bad, it's Construct's fault for being a 'total piece.'" It's hardly fair to blame Construct, especially when most of his issues are either just design flaws or known bugs that have easy workarounds.

Ah, well. I did have a rather wordy reply to his latest post on there but I decided to just drop it. I'll let Construct speak for itself when it comes out.

Aeal5566: Sure, man... go for it. I'd like to see what you can cook up. If I post some code it's free for use. Just not my graphics

I just played the third Construct entry in competition. Afterlife Consequences.

It's pretty bad. Even the creators admit that it's pretty bad. The person in charge of making the game apparently decided to start using Construct at the beginning of the competition, so he had no idea what he was doing. The results definitely reflect this fact.

What makes me a little sad is how he's constantly bagging on Construct the whole time, like it's Construct's fault he's made a bad game. He also states that Construct is just an "insane wall of bugs." He only mentions a couple of bugs in the thread, only one of which he posted about here in the Help forum, which was already a known issue and he actually found a fix for it anyway (the other is the IDE crashing when editing sprites... sounds like a hardware issue to me). The rest is just design issues... he's complaining about animation and hitbox problems that aren't actually bugs and are easily remedied, and all he had to do was ask. Hell, he didn't even have to ask... there are plenty of threads that talk about hitboxes and animation already.

Sigh. When scytos mentioned there was a third Construct entry, I had some higher hopes for it than this. Oh well.

I would say to remake it in Construct, but in actuality that rotating tower is probably one of the few things that would be easier to do in GM .

Anyway, good luck with it, I hope it does get finished some day.

I do have a question though, may I see how you did the AI? I can't wrap my head around how to do them half as well as you have them.

Sure, no problem.

Each of the enemies has six parts:

<img src="http://xs434.xs.to/xs434/08492/enemy426.png">

1. The enemy sprite

2. The hitbox (has platform behavior on it)

3. A detector for walls (the black and yellow striped sprite)

4. A detector for the floor

5. An enemy locator (the M is for 'monster')

6. A separate death sprite

The first five items are all in a container together. The only thing not contained is the death sprite. This is so I can show a dead body on the screen, but still have all the unecessary parts destroyed when the enemy is killed.

When I build my level in the Construct layout editor, I don't place enemies. Instead, there's a seventh sprite that spawns everything. It looks like this:

<img src="http://xs434.xs.to/xs434/08492/espawn997.png">

This is the object I copy/paste around the level where I want my enemies to be. Everything else gets a checkmark next to "Destroy on startup."

At the beginning of the layout I spawn all the enemies:

+System: For each enemySpawner
[ul]
	[li]> enemySpawner: Spawn object enemyBox on layer "actionLayer" (image point 0)[/li]
	[li]> enemyBox: Start ignoring user input[/li]
	[li]> mLocator: Set position to object enemyBox (image point 0)[/li]
	[li]> enemySpawner: Destroy[/li]
[/ul][/code:2mh8izmo]

This creates all the parts needed to run the enemies, and puts the hitbox and locator where the spawning object was.  Then it destroys the spawner.

The sprite and detectors get placed on top of the hitbox every cycle, so there's no need to place them here.

Now for the AI:
Each enemy has a variable called "active" that is defaulted to 0.  When the enemy is on the screen, this is set to 1.  It stays at 1 until either the enemy or the player dies, so the monster can chase you from screen to screen when it sees you.

For the movement, each enemy has the following variables:  mySpeed, lastX, lastY.  This sets up the speed (capBox is the player hitbox):

[code:2mh8izmo]
+Every 125 MS
-> enemyBox: Add 1 to 'speedTime'
  +enemyBox: Value 'active' Equal to 1
    +enemyBox: X Greater than capBox .X
    +enemyBox: Value 'mySpeed' Greater than -4
     -> enemyBox: Subtract 1 from 'mySpeed'
    +enemyBox: X Less than capBox .X
    +enemyBox: Value 'mySpeed' Less than 4
     -> enemyBox: Add 1 to 'mySpeed'[/code:2mh8izmo]

The speed can go from -4 (full speed left) to 4 (full speed right).  Notice that we're not setting the speed of the platform behavior directly based on where capBox is, but rather just adding or subtracting a variable.  This is so the monster doesn't turn around immediately when you jump over the top.  If the monster changes it's X in relation to the player, it takes one full second for the monster to turn around and gain full speed (every 125 ms add 1 from -4 to +4).

But we still haven't actually set the speed yet.  There's another variable called "speedMod" that randomizes to give each enemy a slightly different speed, so they don't all bunch together:

[code:2mh8izmo]-> enemyBox Platform: Set speed to (enemyBox.Value('speedMod')+25)*enemyBox.Value('mySpeed')[/code:2mh8izmo]

And this is how we get the speedMod:  See the 'speedTime' variable up there?  When it reaches 5 this happens:

[code:2mh8izmo]+enemyBox: Value 'speedTime' Equal to 5
-> enemyBox: Set 'speedMod' to random(27)
-> enemyBox: Set 'speedTime' to 0[/code:2mh8izmo]

Dang, that's a lot of info just for one post.  We're about halfway done.  Here's how to set the direction of the sprite:

[code:2mh8izmo]+enemyBox: X Greater than enemyBox.Value('lastX')
-> monsterSprite: Set angle to 0

+enemyBox: X Less than enemyBox.Value('lastX')
-> monsterSprite: Set angle to 180

+System: Always (every tick)
-> enemyBox: Set 'lastX' to .X
-> enemyBox: Set 'lastY' to .Y[/code:2mh8izmo]

As you might guess, 'lastY' is for setting the jumping and falling animations.  I'm sure that's pretty self explanatory.  Speaking of jumping, here's how they do it:

[code:2mh8izmo]
+enemyBox: Value 'active' Equal to 1
+enemyBox Platform: is on ground
   +enemyWallDetector: overlaps Family Terrain
   +System: random(20) Equal to 4
      -> enemyBox Platform: Jump
[/code:2mh8izmo]

I added in the randomizer so that they don't just immediately jump when they hit the wall.  Like the change in speed and direction I wanted it to look a little more natural, like they were thinking about it or something.

Resetting and killing enemies:
When the player dies, his position is set to the last eye stone that he touched.  At the same time, there's a loop that sets each enemy to the mLocator sprite in it's container (that was set back when they spawned at Start of Layout).  Then the 'active' value for enemyBox is set to 0 again so they don't just run around the level willy-nilly.

When they're killed, the blinking "hit" animation is played.  When the animation is finished (and only if the enemy is on the ground) then a dead monster sprite is spawned and the enemyBox is destroyed.  Destroying the enemyBox destroys all the other objects in the container.  And that's about it.

I didn't cover animations really, so if you want to know how that's done let me know.  Though I will be putting this kind of information in my Platform School tutorial, so if you can wait until then that's cool too.

It runs slow for me too, but it's because of all the fancy effects . I turned them all off and it runs pretty smooth.