PixelRebirth's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

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

  • Okay I noticed various things in your cap:

    First of all you have an always event which rounds the X and Y position of the player. I don't really know why it's in there in the first place. I can imagine it would cause quite some problems and I'd really recommend to remove it.

    Then you have the platform movement assigned to the player sprite itself. You might want to use a simple rectangle dummy sprite to have the platform behavior and add the actual player with animations and all on top of that.

    And for animations: you should have a look at tagged animations. Will save you some events. Of course if you have a dummy sprite you will have to add an event which always sets the player sprite animation to the dummy animation.

  • Well I'm afraid I'm not at liberty to share the source of this project.

    I suppose you are fairly new to Construct. Maybe you should make yourself familiar with the program by checking out tutorials, the wiki and doing little games/tryouts yourself. Also look at caps posted here in the Uploads section or elsewhere.

    And if you are having problems achieving anything particular, you can always post in the Help forum. I'll make sure to have a look at it and the folks around here generally offer a great deal of help.

  • This is a good start for a Jump'n'Run game. I like the bright and colorful world (which is waiting to be filled with enemies) and you have a nice waterfall effect in there as well.

    The walking animation still felt too jaggy, seems like it needs more frames to it.

    Another minor thing: the color of the camel seems to be pretty similar to your basic ground color. Personally I'd prefer if it was more like in the title screen, where the camel is brighter and the color tone is more yellowish than redish.

    So are you planning on stuff like jump pads and powerups? Hopefully so. Looking forward to upcoming updates.