Software Support > controls.dat



Disclaimer: I am new to the controls.dat project.

First, I thought it was crazy that the project didn't have a JSON format (who uses XML anymore? :P) so I wrote a script that converts controls.xml into controls.json.

Then I started trying to use the data in a utility project I started. I found the structure of the data in the controls.dat project a bit archaic, convoluted, and difficult to use. So I created a new structure for the data (uncreativly named restructuredControls.json). I wanted something that I could import into a project and be able to use quickly and easily. The controls.dat structure requires a lot of flag checking and/or preprocessing due to the many implicit relationships and values. I am focused on utility projects based around ROM management with an emphasis on control panel planning and automatic control panel layout/input configuration. So, I want data that I can use to programmatically define control panel requirements and map MAME inputs to physical controls that most closely emulate the actual cabinets layout for the average MAME cabinet.

The new structure also allows the details of a game's controls to be stored more precisely and in greater detail. It also updates the way the MAME input ports are stored so it is compatible with the latest MAME version (no more _EXT inputs).

Everything is written in Node.js (JavaScript) and in this github repo:

The README has all the details about the scripts/tools, JSON files, and new structure. Here are direct links to the v0.0.1 generated files:


Let me know what you guys think.

If yo1fog's structure is acceptable, I might be able to help with the MAME game name change concern.

I could write a tool that takes the mame names in the controls xml, and compares them to the names in the mame list xml. Then I could perform a diff with a nice, clear UI representation of changes. It would allow you to manually check which names are unique in controls.xml over the MAME list (perhaps because MAME games were removed or renamed between versions). That would at least give us a fighting chance of keeping uptodate, though it would not be fully automated.

We could also update yo1fog's structure to include rom checksums so we can match records up again when names change.

Further, we could turn the 'label', 'negLabel', etc., properties into full objects. Then we could include the property 'source' for each. The value of which could be 'user_submitted', 'control_panel', etc.

I don't like moving away from xml though. Json's only advantage is for web downloading. We lose schemas, comments, and the nuances of attributes. But the structure review could start with what is suggested in the json sample.

This project is crazy important. PM me if I can help. I do all sorts of stuff like this:


[0] Message Index

Go to full version