Frisk's Forum Posts

  • 11 posts

  • I've been using this software for quite a long time now, a bit over a year. On and off mostly.

    And just a few minutes ago I realized something so nooby. Like, real bad. The fact that you need to have an instance of a sprite or similar in that specific layout, for any events involving it to work.

    I was looking at my events for something and was thinking "How come this works on this layout here, but it doesn't here? It meets all the requirements - how is this sprite going to overlap if it doesn't even exist on this layout?" but yeah.. just worked that one out!

    Thinking back now to when I very first started, I can realize just how many things I've screwed up in the past from not knowing this. Time and time again I would completely erase entire event groups to try again.. when in reality it was this tiny simple thing every time.

    Is there anywhere that has a list of like general usage and "you should probably know this" things? If I've managed to go this long without realizing that one, I'm probably missing a lot of other general knowledge about the software as well. Preferably not the entire manual, because while that is a good idea to do, I won't remember a thing afterwards.

    Not just for me though - it would have been great for me to have known that long ago, so it's possible that other newcomers could get confused on this stuff unknowingly as well. Maybe there actually is already a place like that, and it's just another thing I'm missing. Great!

  • I believe it's because the instant you change it from going left to right, the next event in line triggers.. While still colliding with the Brick, so it simply moves left again. (following the Event sheet top to bottom). If you flip the Direction changing events around, you'll see what I mean.

    I understand this now, and you're correct, flipping them does have the exact same effect on the opposite direction.

    A problem, though, with this:

    A quick dirty fix:

    What I changed is fairly simple, we just need something to tell us that we've already changed direction so the next conditional event in line does not trigger.

    Reading this through I'm not so sure I understand how that works.. after the "Shifted" number gets set to 1, wouldn't the events now never run because they don't meet the conditions? And if the number is also updated at the exact same time, how would this fix that original issue.

    Edit: I've just copied that identically and it plays out in the exact same way.

  • Or more clearly - "why doesn't what I'm doing work properly?" I have no idea how I'm screwing up possibly the simplest thing you can do.

    drive.google.com/file

    /d/0Bz6k_T7ICBNmdjU5b0xNTnZ1bVU

    /view?usp=sharing

    (Edited to split this up because it doesn't work otherwise..)

    In the .capx linked are sprite enemies with a platform behaviour and a "Direction" instance variable, and a sprite called 'block' with a solid behaviour. Depending on the "Direction" of the enemy, it'll either simulate the platform behaviour to move left or right. In the events, if the enemy collides with the block and has the direction "Right", it'll set the instance variable to "Left" and simulate that movement. An identical event is there for the opposite direction. You probably worked all that out instantly just by looking at the 4 events.

    Real simple stuff, right? But when the enemy collides with the block whilst moving left, it'll refuse to set itself to right. It doesn't do anything, just sits attempting to move into the block. In the debug, the "Direction" variable doesn't change at all.

    I have no idea why it won't work. Everything is spelt correctly, the collision hitboxes are both just squares covering the entire sprite, and it works fine when hitting the block whilst moving right. It's like, the most basic thing in a platformer to get working, and it's seriously annoying me. I can't believe I'm making a thread here for something so simple.

    If anyone could spend just 30 seconds to find the problem and tell me why I'm stupid, that'd be great!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • :) You have to read the value correctly: it is 3 times 10 to the power of -14, which is: 0.00000000000003. Clearly this is 'almost' zero.

    What's causing it to be above flat 0 though, when going right works perfectly fine in comparison and this never used to happen before?

  • Ashley's answer is still valid. Computers produce small rounding errors all of the time. You have to deal with them. If you are basing your animation on VectorY=0, don't. Check for < 0.1, or something like that.

    I'm basing it on the "is moving" 8 Direction condition. I can't change it to be like that because there's points in the game where your movement is heavily slowed - and what if those numbers went higher for no reason as well?

    I find it hard for this to be a rounding error because there's no calculation to even be rounded. Moving right keeps it on flat 0. All the other directions range from around 1 - 6 in the example I provided, but it's different for higher speeds. This has happened completely randomly and it doesn't make sense for it to happen.

    When you press just left, you're only moving left. You're not moving a little upwards or downwards at all - it's just left. If pressing right can get this done no problem, and it used to work just fine for all sides, why does this have to happen randomly now? With the main project I have involving this I really can't make a workaround for this without having it not happen. There isn't even a single event within the example project.

    Even if I did manage to get around this myself, it's still a big issue, because the "is moving" condition is practically worthless when this is happening. I don't know much about the program myself compared to pretty much anyone else around here, but I have a feeling Ashley was meaning calculations just within the events of a project.

  • I downloaded your file and checked my project, and it's completely true. The perpendicular vector value does change once you reach your maximum speed in any direction, though it doesn't actually move the player in that direction. This really looks like a bug.

    It's really strange. If I do this on my project that was working just fine a few days ago, even though the values go up, the player never actually moves in that direction at all. I tested this by walking left into the wall for a while with the Vector Y showing that I should apparently be moving up, as well as making a very long canvas, but I didn't go a single pixel up. It's annoying because like I said in my post, it's completely screwing over my animations on that project, and I can't really get around it.

    Strangely, I never updated my Contruct 2 but this still suddenly happened out of the blue. If you make a new project yourself just like I have done here, can you check if it happens for you as well? The only thing I can think of is that there's some setting I've changed unknowingly that carries over to the .capx which is causing it to happen on every project I export / view. The video I have on my original post is exactly how I made the .capx, it's only a few steps long.

    "[r178] 8-Direction bug" is the name of the original thread with this issue, that Ashley replied to. I would link it to you but, you know.

  • It would significantly speed up the process if you provided a small example of a project that has the problem you describe, and exact steps to reproduce.

    Here's a .capx file link:

    This got removed as well.. here's a broken up version:

    https:// drive. google. com/ open?id=0Bz6k_T7ICBNmNGpaZnpaR29YSzg

    All that's in this is a sprite with an 8 direction behaviour. That's really all that's in here. You can see this issue happening if you run in debug mode, select the sprite, and check the Vector X and Vector Y values while moving in a straight line.

  • LIteTween is another option, and is time based.

    Ah, this one is perfect. All I need to use here is the linear option and change the duration / position for each location, and it works flawlessly. Many thanks!

  • Haha I know, it is something quite simple and we need to use it all the time, but it is complex. The easiest option that I always use, is using rexrainbow's moveto plugin

    Thanks! That plugin is exactly the type of thing I was looking for.

    Just as one last question, how would I set the speed to be correct depending on the position the sprite is going to be moving to?

    What I mean is that if I wanted a sprite to get to a position within 1 second exactly, the speed would change accordingly to ensure it takes exactly that long, no matter what the distance is. It'd move quicker if the distance was large and slower if the distance was small because of this. Do you know a 'proper' way to calculate this? My horrible workarounds have always been these extreme mess of events that never really work out that well. (You can probably tell I'm a real newbie with this!)

    Edit: Never mind this, I'm going with the LiteTween plugin. (Check the post below.)

  • Sorry for the shoddy title, not enough space to explain what I mean!

    I've been using Construct 2 for about a week and at seemingly complete random the 8 Direction behaviour in all of my projects is changing Vector X / Y 'incorrectly'. What's happening is when I'm moving just left, the Y Vector will set itself to a number above 0. When I'm moving just up or down, the X Vector will also then set itself to a number above 0. I have no idea why it's suddenly decided to do this.

    The problem with this is that any events I have using the 8 Direction condition "is moving" now don't work properly. Because the player can be right up against the a wall, press the arrow key into it, and since the Vector Y / X will set itself above 0 for some reason, the player will now play the walking animation into the wall, because they are apparently "moving". (The other Vector works as normal.) Something interesting is that when it's set to whatever number, the character will not actually move in the direction at all. Another interesting thing is that pressing left will keep the Vector Y to 0, but pressing right will set it above 0 for whatever reason.

    I looked this up here on Scirra and found only one other person who had this issue (they had submitted a bug report), and Ashley had replied stating it would be something to do with math calculations in the events. I looked through my own events and couldn't find any issues, so decided to make a completely fresh project with no events at all with one single 8 Direction sprite. And to my surprise, this issue happened there as well!

    So now I'm guessing I've changed some setting somewhere by accident..? I'm really not sure where to go from here. I can't really go any further with some projects because I can't test anything to do with animations properly whilst this bug still exists.

    If you've read all of the above and don't understand what I mean at all, that's okay, I made a 1 minute video to show what I mean visually. Hopefully by watching this the issue should become a lot more obvious to see.

    The link got removed for my reputation, so I'll break it up here. "Piece together at your own risk" or something, I guess? "youtube .com / watch? v=LbIhlwR5spQ"

    Hopefully this is something obvious I'm missing, I'd really like to get this back to normal, I have no idea what's caused it. Thanks in advance!

  • Probably one of the biggest beginner questions in existence, but I honestly can't find anything about this!

    All I want to do is have a sprite go to a location (at a consistent speed throughout) in a specific time, and stop once it's there. That's really it!

    Here's an image of what I want to do if it's needed. You can ignore the text.

    I really don't know how else to explain this further because it's such a simple thing that I can't seem to work out. If anyone could just let me know the proper way to go about this, I'd really appreciate it.

    As a quick sidenote, I do not mean having a sprite that always goes the same speed to a location - because then if the distance is a lot smaller in one occasion compared to usual, it'll finish it much faster than a longer distance. What I'm wanting is for the time this movement happens in to always be the same. So the one moving a smaller distance will move slower to ensure it takes the same amount of time.

  • 11 posts