Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upTransition.EndNavigation not always triggered #586
Comments
This comment has been minimized.
This comment has been minimized.
The same goes for changing the
For For left and right it's called only after
I don't know yet what would be the best way around it. Maybe a new Squirrel function that would allow to remap the default signals for the directional controls ( those in brackets )? |
This comment has been minimized.
This comment has been minimized.
Conclusions: Current implementation only allows vertical layouts to benefit from Shouldn't the |
This comment has been minimized.
This comment has been minimized.
Just a rough idea. It would be temporary if the layout sets it. |
This comment has been minimized.
This comment has been minimized.
I've opened a new branch in my fork with a new function I've added
|
This comment has been minimized.
This comment has been minimized.
I think I've got a fix for this |
- frontend should now consistently trigger Transition.EndNavigation when navigating using fe.signal()
This comment has been minimized.
This comment has been minimized.
Not neccessarily, if you just suppress the signal without calling |
This comment has been minimized.
This comment has been minimized.
With my commit we can take advantage of the navigation acceleration without remapping actions every time we change the layout. |
This comment has been minimized.
This comment has been minimized.
|
- corrected error with last commit so EndNavigation transition isn't triggered when a script signal handler catches and stops the navigation - smarter handling of key repeats when a script has a signal handler that is remapping navigation actions
This comment has been minimized.
This comment has been minimized.
Hats off to your commit a45bff8 It actually fixed the underlying problem. I have to admit that my commit was a workaround as I've decided to not to mess with the main loop too much. By adding just:
we have now proper transitions calling and acceleration. |
This comment has been minimized.
This comment has been minimized.
Thats great! Thanks for the reports and for testing this.
That main loop is a monster with way too much going on for my liking... what was I thinking
… On Dec 7, 2019, at 4:50 AM, Radek Dutkiewicz ***@***.***> wrote:
Hats off to your commit a45bff8
It actually fixed the underlying problem. I have to admit that my commit was a workaround as I've decided to not to mess with the main loop too much.
By adding just:
case "left":
fe.signal( "prev_game" )
return true
case "right":
fe.signal( "next_game" )
return true
we have now proper transitions calling and acceleration.
Closing the issue. Thanks Andrew.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Let assume we want to remap the navigation buttons for a certain layout without remapping default controls in settings. When we intercept all the signals
up
down
left
right
and callnext_game
andprev_game
we have the following output in the log:As you can see the
EndNavigation
transition is only triggered for buttons that are mapped in Controls asnext_game
andprev_game
Here is a minimalistic code that is showing the problem