Easiest anti-moonwalk of all the time!

[lcl]

Hello, here's very easy and simple anti-moonwalk.
There is very few lines of code in the demo, but animations work perfectly.

There is ChangeAnimation() - command in the draw actor event and it does all the animation
changings. String called anim holds the animation names and prevAnim holds last animations
animindex. It's used for changing animations when keys right and left are pressed.

I hope it's useful.

- lcl -


EDIT: demo updated

[skydereign]

If you press both left and right down at the same time, it messes up, so not quite perfect. I still say the state method is easier, although it does have more lines of code.

[lcl]

Messes up?
It didn't when I tried it. When you press both of them it changes the animation to
stopright or stopleft according to were you moving left or right. That's what I think
seems best when both keys are pressed.

[Hblade]

NICE


EDIT: HOLY FREKN' CRAP DUDE.... EPIC

[lcl]

NICE


EDIT: HOLY FREKN' CRAP DUDE.... EPIC

Thanks!

[Hblade]

It's so simple yet advanced!

[skydereign]

Well the difference probably has to do with our keyboards. After a bit of debugging, I figured out why this happens though.
Order of events:
Key Right [stop=0, prevAnim=3]
Key Left [stop=0, prevAnim=3]
Key Both [stop=1, prevAnim=3]

So, it doesn't update prevAnim quick enough (as in the draw event happens after the fact, to be precise the last event to trigger), and the animation is locked. You can fix the flaw by changing the animation on the actual event, but that would ruin the whole point of this method. Another weird thing is that keydown events seem to trigger more than once per frame.

[lcl]

Well the difference probably has to do with our keyboards. After a bit of debugging, I figured out why this happens though.
Order of events:
Key Right [stop=0, prevAnim=3]
Key Left [stop=0, prevAnim=3]
Key Both [stop=1, prevAnim=3]

So, it doesn't update prevAnim quick enough (as in the draw event happens after the fact, to be precise the last event to trigger), and the animation is locked. You can fix the flaw by changing the animation on the actual event, but that would ruin the whole point of this method. Another weird thing is that keydown events seem to trigger more than once per frame.

Wow, that's weird.

[skydereign]

Well now that I think of it, the error makes sense, even though the other part doesn't. Essentially your system requires a one frame delay to act perfectly, as you you don't apply a lock. Just to note, the multiple key events per frame stops a couple of frames after the key down events. It eventually stabilized to left, both, right, draw as the order.

[lcl]

Ah, ok.
Since it works fine for me I can't test that but how would it work for you if you
would write prevAnim = animindex; before sprintf(anim, "..."); in key down events?
Could you try it?

EDIT: I got this problem also, I just had to press other one of the buttons
repeatedly. I tried moving the prevAnim thing into keydown events and the problem seems
to be gone!

[lcl]

Hey, I found the most important thing for fixing that problem you mentioned, skydereign.
When you hit two keys immediately same time the animation glitched.
But all I had to do was to add cases for animindexes 2 and 3 to key down for both keys pressed same time. (See the new demo)

[skydereign]

Wow... should have realized that. It was around 6:00 in the morning when I was looking at it. Well, good job then. Trying to add other animations with this system would probably make it overly complicated.

[lcl]

Wow... should have realized that. It was around 6:00 in the morning when I was looking at it. Well, good job then. Trying to add other animations with this system would probably make it overly complicated.

Thanks.
And well, I don't know if it would be complicated or not,
but I think it's better than use million rows of code in draw actor.

[Camper1995]

wow... really good job man! +1

[lcl]

:shock: wow... really good job man! +1

Thanks!