Rhindon's Forum Posts

  • — - 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • *bump* My apologies if the bump is too soon as I only posted this yesterday, but it was already on page 4. I was afraid it would get lost with no reply.

  • coltonrawrr - Here's my .capx of my game I'm testing new things on. It's by no means a finished work. But it should show you what you're looking for. When you look at the Event Sheet, scroll to the bottom to find the "Dr Box Movement" group. That's pretty much what you'll find in the tutorial — showed you.

    Also, you can use a global variable to track your enemy's direction, but if you choose to limit it to a local variable (as I did - see the Local static text MrBoxDirection = "left" variable declaration at the start of the group), be sure to set the variable to "static" so it doesn't reset its own value every tick (which would override any changes in direction and keep it going the same way indefinitely). Think of static like electricity: it's always ready to be on the move and change. Non-static resets - or is re-declared - ever new tick.

    Does that help? :) Anything we can clarify?

  • Thank you for the help! :) I got it worked out.

    For my situation, I called on the instance count of the object and told it to -1 in order to refer to the actual ID #.

    So, if I have five instances (IID #s 0, 1, 2, 3, 4) and want to destroy the last created/existing instance, then -1 gets me to that correct # and destroy it. So far, it's working.

    The instructions I gave go like this:

    ->PlayerBox | On collision with Enemy

    -->(sub-event) System | Pick Sprite instance (Sprite.PickedCount-1) => Sprite Destroy

  • .capx file here: https://www.sugarsync.com/pf/D6025908_4317202_6583129

    Hello all!

    My current problem rests in a "little" obstruction or...I don't know what it is...that stops Mr Stick (that's the stick man you can control) from moving forward just as he reaches the apex of the two-triangle incline (made of two instances of the platform45Slanted sprite object.

    Once the .capx loads, simply start running to the right (A and D to move left and right, W to jump) and once the PlayerBox (the sprite objected that the MrStick image is set to) reaches the top of the first slanted platform instance and apparently collides with the second, it just gets stuck.

    This doesn't happen 100% of time and doesn't seem to happen again after the first time (ie: you move away and come back again). I have Dr Box (that's the box with "evil" eyes) running on Simulate Platform movement and I've noticed he occasionally gets stuck, too...usually after Mr Stick is already stuck. But it seems to happen much less with Dr Box.

    I have checked the collision polygon settings for BOTH instances of the slanted platform sprite. It's a triangle shape stretched as far as each point can go to their appropriate corners of the sprite. Both sprites on are equal in terms of the Y-axis. Both are the same size.

    The ONLY possible explanation I can think of is that there is (I THINK) a pixel-wide space between the two instances. I haven't devised a way to test this or if it's even the actual problem.

    Could someone poke around see what they can find, please? Thank you, much!

  • You do not have permission to view this post

  • if you put the enemies into a family you could save the uid of the family

    the collision would pick the right enemy a,b or c

    How would I put the enemies into a family? What's a "family" in C2 terms?