VERY weird "Play Animation" bug.

I have an event that triggers "play animation" whenever a sprite changes direction. each time "Play animation" is triggered in the game, the sprite warps more and more, until it's almost invisibly thin. while on the subject, is there any reason an animation will just stop playing although it's supposed to loop? is it a known bug?

I set a sprite to change to a running animation when holding the right key for example (I made sure "trigger once" is on), and it works fine for a while, but eventually when it switches to the running animation, it will be stuck on the first frame.

Anyone come across something similiar?

I love the program, but it seems way too unstable to develop something ambitious on..

You might want to check the order of your events. If you have an event that switches your sprite to a different, single-frame animation that is being run before checking for left/right input and switching to "running" then when your "running" animation comes up it will always default to frame 1. For instance, putting your "change animation to default" action into an always event at the start of your animation routines will do this, but there are other ways as well. Just double-check that there isn't anything triggering an animation change prior to your running action that might be overriding it, and condition it accordingly.

As for the sprite changing size... I don't know what could be causing it. I've never encountered it, and I've never heard of it happening. Maybe you could upload an example of what's happening so someone could take a look at it?

I posted the animation bug already. Here're the steps: New game, insert sprite, import an animation. Make event: Always set frame to random(number of frames). The sprite crunches. This happens sometimes with the 'set animation' action as well.

A workaround is to set its size each frame to its original width and height.

http://sourceforge.net/tracker/index.ph ... id=1003219

You might want to check the order of your events. If you have an event that switches your sprite to a different, single-frame animation that is being run before checking for left/right input and switching to "running" then when your "running" animation comes up it will always default to frame 1. For instance, putting your "change animation to default" action into an always event at the start of your animation routines will do this, but there are other ways as well. Just double-check that there isn't anything triggering an animation change prior to your running action that might be overriding it, and condition it accordingly.

As for the sprite changing size... I don't know what could be causing it. I've never encountered it, and I've never heard of it happening. Maybe you could upload an example of what's happening so someone could take a look at it?

I double-checked, and nothing should be changing it - the animation is the right one, it's just stuck on frame 1 like it doesn't play.

Like I said, it works fine 90% of the time, but after playing for a while it randomly happens. I don't really want to show the game yet - could I email you or something?

Everything is going smoothly for me in the controls department, but i'm having alot of trouble getting animations to play correctly. it'll always end up NOT playing any animations, while still switching to the correct ones.

by the way, your kick-it demo is perfect for my game - except for the little bounce the character makes when it lands. did you find a way to work around it?

Thanks for all the help!

I was working on a bounceless physics-platform movement, but met with some mixed success. I set up some events to briefly add force downward when the sprite lands to overcome the bounce. It took a lot of tweaking to get it looking right, and even then occasionally it would stick to the ground momentarily on landing. Then there were other problems that had nothing to do with the ground bounce, like the sprite sometimes sticking to walls in midair when you push against them, even with the world solver and friction set to fastest. Eventually I scrapped it. I might give it another shot sometime, but I think I'm done trying to mix platforming with the physics movement. The only really good thing to come out of it was learning that you can get the detector to stick properly (no lag-behind) by using Create Hinge instead of updating it's x,y and turning rotations off.

And yeah, I can take a look at your cap if you want. I'll pm you with my email.

Hey electrii, got your file. I don't have time right now to do any hardcore bug-searching but I can get to it later tonight. I was able to replicate the problem with the run animation stopping, though. I also noticed though that there were some code streamlining fixes you could make to smooth things out. For instance, you have "On Key Down" conditions in both your control events and your animation events, so it's a little redundant. I could make some commented suggestions and send you back the cap if you like.

But yeah, like I said I'll dig further into why the animation is crapping out later on. I'll keep you posted.

PS - I like your character design and the dust effect. Pretty slick

That will be great, thanks

I'm a graphics designer, not a coder, that's why my events are a little sloppy

I've used MMF before, so this is a little more complex for me - it looks like the order of events is much more important here.

Also, do you think I would be better off using a different method to control the guy? the only reason i'm using the physics movement over platform is because it allows me to easily play with velocity.

A workaround is to set its size each frame to its original width and height.

Oh yeah, this is a nice temporary fix

I guess that with this fix you don't really need to look into it, deadeye! now I can set "Play animation" along with any animation-changing events, which seems to solve the problem.

Now I just need to lessen the bouncing, I'll try playing around with force settings..

Could you send the .cap which is doing this to so I can take a look? Thanks.

Mail sent.

Sorry for the late response.

I've gone over your cap front and back, even going so far as re-writing both your entire animation and controls event sheets, and making all of your animations (even the static ones) four frames. It still has the same problem... the run animation will eventually stop and get stuck on frame 1. I have no idea why it's doing this. Hopefully Ashley will be able to find the problem.

Anyway, I did do some streamlining on your code though, I can send you a commented .cap of the changes if you like. For instance, I was able to condense your animation sheet down to just two events, and your dust spawning effect down to just one.

Well so far I've had a look and the reason the animation is stuck on frame 1 is because of your coding: make the red detector visible that you use to check if the player is standing on the ground, and it goes flying off somewhere because you made some kind of hinge. You really should remove its physics movement and just fix it in place with set X/set Y actions. Then it never gets stuck on the first frame, because it can properly tell when you're on the ground.

As for the object changing size, that's a bug in Construct I need to hunt down

I don't mean to be contrary Ashley, but that's not it. I mean, yeah that could be a problem, but that's not what's causing the animation bug. I was working with the .cap for hours with the detector visible, and the animation still stops even when the detectors are in the correct place. In fact I never once saw the detector fly away, it was always in the correct spot, so the animation bug isn't the detector's fault. And I don't know if electrii sent you a different version than what I got, but he had the detector set up with "Aways: set to position" rather than with a hinge in the file he sent to me.

Sorry for the late response.

Anyway, I did do some streamlining on your code though, I can send you a commented .cap of the changes if you like. For instance, I was able to condense your animation sheet down to just two events, and your dust spawning effect down to just one.

That would be great! I'd also love a way to reduce the bounce a little, it's proving to be a bit more bothersome than I thought it would be.. I don't care about how it looks, it just makes landing and immediatly jumping less responsive than i'd like.

You would of course get full credit if I finish this

Also, I doubt the detector is the problem, since it still recognizes when to switch to the correct animation..

That would be great! I'd also love a way to reduce the bounce a little, it's proving to be a bit more bothersome than I thought it would be.. I don't care about how it looks, it just makes landing and immediatly jumping less responsive than i'd like.

File sent. I didn't correct the bounce, for reasons I explain in the PM, but all the other code tweaks I made are commented.