vee41 - *sarcastically to myself* Now why didn't I think of that? *facepalm*

ramones - Just before I checked the replies here, I was talking it over with my development partner, and that very fact dawned on me. Lo-and-behold, I had another event telling the running animation to reset to an idle pose after the release of - get this - ANY key. *MORE facepalm*

Thank you BOTH for your prompt replies and willingness to help.

There are some similar forum posts out there that have somewhat clarified part of my issue here - I now understand the difference between On Key Down and On Key Pressed. The latter waits for the release of the key.

MY present issue is that I simply want to have an Action take place when the Event tests that a key has been pressed at all, regardless if the key is held down or released...or not. Just, was it pressed.

My scenario is that I have a character who will throw a punch upon the K key being pressed. The Action that ought to follow is that the Punch animation will play...from start to finish, all six frames. However, whether I use either On Key Down or On Key Pressed, the animation is immediately interrupted when I let go of the key.

(I've tried setting up a work-around - and almost got it "perfected" - but it's too lengthy to try to explain.)

So, ultimately, what I want to happen is this...

1) I tap the K key and quickly release...

(SIDE NOTE: Presently, pending a solution, I can hold it down, whether by O.K. Down or O.K. Pressed, and the animation repeats until I release the key.)

2) ...The punch then plays through a full sequence once regardless of the current true/false of the K key press in subsequent frames.

I've made sure the Loop is set to No on the animation sequence. I've also tested On Key Released. None of them work for my desired result.

Thank you for your help!

— - I have one IN MIND...I just haven't implemented it at this very moment. But yeah, I know I'll need one. My first concern is simply getting it to respond and follow through with the whole animation with a mere key PRESS, with or without being held down or button released. If I can get that set up, doing any reset to the animation (such as an interruption from an enemy from behind) will come next.

— - Thank you for the clarification on the two. Movement-wise, I thought I had the two well understood, but now that I'm adding an "attack" condition, they both seemed to behave the same.

But a new problem for me arises. I want my character to attack and complete it animation sequence SIMPLY when the button is PRESSED - regardless if it's held down or released (or not). The obstacle I face is that the animation STOPS once I release the button. I've switched out both ON KEY DOWN with ON KEY PRESSED...same results. I've almost got a work-around figured out but am having trouble setting up the logic. The one idea I have is to check if the animation is still in any of its current frames by way of a variable, adding 1 to the value each tick. Once the value reaches more than the actual number of frames in the animation, THEN it goes back to normal until I give it new instructions. ...but, the problem I see is that if I set it to a dual-condition event, at least one condition - the button press/down - won't be true.

Your thoughts?

wretchedshark - I hear ya. Since this is just a test game - one that might see its day as an intentional app - I'm not worrying too much about it in DrBox's case. I'll definitely implement the hidden sprite with Platform behavior when that time comes, of course. For now I was just trying to work out hit detection. I deeply appreciate your feedback, though. Thank you! :D

wretchedshark - VERY good points. This is just to work SOMEthing out to begin with, but I'll keep that in mind. ONE thought JUST occurred to me, though. IMAGE POINTS! Right NOW, I've only got one frame for DrBox. I could set multiple image points as the range of detection! So test if the collision happens closer to I.P. #1 and 2 OR I.P. #3 and 4. Something like that. So if the Y value of MrStick's origin point is between DrBox's Y values of image points 1 and 2, for example, and the X value is one the correlating side, then...HIT. I'll work it out.

It might prove to be tedious, but it'll perhaps account for any changes in the size of the frames/images. What do you think? Does that make sense?

wretchedshark - Thank you, sir. I believe I had a similar idea but opted for the horizontal (X value) option instead. I suppose either way will work. I'll test your method, though.

When you have the .height/2, is that because you are assuming that the origin points are dead center for both X and Y values? Presently, I have the origin points at the bottom middle of both sprite characters (so, at their feet, basically).

For my case, given the location of the origin points, I would probably have to amend the code to MrStick.height <greater/less than> DrBox.y+50 pixels (or however tall he is).

...I'm probably expecting a more complicated solution and having trouble finding an easier one...when it really IS that easy. Off to test things! THank you again!

Yann - Oooooh! Okay. I gotcha now. Actually, that IS what I was doing, but when I saved the .capx to be shared, I forgot to set the PlayerBox (the object actually being controlled) back to invisible. I do have my MrStick character (images and animations and all) set to follow the PlayerBox.

.CAPX here: sugarsync.com/pf/D6025908_4317202_6583129

I have pretty much the same set-up that Ashley has in his tutorial, but there's one tiny little discrepancy...

In my .capx the box sprite (the one with the "evil" eyes...aka Dr Box), the collision polygon is uniform with his box shape (minus the eyes). I have it set where if MrStick is falling and collides with DrBox, then DrBox will flash and MrStick will take no damage (represented by the health meter in the top-left).

If MrStick is on the ground/not falling and collides with DrBox from the side, then MrStick takes damage. HOWEVER! It should be possible to take damage even if MrStick is falling and still collides with DrBox from the side - not on top.

I tried setting up a comparison of X values between DrBox's origin coordinates and MrStick's, citing that if MrStick.X was within DrBox.X(+/-)50 (pixels), regardless of jumping or not, to determine if MrStick was colliding with DrBox from the side or the top. (But I've since deleted that line.)

Is there a better way to test what side or point of a collision polygon is hit?

Yann - Forgive me...I'm a tad confused.

Am I cloning my PlayerBox - that which the player actually CONTROLS but is invisible - or am I cloning the MrStick sprite that the player sees when playing the game?

I haven't yet done as you suggested, but I did try editing the origin point on my PlayerBox. APPARENTLY, moving the origin point on the PlayerBox down one pixel seems to have fixed the problem...for the moment. The seemingly random nature of when the collision with the platform sprite makes it difficult to tell.

wretchedshark - THANK YOU! LOL I was trying to figure that out, myself. I knew it had SOMETHING to do with the parallax...go figure I didn't THINK to actually test changing the values. Thank you again!

Yann - *BLINKS* Well, that's news to me. I assumed my PlayerBox sprite was staying uniform in size and not adjusting despite the frames of the MrStick sprite. If that's the case, how do I keep the PlayerBox sprite (or the collision lines, as you said) from resizing? And thank you very much for checking it out for me.

RangerJim - First, I LOVE that you have a Pixar character for your avatar. Second, thank you for also checking it out and confirming what Yann shared.