Autoconfig should take priority over hard binds

[jvook]

Currently, autoconfig profiles for controllers will only load if buttons are set to "nul" in retroarch.cfg. It seems to me that it would be more user-friendly and intuitive to override hard binds with autoconfig profiles.

I can see there may be arguments against this (for example, maybe in arcade cabinets or retropie installations) but I'm unable to understand why the current behavior would be preferable.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[dankcushions]

Autoconfigs are the defaults, though, not an override. They are what the 'Default All' input option loads, in fact. see #2018

[Ryunam]

Current behavior allows much more flexibility and freedom in all cases where either the autoconfig is broken or, simply, you want to only change a few binds if compared to the autoconfig default.

[jvook]

Autoconfigs are the defaults, though, not an override. They are what the 'Default All' input option loads, in fact. see #2018

I think this is just semantics. The fact is that autoconfig profile will not override hard-binded buttons. This seems backwards.

Current behavior allows much more flexibility and freedom in all cases where either the autoconfig is broken or, simply, you want to only change a few binds if compared to the autoconfig default.

These issues are easily corrected by saving autoconfig profile if you don't like the default autoconfig.

[andres-asm]

I don't agree with this request.
Autoconf is a method to provide plug and play controller support. It's not
intended to override settings.

Hard maps should take precedence like they are song now.

On Tue, Sep 13, 2016, 8:42 PM jvook notifications@github.com wrote:

Autoconfigs are the defaults, though, not an override. They are what the
'Default All' input option loads, in fact. see #2018
#2018

I think this is just semantics. The fact is that autoconfig profile will
not override hard-binded buttons. This seems backwards.

Current behavior allows much more flexibility and freedom in all cases
where either the autoconfig is broken or, simply, you want to only change a
few binds if compared to the autoconfig default.

These issues are easily corrected by saving autoconfig profile if you
don't like the default autoconfig.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3581 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABpC0LQbSdHID6BwmGIX0CZurcC78F--ks5qp1EWgaJpZM4J8KKm
.

[jvook]

Plug and play controller support is not working if a user sets an autoconfig. Plug and play controller support only works with autoconfigs that are included in the distribution. Otherwise, hardbinds take control, and the user must take the counter-intuitive step of resetting all keys and buttons to default in order to activate the autoconfig that they just saved (not to mention custom keyboard configs are reset in the process).

[andres-asm]

And after such a profile is added plug and play works.
I understand your POV but I don't share it.

The only counterintuitive part of the process is having to hit reset. That
can be fixed but I vote the current behavior should stay.

On Tue, Sep 13, 2016, 9:01 PM jvook notifications@github.com wrote:

Plug and play controller support is not working if a user sets an
autoconfig. Plug and play controller support only works with autoconfigs
that are included in the distribution. Otherwise, hardbinds take control,
and the user must take the counter-intuitive step of resetting all keys and
buttons to default in order to activate the autoconfig that they just saved
(not to mention custom key configs are reset in the process).

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#3581 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABpC0Bk_5hUm5Qns_6KT-BGcgy-vk09Qks5qp1VngaJpZM4J8KKm
.

[jvook]

I think we disagree on the meaning of plug and play in this case.

I still see no proferred reason why the current behavior should stay. If it is some niche use-case, that can be easily rectified by a toggle to force hardbinds take priority, defaulted to off.

In any case, automatically resetting gamepad buttons only after saving autoconfig will result in identical behavior as requested in this issue, and allow the current behavior to continue.

[jvook]

Another solution would be a "Create Autoconfig" menu item that creates an autoconfig but does not modify retroarch.cfg

[andres-asm]

Actually after a lot of testing I agree.
Hard maps taking precedence is "safe" but your idea would be more useful to both people with hard maps and autoconf.

I had a reason to ask @twinaphex to make it like this but I really don't remember.

[kivutar]

@fr500 really?

The current behaviour looks perfect to me.

The user plug the joypad:

• If an autoconfig matches, the jobpad works. DONE.
• If no autoconfig matches, the user can do a manual bind. And then it works.
• If the user want to go further, he can save his manual config as an autoconfig.

I don't see how it's a niche use case.

Of course the fact that it still keep the manual bindings in retroarch.cfg is a problem. But it can be resolved easily by using the Bind Default All. Isn't it?

While if we make autoconfig override manual configs, the user loses the ability to override the autoconfig. And they will certainly complain about that.

[jvook]

@kivutar It's the same though in the proposed change:

The user plug the joypad:

If an autoconfig matches, the jobpad works. DONE.
If no autoconfig matches, the user can do a manual bind. And then it works.
If the user want to change the default autoconfig, he can save his manual config as an autoconfig.

Except now the user who is customizing/changing defaults doesn't have to take the strange step of Bind Default All, and losing all his keyboard binds in the process.

There are two possible options to correct this issue:

1. This proposed change
2. Save autoconfig command automatically resets gamepad buttons only

I'm okay with either.

[jvook]

There are two possible options to correct this issue:

1. This proposed change
2. Save autoconfig command automatically resets gamepad buttons only

I'm okay with either.

How would use of multiple players affect this?

Perhaps there is a reason to choose option 2 over option 1 in context of 2+ players.

[0x90shell]

I had to dig deep into the bug vault to find this gem, and I really can't understand the logic here. You've basically broken controller functionality when switching controllers, at least as P1, and when saving your retroarch.cfg. I created a systemctl service to null these bindings so autoconfig always works in the event of an accidental overwrite, but this seems like an extreme course. You could at least provide an option to prioritize autoconfig over retroarch.cfg hardcoded inputs. That way people don't have to go full neckbeard to fix this.

[0x90shell]

Script I'm automating to purge if controller configs accidently get hardcoded to retroarch.cfg

https://gist.github.com/0x90shell/f248cda6e78e763000cb78563c0949f3

[hizzlekizzle]

@0x90shell

You could at least provide an option to prioritize autoconfig over retroarch.cfg hardcoded inputs. That way people don't have to go full neckbeard to fix this.

Isn't that what the 'reset all to defaults' or whatever option does in settings > input > retropad binds > port X controls? That is, wipe out the manually applied binds so the autoconfig isn't superseded?