AW: [mupen64plus] mupen64plus doesn't seem to open InputAutoCfg.ini

[sven]

Why are you editing this file and not $HOME/.config/mupen64plus/mupen64plus.cfg ?

[William Shipley]

Editing InputAutoCfg.ini is far more convenient for adding controllers, especially if you plug/unplug the controllers often.

One issue that I occasionally come across: If mupen64lpus.cfg already has the entry for the controller you're using, (IIRC) it won't re-read the entry from InputAutoCfg. The easiest way around this is to run mupen64plus without a controller in (thus defaulting to the keyboard)

If the keyboard is what you're messing with, you can just delete the entire [input-SDL] section and it will be recreated on next run of mupen64plus with the new config from InputAutoCfg.

On Fri, Apr 12, 2013 at 1:16 PM, sven <sv...@narfation.org> wrote:

Why are you editing this file and not $HOME/.config/mupen64plus/mupen64plus.cfg ?

--
You received this message because you are subscribed to the Google Groups "mupen64plus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mupen64plus...@googlegroups.com.
To post to this group, send email to mupen...@googlegroups.com.
Visit this group at http://groups.google.com/group/mupen64plus?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Richard Goedeken]

Actually I'm really glad that this topic was brought up now, because I see
that the current system causes problems for some people. I am down to just 2
major things that I want to address before the 2.0 release, and this is one of
them.

I would appreciate it very much if everyone on this list who can take the time
would write up your thoughts on how you use the input configuration system in
mupen64plus, so that I can satisfy as many use cases as possible with the
upcoming revisions. I'll make a wiki page on the google code site to track
all the use cases that I'll support. In particular, I would like to know:

1. Which front-end do you usually use? I would like to hear from GUI users as
well as command-line users.
2. How do you normally use the input config? Do you edit the
InputAutoConfig.ini file? Edit the mupen64plus.cfg file? Change the
configuration with a GUI? Leave everything alone and let auto-config run?
Delete the mupen64plus.cfg file?
3. Describe any special use cases that you have. Do you often switch
controllers or always use the same setup?
4. Are there any problems that you have or annoying things about the current
system that you'd like to see change?

Please respond within the next week or two; I'm anxious to get 2.0 out the
door, after like 4 years. :)

Thanks,
Richard

[Sven Eckelmann]

[...]

> I would appreciate it very much if everyone on this list who can take the
> time would write up your thoughts on how you use the input configuration
> system in mupen64plus, so that I can satisfy as many use cases as possible
> with the upcoming revisions. I'll make a wiki page on the google code site
> to track all the use cases that I'll support. In particular, I would like
> to know:
>
> 1. Which front-end do you usually use? I would like to hear from GUI users
> as well as command-line users.

usually the ui-console frontend, but from time to time the wxmupen64plus
frontend.

> 2. How do you normally use the input config? Do you edit the
> InputAutoConfig.ini file? Edit the mupen64plus.cfg file? Change the
> configuration with a GUI? Leave everything alone and let auto-config run?
> Delete the mupen64plus.cfg file?

it is mostly not needed for me to adjust, but when necessary I edit
mupen64plus.cfg (through the file and when I am really lazy then through
wxmupen64plus)

> 3. Describe any special use cases that you have. Do you often switch
> controllers or always use the same setup?

Either using the same controller or in rare cases I use it without controller.
So I don't change the joypad, but joypad <-> keyboard.

> 4. Are there any problems that you have or annoying things about the current
> system that you'd like to see change?

I only would like to see a (not as a "I want that now" but as a "would be cool
to have that") ui feature (e.g. in wxmupen64plus or m64py) to save a current
mapping as profile for later. So you can easily switch the mapping fast and
reload a mapping after the joystick was changed.

Kind regards,
Sven

[William Shipley]

1. I always use the CLI frontend. The GUIs are just such a hassle in comparison.

2. InputAutoConfig.ini, occasionally deleting the Input-SDL section in mupen64plus.cfg to get it to refresh.

3. I switch controllers fairly often, to get multiplayer and for the occasions I need a joystick. Also, some games don't like having the dpad and joystick overlapped (Zelda MM in the menu, for example)

4. I would love it if InputAutoCfg.ini was in the same place as mupen64plus.cfg. It doesn't make much sense to me to have one be per-user and one be system-wide. Either way is fine, since I run a single-user machine, but it would be nice if it was consistent.

[Richard Goedeken]

Thanks to William, Sven, and Tony for their input on mupen64plus configuration scenarios.  I wrote up a wiki page on some use cases and the new design change here:

http://code.google.com/p/mupen64plus/wiki/InputPluginUsage

I just committed a complete re-write of the input autoconfiguration code in the Hg repository.  I think this will be a big improvement: it should support more use cases and be more user-friendly.  I believe that it solves all of the common stumbling blocks that people ran into with the old design.

I would appreciate it if as many people as possible could update to the head and try it out with your systems.  It should automatically clear out your old config sections and set everything up for full auto.  You can read the wiki page and tweak the setup for your individual needs.  Auria, it should create all 4 config sections by default to solve the problem with your wx front-end.

I'm looking forward to everyone's feedback.

Thanks,
Richard

[Sven Eckelmann]

On Sunday 19 May 2013 10:53:15 Richard Goedeken wrote:
> Thanks to William, Sven, and Tony for their input on mupen64plus
> configuration scenarios. I wrote up a wiki page on some use cases and the
> new design change here:
>
> http://code.google.com/p/mupen64plus/wiki/InputPluginUsage
>
> I just committed a complete re-write of the input autoconfiguration code in
> the Hg repository. I think this will be a big improvement: it should
> support more use cases and be more user-friendly. I believe that it solves
> all of the common stumbling blocks that people ran into with the old
> design.
>
> I would appreciate it if as many people as possible could update to the head
> and try it out with your systems. It should automatically clear out your
> old config sections and set everything up for full auto. You can read the
> wiki page and tweak the setup for your individual needs. Auria, it should
> create all 4 config sections by default to solve the problem with your wx
> front-end.
>
> I'm looking forward to everyone's feedback.

I've added new experimental, prebuild binaries for Windows [1], Debian [2,3] and
Ubuntu [4].

Happy testing,
Sven

[1] https://bitbucket.org/ecsv/mupen64plus-mxe-daily/commits/cea500a63f36a3d833ecf140b918d0131bb0a6d0
[2] http://packages.qa.debian.org/m/mupen64plus-input-sdl/news/20130519T193306Z.html
[3] http://packages.debian.org/source/experimental/mupen64plus-input-sdl
[4] https://launchpad.net/~sven-eckelmann/+archive/ppa-mupen64plus