-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature request] Input mapper macros #8209
Comments
This is kind of a duplicate, if much leaner and meaner than my own: If you tl;dr i first proposed a extensive system with a GUI for input capture and then had a brainwave in further replies and went 'retroarch is already going to do a parser because it has the idea that everything configured is saved as text; so you might as well make it import stuff from the clipboard and people will check forums and copy paste the macros there, no GUI except to show the macro/macro name even necessary'. The largest challenge of a 'minimal' setup like that that doesn't depend on input skill or complex new GUI components is designing the language so it can be extensible and hammer down the complex use cases: Two or more buttons at the same unit of time time; is button press and button release required or repeating all the info of what is pressed on each unit of time?; what's the 'interval of each time unit' in the parser; is it feasible to extend the language to handle analog movement and how should time intervals be treated for analog movement and curves? Predefined analog curves are a good idea or do they explode the combinatorics too much? How to handle the speed of analogic movement (ie: spread them over more than one unit of time for 'slower' movement? Should users be able to tell where they are at each stage?)?; Half pressed buttons for analog buttons how? Is extending the 'analog curve' idea to 3D completely crazy (for the wii and gyroscope enabled portable controls)? Is pressing a extra normal controller button going to interrupt the macro or try to 'merge' the input to the macro? , etc. Then you'd do a grammar in byson or antlr, output the C file version of the parser, throw a error if someone screwed up and you'd get no chance of buffer overruns. Import more than one at a time ofc . If you want to be nice show exactly what line/column of the input screwed up. |
I don't think input replaying is within the scope of the original issue and from what I saw on the chat many people are against the idea. That would be overblowing the problem into something way more complex that what's needed to fix libretro/fbalpha#124 I did like that thing in zsnes (hotkey for hadoukens) but tbh I don't see the point. |
There is a difference? Autofire is different, being focused on the largest possible number of repetitions on the smallest recognizable interval, but i conceptualize 'input mapper macros' as pretty much exactly the same as my issue. What's the difference? Also why would people be 'against' the idea? Disable it on netplay if it's a 'competition' problem (even though, things like this can be done non-portably with autojoykey). |
Input mapper macros mean rewriting input within one frame. To represent a macro I can use an integer, for instance say I want a button to trigger B + A, that would be.... 3 if I represent inputs as bits following retropad.
What you're proposing is far more complex and as I said is something that needs to be done along a timeline (some miliseconds or even complete frame delays). I'm not against your idea but I'm the only one who has worked on the input mapper and I'm against the idea of implementing such a complex thing. |
Thats... well, a feature that i wouldn't use very much. Could be useful to enable modifier keys shortcuts if it can be mapped to 'always pressed' even if you don't press anything but little else. Timelines are hard thou, i agree (especially if you want to accommodate analog input). |
It would allow core agnostic implementation of common combos (three punches in fighters), etc. |
You could essentially implement this in the same format (as a 'single unit of time') and leave the door open to extensability to timelines later. Even including the rudimentary copy paste parser instead of multiple drop-down input remappings. Not sure if it's better for users actually. People writing "double punch - A B", copy that from a text file or forum and pasting in the RA window is cool, but RA has some platforms where c&p are not available. Then again, RA always needs cfg editing and that route is always assumed possible. |
Please help implementing these button combinations for neogeo games :
|
#7467 |
It would be nice if a third button for A+B could be added to all 2 button games so that most beat them up games could benefit from it. |
Just wanted to add my support for macros. I'm playing through a NES game called Full Quiet and in order to manually reload you have to double-tap up on the d-pad. Would be nice if I could program a macro to do that whenever I press a given button on my controller (like Y). That's how it works in the Steam release (it has some quality of life features like this). |
We need something frontend side to handle macro/autofire, currently the only way to do this is core side through core options, however it can be a source of netplay desync.
FBAlpha's core options to handle macro/autofire stopped working (https://github.com/libretro/fbalpha/issues/124), i don't intend to fix this, and will remove it completely instead, because it was never a good idea to handle it that way.
While i don't use it myself, i think this feature is important, and having this feature implemented frontend side would benefit all cores and solve netplay issues.
The text was updated successfully, but these errors were encountered: