Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
01080 Interface Feature Have not tried Feb 9, 2008, 12:35 Dec 29, 2021, 15:06
Tester john_iv View Status Public Platform MAME (Official Binary)
Assigned To cuavas Resolution Fixed OS
Status [?] Resolved Driver
Version 0.122 Fixed in Version 0.239 Build
Fixed in Git Commit 7d1ff26 Github Pull Request #
Summary 01080: The \ctrl files don't override driver specific mappings.
Description The \ctrl files should override driver specific mappings.
For example:

If you have these mapped differently at the driver level [*.c] in a \ctrlr\*.cfg file or as individual games in the \ctrlr file the settings do *not* take. It is necessary to remap the games manually in-game via [TAB].

If you have a \ctrlr file it should take precedence over the internally hard-coded 'fresh' defaults.
Steps To Reproduce
Additional Information
Github Commit
Regression Version
Affected Sets / Systems
Attached Files
related to 02171Confirmed All sets that remap inputs in the source: Cannot map to "default" in "Input (this game)", so cannot use general inputs or ctrlr file with hardcoded maps 
User avatar
Mar 18, 2008, 01:14
This is actually by design, so I am recategorizing the bug as a feature request. I am still not sure it is the right thing to do, however.
User avatar
Senior Tester
May 18, 2008, 20:10
edited on: May 18, 2008, 20:22
One would think that the player not the driver author would be the ultimate arbiter of how they want the controls set up. Yes, the workaround is to map from w/in a game however the use of ctrlr files facilitates this on a large scale across multiple games in driver families.

Take the asteroid.c games for example. They are currently hardcoded and cannot be overruled by an asteroid.c section in the ctrlr file if I want D,F and J,K and Space as my control scheme across all of asteroid.c.

Ruling precendence should go from bottom to top level: driver hardcoded settings if there are any, ctrlr files, then individual game cfg imo.

Update: It appears w/ .125u1 that invaders.c, djmain.c, missile.c have been decoupled from hardcoding and work as expected. Asteroid.c however still has the issue. Updated driver info in the bug to reflect that.
User avatar
Aug 28, 2008, 22:18
There was a way to get the ctrlr file to work. It involved going into mame's "input (this game)" menu and change the offending inputs to "default" with enter esc (wait) enter esc. However, currently there's 02171 that you can't do this anymore. However you still can hand edit the game's cfg file and set the newseq to "DEFAULT", and the ctrlr file will work.
User avatar
Jan 4, 2014, 01:48
The workaround of hand editing the game config to "Default" does not work if you have Joysticks conigured in the ctrlr file.
ie. If the 2nd joystick is not plugged in (Often the case), The autogenerated "JOYCODE_*" becomes invalid and the entire game.cfg is erased next run!
User avatar
Dec 3, 2021, 22:09
Partially fixed starting with 0.234, but you have to map in the game or parent or source's system block, and include the tag, mask and defvalue, too, and not in the default system block.
User avatar
Dec 5, 2021, 16:19
There was a bug preventing specific input overrides from controller configuration being applied properly. I’m not sure if it was already there when 0.234 was released or if it crept in since then.
User avatar
Senior Tester
Dec 29, 2021, 05:32
Confirmed fixed on asteroid.cpp against official .239 and 0.238 (mame0238-405-g65f40d27812). Closing