controls.dat or similar support via MAME Lua plugin

[Stiletto]

MAMEdev is talking about bringing part of the controls.dat functionality into MAME. We were getting a number of pull requests submitted externally by users to change the button descriptions in the internal UI from how they are currently listed in the sourcecode to how they are described on actual control panels, we could see this getting tiresome quickly, and decided to explore loading this information via a Lua plugin and have the button descriptions be externally maintained and localizable. This of course made me think of the old "controls.dat" project.

Thus far, early work in this direction is here, and will be in the next release. At the moment, the file format is very simple and not as detailed as controls.dat. Of course, we know about all the verified button info contained within controls.dat xml/ini files.

https://github.com/mamedev/mame/tree/master/plugins/portname

We may end up going in a different direction.

[yo1dog]

Regarding the structure, a few years ago I put a lot of time and effort into restructuring the controls.dat project. The details are here:
https://github.com/yo1dog/controls-dat-json#new-structure

Posted about it here:
http://forum.arcadecontrols.com/index.php/topic,150639.0.html

If the purpose of the extension is to simply map labels to input ports, then such a detailed structure would not be necessary.

[Howard_Casto]

I'm not sure how I missed this, but I'll reply now anyway. 

One of the main goals of controls.dat was to present the data relative to the user's actual control panel and how they had buttons mapped for that particular game, which I'm sure you know already.  That is what all the extra data is for.  Although I had some additional filtering that just made things look a bit nicer, how I did it was extremely simple.  A static image of the control panel is displayed on the screen.  Multiple labels could be defined by the user and each label had a x/y position and a button or key (or analog stick direction or whatever) assigned to it.  As mame inputs (and the control descriptions) were read in, the button/key assignment for that game was also read.  Next every label was checked to see if it's key/button assignment matched the mame input's assignment and if so, that label's text was set to match the control description. 

I haven't played with mame's lua plugin system at all, but if it can display an image on the screen and populate labels as I just described, a control viewer with nearly the same functionality of Johnny 5 could be recreated in script thus eliminating a lot of headaches involved in having a control viewer popup in mame on the fly.  If I can help in any way let me know as controls.dat was originally created out of frustration that mame didn't label inputs internally.  It would be great to just have that feature included.

[yo1dog]

Howard, I am interested in your solution for automatically mapping controls to a user's actual control panel. That was a heavy (if not the main) focus for the new format I implemented my controls.json project. I mostly curious about how you automatically map buttons to the correct one on a control panel.

Overall, my objective was to accurately describe games' native control panel(s) in a way that facilitated automatically mapping controls to a user's actual control panel. This greater detail also serves the historical/archival aspect of the MAME and control.dat projects.

One of the key considerations was the physical location/layout of buttons. Some games play extremely awkwardly if the buttons are not mapped correctly and most control panels use the same standard button layouts. Another example are buttons on other controls like trigger/flight sticks.

[Howard_Casto]

It's nothing magical really, I just read the cfg, ctrlr and ini files for the game loaded, so I would have two bits of data, the control description (aka the label/text) and the button/key/whatever it's mapped to according to the files.  So now you have that.  Then there is a separate document defining the users control panel layout that doesn't really have anything to do with controls.dat.  It has a bunch of labels, with each label having a button/key/whatever and a position on the graphic.  Now you just compare the two files....  Since they both have a button/key/whatever defined, you just apply the control description to any control panel label that matches the key determined in the controls.dat data. 

Of course I'm over-simplifying.  The viewer also checked various settings within mame, so that... let's say some of your control panel labels are mapped to the mouse, and you don't have the mouse enabled in mame, those labels are left blank.  In addition there was an order in which the cfg/ctrlr/ini files has to be read as they override each other in mame.  There's a ton of other little things that were read in, some hard-coded control constants that mame won't print out on cfg files, ect.  It was actually quite a hassle to get things working right, which is why it'd make more sense to get the data inside mame itself.... no more mucking about through half a dozen cfg files to determine how mame has a particular control mapped.  I would go into further detail, but mame has changed a lot since the last version of johnny 5, so a lot of my info isn't going to apply anymore.