[4.1.0+?] player obj getting action step overwritten prematurely by input?

FrankenGraphics

New member
There's many moving parts and i may have missed something fundamental, but i think i've encountered a bug, possibly.

I set up a "shallow water" type of collision that changes "Action Step" and subsequently "Animation Type". Turns out that while the aesthetic change (with the changed animations) show immediately at the difference of every type, the change of action step is overwritten before any effect of it can take place. This is true until the walk button is released.

I found this out by temporarily setting the shallow water collision property to write an "Action Step" value that will have the vanilla movement scripts (SimpleInput\StartMovingPlayerDown.asm etc) branch past its contents. The result is that you can keep walking as long as the button is held, but you're stuck (which was expected to happen immediately in this case) only after you've let go.

I also verified it with combing through a walking speed modification with BRK:s to the same effect - it listens to what the action step for the player is - but that's not hard evidence since i'm not sure exactly when i'm doing this (i'm doing it right before checking if there's enough speed to move the object that frame).

It's a sneaky one since it doesn't affect monsters/objects not controlled by gamepad input and since it looks the part animation-wise.
 

dale_coop

Moderator
Staff member
Maybe you could modify the StartMovingPlayerXxx to check it when player is in your particular state and skip the rest of so?
 

FrankenGraphics

New member
Ohhh right, that should work! Turns out the scripts do not take Action Steps above 3 into consideration currently.

CMP #4
BEQ +
(and so on, or in a loop)

That ought to fix it. Thanks!

Edit: just a little caveat - the problem then becomes reversed unless your "null"/walkable script actually has some lines change things back to normal from your special state - from a vanilla module perspective, maybe worth it in exchange for a bit more robustness?
 

FrankenGraphics

New member
Something similar turned out to work great - end of animation -> GoToFirst (or whichever). That's nice not needing to run code at all in the walkable handler. Even if it was just two branches in my case.
Caveat with this method: your animation needs to short enough to provide a snappy response. Mileage may vary depending on how it is used.

Action step timer actions (what a term!) are done before writing the object to the sprite buffer, so that wouldn't work quite right (you'll see the sprites toggling content for a frame at the interval of your timer).
 
Top Bottom