Then again, I forgot to mention I make all my sprites in MS Paint, so right away I'm doing things the tedious way.

If you're using a better program, there's better options for coloring (that's not the time-consuming Edit Colors option on Paint).

I've found that when I upload stuff as bitmaps, they retain their crispness 100%.

However, there is some color loss when that happens. Colors tend to get duller during the conversion, so what you have to do is save to 256 bitmap, and when the colors get dulled, RECOLOR it again.

Roundabout process, but that's what I do.

To tell the truth, I notice next to NO differences between the versions of Construct whenever it gets updated.

But yeah "Ignore User Input" is your friend.

There's a lot of good stuff in here.

Thanks for compiling the list- often-times it was a big chore browsing through the tutorials topics to find the stuff you wanted.

No, Activision isn't evil.

It's just that Bobby Kotick is a supreme douche amongst douches.

Thanks, I cleaned up the pushing events with your suggestions, except instead of Y is greater or equal than Block Y, I did

ToyGirl X is greater than or equal to Block.Left,

in order to keep things smooth-looking (plus, if the player was on a platform a smidgen higher, it wouldn't push at all with Y).

Honestly, the Walls and Blocks event I listed up above (the cause of my previous conundrum) has proved to be such a hassle that I scrapped it. I scrapped it and the Pusher objects too, because they were honestly causing too much trouble, trouble I didn't want to deal with.

It's kinda funny that I put stuff like that in at the beginning because I didn't know how to go about programming what I wanted to do in the first place.

I would really recommend looking at the tutorials if you haven't. Stuff like the Ghost Shooter tutorial, or the Platformer school addresses a lot of the problems you seem to be having, and if you really go through them (and multiple times! like I did), you should begin to get a grasp of what you're trying to do. You can't really just run into things or else you'll hit infinite roadblocks.

The problem you have is this:

on the specific action "L key pressed" you have nothing happening.

What you need is something like this

-L key is pressed

-Sprite2 Opacity Equal to 100

Then: Set Sprite2 Opacity to 0

-L key is pressed

-Sprite2 Opacity Equal to 0

Then: Set Sprite2 Opacity to 100

For the lights (you should really get into the habit of naming your sprites), you do this:

Always (every tick):

Set Sprite2 to Sprite image point "lights" (I made an image point where the lights go).

Like I said, do them tutorials.

Here is yet another conundrum I've got on my hands:

When I had solved the last major problem (the death animation one), I thought I was on easy street. That is, until I noticed a major bug in my programming: if one block was against a wall (and thus, its momentum was set to zero), it would treat all blocks as if they were against the wall on that same side, and thus, it would be impossible to push anything anywhere.

I had originally thought this might be due to the fact that I had used spawn boxes for the blocks as opposed to just having separate instances of the blocks. So I did just that: I got rid of the spawn boxes and the events surrounding them, and just filled the layout with individual boxes. However, it seemed that that solved nothing.

I then realized that I had made a mistake in my original programming: if a block was against the wall, I'd set its speed to 0, when that was entirely unnecessary. I toggled off those outcomes, and things ran smoother.

However, if a block is still against the wall, it still adversely affects all the other blocks on the layout.

Here is the .CAP if anyone wants to take a look.

Here are my events as I have them now:

<img src="http://i417.photobucket.com/albums/pp257/Emperor_Phoenix/Construct%20Problems/BlockProblem1.jpg">

<img src="http://i417.photobucket.com/albums/pp257/Emperor_Phoenix/Construct%20Problems/BlockProblem2.jpg">

When one block is against the wall, all other blocks move jerky and oddly, and I am not sure what is causing it. Well, I should clarify: I have a feeling that I have over-specific conditions for the event of a block against the wall, and this is causing a general muck-up on the .CAP's part.

When I run the debug, it shows about 8 or so more instances of block than what is actually there on the layout. Weird. I have a feeling this may have something to do with it as well.

Thanks for any insight.

From my experience, "Control is down" is a lot better than key pressed or anything.

I don't worry about Xbox stuff, but what you have to do is go into application properties and make sure you know the names of each of the controls you have. There you can also configure what buttons do what. I ASSUME (don't know for sure) that you would set the controls to XBox buttons (like X, Y, etc.).

Thus, in the event sheet, you can have stuff like "If 'Move Left' is down" or "On 'Attack' pressed" or stuff like that.

Yikes, no kiddin'.

You have on animation revived finished as a sub event to death = to 1, but if death is equal to 1 then......

You need a trigger once under the initial death= condition, with the global changed to 0 right after its created. Then on revived finished could be a separate event.

Umm, I am not sure I followed your advice, but this is what I did:

<img src="http://i417.photobucket.com/albums/pp257/Emperor_Phoenix/Construct%20Problems/Solution1.jpg">

And everything now works fine (with the exception of me not being able to change which angle plays during the death animation- which turns into an awkward flip if the player is at 180-degrees, dies, and then instantly flips to 0-degrees for the death animation. I tried setting the animation, but that don't seem to work).

EDIT: it seems that that was just the odd bug. Because now i run it and the angle is all fixed. Sometimes odd glitches like that crop up in my test-runs.

It's kinda odd, but with the event sheet I posted on the last page (the wrong previous one), it would create, in the debug, over 90 instances of the main character sprite, and it would glitch up the animation and slow the game down significantly. I really don't know why it would do that, but I'm glad at the least I have a workable (for now? I hope!) solution.

In a dev-bloggish fashion, my next tasks include:

-HUD creation (easy)

-considering whether or not to destroy progress on a level (eg block placement) every time a player dies. I'm weighing costs and benefits.

-designing some enemy sprites, but more importantly, actual cosmetics (backgrounds, environment)

-events corresponding to a Game Over scenario

And I envision future unexpected problems with all of those things! Joy!

But now i celebrate a small victory, ha. Thanks for the help.

How do you know?

Classified.