PixelRebirth's Recent Forum Activity

  • I think all it needs is a "DUCK" is NOT down condition in event number five.

  • It's great when you're writing an answer just to notice deadeye was faster. lol

    Still I have a little thing to add:

    I noticed that you might have tried to use tagged animations on the character. This only works with the object that has platform behavior applied to it. You could still use tagged animations and set the animations of your visible sprite accordingly with an always event. But beware tagged animations are currently a little buggy or so I've heard.

  • Can you upload the cap file where this happens? Without it it's kind of hard to tell you what might be going wrong, although there might be people around here who can tell you a little more about that particular error message.

    Oh and btw welcome to the forum

  • What I want to achieve is this: The enemies are patrolling - which means they walk left for x amount of pixels, stop and go to the idle animation, then they turn around, walk x amount of pixels, stop and go to idle, etc. etc.

    I don't really think that's hard to achieve. You'll just have a PV on the enemy called Range or something similar and then you compare its current position to its last stopped position. If the difference is bigger than the PV Range, the enemy will go idle.

    Here's a little example.

  • Yes I am looking forward to a plugin like that for quite some time now. I'm kinda sick of using workarounds (

  • Actually you don't need any of those events in this case... you could just use tagged animations with a little tweak as described here:

  • I noticed this problem with tagged animations too. You don't really need events to fix it though, apart from 1 always event that is.

    You can still have all the tagged animations on your invisible dummy sprite. Like mentioned above the actual image of the different animations should be all the same rectangle.

    Now with your visible player sprite you need to use the same animation names. You don't need to tag them. Finally make an always event which sets the visible player animation to dummy.animname.

    For some reason this works.

  • I don't think you should mess up Metal Slug with your very first project. Sry for sounding a little harsh.

    It looks a little strange when you walk in one direction and aim behind you...

    The movement and jumping feels right, though.

    Oh, and Metal Slug > Contra.

    Yeah, I said it. Anyone wanna fight?!

    I don't want to fight but regarding gameplay I still prefer Contra

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Okay I checked out your cap in 0.98.7 first. Then in 0.98.8 and 0.98.9.

    So I could figure out how it's supposed to work, hehe... I really like it btw. Although Deadeye is right. It's pretty damn hard to get into it without any comments.

    Without fully understanding what's going on in your events, I just tried a few things. One thing seems pretty clear: It's your "Zaharra" event group where things go wrong. There's a for each loop with three subevents. All three subevents perform a move at angle action. And the calculations used there go wrong in the most recent versions. So your characters suddenly are positioned out of the window.

    (That was figured out by toggling the Zaharra group. Doing that it seemed to behave the same in all versions.)

    Unfortunately I'm far from being able to tell why this happens. I had a quick look at the changelog of 0.98.8, but there was nothing that really came to my attention.

    Interesting enough, when I toggled the FOR EACH condition in the "Zaharra" group and ran the cap it crashed in 0.98.8 and 0.98.9 (Runtime Error, unexpected error)when a collision occured, while it still worked in 0.98.7.

    So after all I guess it could be a bug that was introduced in 0.98.8. But that's still a guess. And I'm not known for being that smart. Hope this still helped in some way.

  • Just use On Click to set the animation.

    On left mouse button clicked => set animation to "shooting"

    Since it's looped, it will repeat itself from now on of course.

    Now make a new event like this:

    Left mouse button is NOT down (inverted condition) => set animation to "default" (or whatever your idle animation is called).

    That should work.

  • Rightclick in the project bar and select 'add layout'.

  • I think your english is fine. I just get confused easily.

    Well if you're using overlap at offset it's like you're checking if the object would overlap if it was at a different position. So I'm using (-1,0) offset in the example. Which means that it checks for overlap using the X position of the object minus 1. The Y position remains unchanged since it's 0. Hope that clarifies it a little.

    But if you're happy with the use of another sprite, go for it. Anything that works is okay.

PixelRebirth's avatar

PixelRebirth

Member since 26 Mar, 2008

Twitter
PixelRebirth has 1 followers

Trophy Case

  • 16-Year Club
  • Entrepreneur Sold something in the asset store
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Coach One of your tutorials has over 1,000 readers
  • RTFM Read the fabulous manual
  • Email Verified

Progress

23/44
How to earn trophies