I’m working on a game where d-pad controls should move the player sometimes, but other times should only change player facing direction.
Unfortunately, unless I use
ignore, the d-pad always moves the player. And if I turn on
ignore, then no input events happen at all.
There are workarounds, of course: I can move invisible walls around the player, or draw the player myself and not use the player at all. But these add significant complexity.
It would be great if there were a pre-move action that I could implement on the player that would let me add logic and make other calls.
It would be especially helpful if the handler could return true to allow the default player behavior to proceed (walls would still stop the player, interactions would still proceed), or return false to prevent the movement from occurring.
Have you tried using something like this in the player's
update event to just keep the player place when you want to? You would have to handle both the
event.dy actions, but maybe this will point you in the right direction.
if event.dx!=0 then
if stopMovement = 1 then
// assuming you have a stopMovement bool that you use to mediate the input
realX = event.x
realX -= event.dx
I gave it another go, and was able to make this work, but it does require suppressing the repeated call to the
update event that happens when you call
goto. And you must have
autoAct disabled, calling
act or maybe
tell only when you allow the movement.
I haven't worked everything out yet, and I sure would love to be able to simply interrupt the event instead of having to work around things like this, but it does look easier than other workarounds I tried--thanks for the encouragement!
Example handler just to conditionally stop movement:
on update do
if goto_triggered==1 then
goto_triggered = 0
if x_movement_allowed==1 then
player_x = event.x
if y_movement_allowed==1 then
player_y = event.y
goto_triggered = 1
@Harspoon this is what you were trying to do in your game.
I’m quite keen to do something like this too.
I ended up with almost the exact same script. I agree - would be nice to have global parameters for targeted ignoring of select input commands.
on update do
if calculatingPhysics==0 then
if cancelDPad==0 then
if event.dy!=0 then
realY = event.y
realY -= event.dy
cancelDPad = 1
if event.dx!=0 then
cancelDPad = 0
calculatingPhysics = 0
Sorry for the dull comment. I threw the above two code examples into a test game without much luck.
I'm sure i'm doing something wrong but my question is if anyone has a working example of what is trying to be done here?
Or is this still theory crafting?
I copied working code into the above—but I swapped out some game logic for the x_movement_allowed and y_movement_allowed variables. But note that I didn’t provide anything to set those.
Something else in your code would need to do that, in order for the.
player to move at all.
I hope this helps!
I'm sorry, I'm still not following.
Do you mind sharing the json?
Hi, again, Guv!
Sorry for the delay, but I wanted to communicate this as clearly as I'm able.
Here's a complete mini game that uses this technique to lock direction of movement -- I wrote up the approach that I took in the README:
I hope this is helpful. Feel free to ask follow-up questions!