Closed canthonyscott closed 8 years ago
Please can you post the configuration files before and after your fixes. The input configuration is generated from the controller setup within emulationstation.
Absolutely. The relevant section of the file is below:
ORIGINAL InputAugoCfg.ini:
[Microsoft X-Box 360 pad]
[Microsoft X-Box One pad]
[Win32: Controller (XBOX 360 For Windows)]
[Win32: XBOX 360 For Windows (Controller)]
[Win32: XBOX 360 For Windows]
[Xbox 360 Wireless Receiver]
[Linux: Xbox Gamepad (userspace driver)]
[Afterglow Gamepad for Xbox 360]
plugged = True
plugin = 2
mouse = False
AnalogDeadzone = 4096,4096
AnalogPeak = 32768,32768
DPad R = hat(0 Right)
DPad L = hat(0 Left)
DPad D = hat(0 Down)
DPad U = hat(0 Up)
Start = button(7)
Z Trig = axis(2+)
B Button = button(2)
A Button = button(0)
C Button R = axis(3+)
C Button L = axis(3-) button(3)
C Button D = axis(4+) button(1)
C Button U = axis(4-)
R Trig = button(5) axis(5+)
L Trig = button(4)
Mempak switch =
Rumblepak switch =
X Axis = axis(0-,0+)
Y Axis = axis(1-,1+)
My Changes:
[Microsoft X-Box 360 pad]
[Microsoft X-Box One pad]
[Win32: Controller (XBOX 360 For Windows)]
[Win32: XBOX 360 For Windows (Controller)]
[Win32: XBOX 360 For Windows]
[Xbox 360 Wireless Receiver]
[Linux: Xbox Gamepad (userspace driver)]
[Afterglow Gamepad for Xbox 360]
plugged = True
plugin = 2
mouse = False
AnalogDeadzone = 4096,4096
AnalogPeak = 32768,32768
DPad R = hat(0 Right)
DPad L = hat(0 Left)
DPad D = hat(0 Down)
DPad U = hat(0 Up)
Start = button(9)
Z Trig =button(7)
B Button = button(2)
A Button = button(0)
C Button R = axis(2+)
C Button L = axis(2-) button(3)
C Button D = axis(3+) button(1)
C Button U = axis(3-)
R Trig = button(5) axis(5+)
L Trig = button(4)
Mempak switch =
Rumblepak switch =
X Axis = axis(0-,0+)
Y Axis = axis(1-,1+)
In addition to modifying the C-buttons, I also edited the n64 start button (originally on the xbox360 R-trigger) to assign it to the xbox360 start button (button 9), and moved the n64-z-trigger from the Axis2+ to the xbox360 R-Trigger (button 7).
I also made these same changes in the mupen64plus.cfg file, but they did not seem to change anything. I had to make them in the InputAutoCgf.ini file for them to work.
Proper formatting for large code blocks are three back ticks ```
For future reference refer to my edits on your post above (the pastebin link was broken also)
Apologies, three backticks followed by a linebreak. markdown is fun. I worked with gizmo on the n64 config generation I can test it as well
Thank you very much!!! I removed the unnecessary link now the code block looks much better.
@canthonyscott how did you configure your xbox controller? Did you use the xboxdrv driver?
I remember when I was testing with gizmo if there was already a config there (the default) the autoconfigs would conflict if there was a config for an existing controller (like the xbox 360) I'm also not sure how it is affected by using the driver vs not using it as it will treat the axes differently depending on which you use.
On top of that there are config issues with the latest kernel for xboxdrv.
So I installed everything fresh using a downloaded SD-card image, on first boot I used a simple USB controller I had laying around and configured it. Using that controller I enabled the xboxdrv driver, shutdown, plugged the xbox360 wireless receiver in, booted up and the configured that wireless xbox360 controller using the Emulation Station menus.
I see. just out of curiosity if you delete the InputAutoCfg.ini (you can back it up first for safety of course) and then reconfigure your controller in emulationstation it should generate another inputautocfg.ini how does it compare to the original?
After deleting it and re-configuring the control this is what was generated. This userspace driver heading was not present on the previous one.
[Xbox Gamepad (userspace driver)]
plugged = True
plugin = 2
mouse = False
AnalogDeadzone = 4096,4096
AnalogPeak = 32768,32768
Mempak switch =
Rumblepak switch =
C Button D = button(0) axis(3+)
C Button L = axis(2-)
R Trig = button(7)
L Trig = button(4)
Start = button(9)
Y Axis = axis(1-,1+)
Z Trig = button(6)
DPad U = hat(0 Up)
C Button U = button(2) axis(3-)
A Button = button(1)
DPad D = hat(0 Down)
X Axis = axis(0-,0+)
DPad R = hat(0 Right)
B Button = button(3)
DPad L = hat(0 Left)
C Button R = axis(2+)
; Xbox Gamepad (userspace driver)_END
so with the latest changes are there any input issues with the C buttons in gameplay or is it working as intended?
(I don't play the n64 much so I dont know which buttons are supposed to do what)
The C buttons appear to be working as intended. Re-configuring the controller never changed anything(i tried multiple times), but deleting the InputAutoCfg.ini and then Re-configuring the controller as you just had me do appears to have correctly assigned the buttons.
TADA!
related pull request:
https://github.com/RetroPie/RetroPie-Setup/issues/729
@joolswills this is essentially the same reason we removed all the preconfigured controls for retroarch when we generated the retroarch auto-configs. the pre-existing configs cause conflicts.
@gizmo98 what are your thoughts on this
Just for more info. Running the scripts to update all retropie packages causes the InputAutoCfg.ini file to be replaced with the non-working one in my original post.
@HerbFargus sorry i have not seen your post. Reconfiguration should work as long there are "frames"around each controller config. Our controller config creates these frames. If you use the original inputautoconfig.cfg with controller presets controls will not be reconfigured. I don't know why it shouldn't work anymore. canthonyscotts ini file looks like the original one. Our install script should delete this file. As far as i know there was a change so the install script will not overwrite existing config files.
we only don't overwrite the mupen64plus.cfg - the code still does
# remove default InputAutoConfig.ini. inputconfigscript writes a clean file
rm -f "$md_inst/share/mupen64plus/InputAutoCfg.ini"
it would be best to check if the existing file is our generated one and if so do nothing (so we dont remove existing configs), or if an old one, do the overwrite.
Seems like an old config file because we do not create such structures:
[Microsoft X-Box 360 pad]
[Microsoft X-Box One pad]
[Win32: Controller (XBOX 360 For Windows)]
[Win32: XBOX 360 For Windows (Controller)]
[Win32: XBOX 360 For Windows]
[Xbox 360 Wireless Receiver]
[Linux: Xbox Gamepad (userspace driver)]
[Afterglow Gamepad for Xbox 360]
@gizmo98 is the code I pasted above correct ? the input configuration script creates a InputAutoCfg.ini in $configdir/n64 but the above code removes a config from $md_inst/share/mupen64plus
- was there an older config in the other location then ?
This is wrong. Removal should happen before line 136 is reached.
you mean before we run mupen64plus ?
ah you mean before the config files are copied?
Correct ;-)
then it should probably be removed at the install stage and binaries rebuilt.
i'll do that now.
Yes, package size will be a little bit lower.
Thanks for the help. I made the change / rebuilt the binaries.
This is specific for the Mupen64plus emulator and the xbox360 wireless controller:
The default controller mappings for some of the C buttons show they are mapped to an axis (4+) and (4-). Only, after setting up my xbox360 controller, those axes don't seem to exist. The R-analog stick exists on axis 2 and 3.
This can be fixed by editing configuration files, but was initially very confusing on the inital setup as to why I could not find these buttons. Should these defaults be changed?