PixelRebirth's Recent Forum Activity

  • 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

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

  • Why are you setting the door to sollid in the first place? Solid objects are unpassable, period. You will never overlap with them. At least, not if you're using a built-in behavior like Platform or 8 Direction.

    I was confused about that as well. But when I checked his cap I figured that he wanted the door to be part of the level boundary.

    Actually wouldn't it be better Makis to be able to place the door anywhere in the level, so the player can overlap anytime, but only pass through the door with the key? In many platformer games doors are part of the background. So you might want to go for that. But maybe your game concept requires this. After all I don't know.

    Instead of using overlap with the door object i use collision with another object. Even though the door is set to solid (to prevent the player from passing through the door) it still doesn't work. I'm checking for collision and not for overlaping so i guess it doesn't matter that the door is solid!

    You are using collision with another object and not the door itself? But your next sentence kind of sounds like you were still using the door itself just with on collision on not overlap. Again, I'm a little confused there.

    EDIT: Oh I get it... the another object thing lol. Of course it's called like that in Construct itself. My bad. Then I guess you can't be on collision with something solid when you're using platform behavior.

    Anyway, I made small changes to the cap you posted. It works with offset. Remember if the door was to be approached from a different or both directions you need to have an event with different X offset as well.

    Here is the cap

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm actually a little confused but I think I get what you mean.

    So if the player is overlapping the door and has the key, the game will instantly jump to the next layout, right?! Just put an invisible sprite that checks for overlap and the HasKey variable in front of the visible door, which can be solid now of course. That way you can get an overlap.

    Even easier: you could check for overlap at offset.

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