Strafing backwards and diagonal strafing bug

[marcole]

Hello again,

I'm right away posting another contribution.
I was looking at the strafing feature (another nice addition ;-) and what it could take to allow backwards movement.
The code is nearly ready so I gave it a try just to find out some strange outcome.

It led me to find a bug in current nightly when strafing diagonally.
The movement preview shows correctly that it will cost 7 TUs (and should cost 3 Energy).
However it actually costs 5 TUs and 5 Energy because the engine has both "strafe" and "run" flags set.
This is incorrect IMHO so I tried to fix this.
The fix also fixed the incorrect behaviour mentioned above when backwards strafing was enabled.
Specifically, the movement around building corner (X +- 1, Y +- 1) was affected, which has the same basic properties as diagonal movement.

I'm attaching both file patches, bug fix and strafe enhancement.
I have done just basic testing, please if you try it, let me know how it works.

Thanks, Marek

[alienfood]

IIRC, strafing backwards-ish was disabled because the animation shows the character moonwalking forwards, then teleporting two squares backwards and then moonwalking forwards into the new square. There might be a fix related to cycling the frames backwards, but I did not have the time to investigate this. Is this what you did?

[marcole]

Actually I'm not sure if I understand what you're saying.
I have done nothing special regarding the moonwalking.
Since the sidewards strafing also shows forward movement (there is probably nothing else available) I took it as normal.

Sure, I was thinking about reversing the movement sprites but didn't actually looked at it yet.
And the movement is normal, just the moonwalk is quite obvious.

[marcole]

OK, I think I know now what you are talking about.
Tried to revert the movement sprites and it immediately went crazy.

So I looked at the respective code to correct the behaviour.
I'm not sure if the sprites are good enough for this but it still looks better.

I have also found another bug in UnitWalkBState, that shows the first movement sprite incorrectly, facing the walking direction.
It's kinda hard to spot, but it's there, nightly affected.
That's also corrected now.

Please have a look and test it if you like.

[marcole]

I've been not following the development for some time and have just noticed that Warboy already pushed the bug fixes into the master branch, commit 5337f31.
I'm just a little bit surprised it is not mentioned or credited anywhere or at least commented on here for us to know.

Now I would say there is not much that prevents us to correctly implement backwards movement.
Do you see any other reason not to do so ?