Did y'all happen to read my
console.json post? If not, please please read at least the
New Structure section and check out this
example. I put a lot of thought and work into the new structure and I think it solves some of these issues.
Let's refer to the goal of the controls.dat project: "to accurately document M.A.M.E. outputs by using the labels the games used on their control panels. The benefit of this is frontend developers can use these resources to display the controls for the games."
The data is explicitly intended to be used to enhance the MAME experience. It seems to me the primary use of this data is automatic configuration and labeling of controls in MAME; to prevent a MAME user from having to go through their entire game collection and manually map physical controls to MAME inputs for each game so they match the original machine; to prevent a MAME user from having to look up the instruction card/label for every control of every game in their collection so their frontend can display it correctly.
Again, the goal should be to enhance the experience of a MAME user who, 99.9% of the time, has a standard setup (control panel with typical controls).
1) How do we update it when a new mame comes out? How do we know what are new roms versus name changes? Since mamediff hasn't been updated in forever this makes it difficult, unless something new has come out?
How often do rom names change? Could we use git diffs to detect name changes? We could write a script that automatically applies name changes. Is there an authoritative list of all roms somewhere in the source we could monitor (maybe the roms' header files)?
2) How do we handle games with oddball controls or games where they have since changed what the default controls are? For example, some games could use a 49way joy and some an 8way joy and mame has since removed the 49way even though that is how the game was used most of the time. I am looking at you NFL Blitz.
Let's keep our goal in mind and remember that it is extremely unlikely that a MAME user will be using any of the physically unique or oddball controls or has any expectation of emulating them exactly. That said, I say we record the control but don't attempt to assign it an enumerated type. Frontends will not be able to automatically map the label to a physical control but that's OK. If applicable, we should define fallback controls that can be used instead of the oddball ones.
3) A redesign is needed. The project made it fairly far with the restriction of using confirmed documentation. Labels were based on actual control panel pics or manuals. A redesign needs to support both user submitted labels and confirm labels. It also needs to support the additional controls like NFL Blitz. In Blitz it is a dip switch to indicate 49 way or 8 way. I assume at this point is should be simple to read the dip switch settings in mame and what the user has them set to to automatically use the correct one.
In the
new structure I proposed, games can have multiple control configurations defined. This allows you to specify the mappings for both the 49way and 8way configurations of NFL Blitz. As you suggested, the frontend could read the dipswitch value and choose the correct configuration.
I am new to this project so I may not completely understand the problems that need to be solved, but I would love to help evolve this project.