The NEW Build Your Own Arcade Controls
Software Support => controls.dat => Topic started by: bobmoo79 on February 04, 2016, 12:03:08 pm
-
Is this still being maintained? there hasn't been an update (or a post here) for a while......
-
If it isn't dead, I'd say it's got both feet in the ground and the rest of the body is almost there too. For the last few years it was only SirP and Howard working on it (at least publicly). I wouldn't hold my breath waiting on an update. :-\
-
What happened is mame changed and made it more difficult to update the project. Every time I come back it becomes more difficult to deal with.
In order for the project to be able to be updated again we need to figure out a couple of things.
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?
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.
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.
If someone has an idea and wants to come up with a modern way to handle this by all means go ahead.
-
Well something interesting that's happened is mame's lua implementation. I haven't looked into it much, but you can display simple shapes and text on the screen and I believe you can read inputs and such. I'm just spit-balling here, but perhaps a dat could be made with whatever the internal names of these controls are.
Also mame now allows you to name an input and it will show up that way in-game when you are configuring controls. I'm not sure how open the mame team is to labeling controls internally (some games have it and some don't) but that would solve a lot of problems. I'm sure a lua script could be made to print out a game's controls on screen as well.
I really don't have much interest in resurrecting the project unless we get help. Sirp, myself and a couple of guys entered virtually the entire dat and I don't know about everyone else, but I about killed myself trying to get at least 30 verified entries a day.
-
Did y'all happen to read my console.json post (http://forum.arcadecontrols.com/index.php/topic,150639.msg1574431.html#msg1574431)? If not, please please read at least the New Structure (https://github.com/yo1dog/controls-dat-json#new-structure) section and check out this example (https://gist.github.com/yo1dog/a6d841e09b871e5f90fec3c4bca7f66f). 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 (https://github.com/yo1dog/controls-dat-json#new-structure), 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.
-
What is the status of this project? http://controls.arcadecontrols.com (http://controls.arcadecontrols.com) is dead atm ... I just got a couple of servosticks and registered LEDBLINKY, where do I get the latest controls file now?
Ledblinky site hosts version 0.111.3 - it is my understanding that this is not the most recent one.
TIA for any help!
edit:
found the missing INI zip and uploaded all stuff to mediafire just in case anyone else searches for them:
controls.ini.0.141.1.zip -> http://www.mediafire.com/file/b5ublb5ccw4x3ch/controls.ini.0.141.1.zip (http://www.mediafire.com/file/b5ublb5ccw4x3ch/controls.ini.0.141.1.zip)
controls.xml.0.141.1.zip -> http://www.mediafire.com/file/xwnb1pk6e5b7fnn/controls.xml.0.141.1.zip (http://www.mediafire.com/file/xwnb1pk6e5b7fnn/controls.xml.0.141.1.zip)
FEDEV.0.141.1.zip -> http://www.mediafire.com/file/52ibs0i2m4b5yey/FEDEV.0.141.1.zip (http://www.mediafire.com/file/52ibs0i2m4b5yey/FEDEV.0.141.1.zip)
saved webstite on Wayback Machine -> https://web.archive.org/web/20150220112407/http://controls.arcadecontrols.com/ (https://web.archive.org/web/20150220112407/http://controls.arcadecontrols.com/)
-
The project isn't being worked on, but the reason you can't access the site is because Saint hasn't restored all the hosted sites since the server move. Contact either him or Sirp for an update (I don't do the server end.)
-
Ledblinky site hosts version 0.111.3 - it is my understanding that this is not the most recent one.
I've updated the LEDBlinky site with the most recent version (0.141.1).