Page 1 of 1

Double-move sprite glitch on keyboard/dpad flee

Posted: Sat Apr 17, 2021 5:56 pm
by Einsame Hirte
I came across a bug in (I believe) the sprite animation code while working on a new keyboard handler. When fleeing using a keyboard or dpad (including virtual dpad), the hero sprite will often jump two spaces, including onto unwalkable tiles. This is only a visual effect; the internal reference is correct, and the sprite is moved appropriately on the next move or redraw. It does not happen if animations are turned off.

I've spent some time trying to track it down, but the animation code is a bit hard to follow, especially for this android newbie. I have confirmed that MovementController::moveToNextIfPossible() is only called once, as expected.

Screenshots from two different phones:
Screenshot_20210417-104944.png
Screenshot_20210414-083844[1].png

Re: Double-move sprite glitch on keyboard/dpad flee

Posted: Fri Apr 23, 2021 1:24 pm
by rkabra151
I primarily play AT via D-pad and this is bugging me quite a lot. After updating AT to 7.13 fighting has became very irritating for the past week.
As it is only a visual effect may be it is related to D-pad graphics change.

Edit: As there were a lot of changes in combatlog it maybe related to that. This seems more likely.

I will also add that if I am not struck in unwalkable area movement will follow from visual location not the place where I should have been.

Re: Double-move sprite glitch on keyboard/dpad flee

Posted: Sat Apr 24, 2021 8:50 pm
by Einsame Hirte
I've since verified that it can happen using the regular touch interface too, if you double-tap on a tile more than one space away when fleeing. It seems to be related to input rate limiting during the transition from combat mode to regular walking mode, but it's strange because as I noted above, the actual movement routine (which is used in both modes) is only called once to the appropriate tile, and it doesn't happen when animations are turned off. It seems like the animation moves an additional tile if an additional input is pending, independently of the code that checks for walkability. This is odd, because I'd think the animation would be called only after the internal state is updated, but I haven't been able to figure out that code yet.

I think that if the location IS walkable, the extra movement instruction gets processed and the internal state matches the screen. It still "jumps" that first move, though, which is a bug.

I haven't tried it on an older version to see if this is a new problem, but I'd be surprised if it was introduced with the combat log changes.

Re: Double-move sprite glitch on keyboard/dpad flee

Posted: Sun Apr 25, 2021 3:04 pm
by rkabra151
I have played in last version just a day prior to updating and combat and fleeing was working fine. I had only played with d-pad not with touch input, So I can't say if it was present already and only become apparent to me in v0.7.13.

About combat log, I only said that because It is related with combat and combat log changes stood out in change log. I am not a coder and that was the only basis for what I said.