Wandering USB Controller Order

[vindic8r]

So I'm another victim of MAME's inconsistent USB controller assignments, it seems. Every time I reboot my cab and go back into MAME, my spinner, trackball and guns switch up the numbers assigned to them in MAME. So to get them to work, I have to manually reconfigure them each time. Strangely, my USB Ultra-Stiks don't share this issue. All of my devices, including the sticks, go into a mini-USB hub I picked up on Newegg:
http://www.newegg.com/Product/Product.aspx?Item=N82E16817659004

It looks like my solution, until someone in the MAME dev community has a chance to fix this properly in Input.c, is to use drventure's extremely handy ControllerRemap tool. I've started to dig into the docs and wanted to confirm that I understand the process correctly.

My plan:

• Run ControllerRemap /list and generate my list of devices and their USB HID VIDs and UIDs.
  DONE. See attached. Note that the USB port is the same for all, which I assume is because they're all going into the HUB.
• Figure out what device is what, by plugging/unplugging devices and repeating step one. Fortunately, I've already narrowed the list down a bit, just by looking at device details in Windows. Notes included in attachment.
• Reboot a few times and get an understanding of what portion of each HID VID + UID is constant. Clearly, something is changing every time. Shorten the controller ID to only reflect what is constant.
• Start MAME, and map the controller via the configuration screens
  
• Quit MAME
• Open the “default.cfg” file from the .\cfg folder in Mame in your favorite text editor.
• Find the applicable controller mapping entries, and copy them over to your custom mapping controller file stored in the .\ctrlr folder, placing them into the appropriate <system>/<controller> element
• Add the “id” attribute to the <controller> element to identify which controller this element corresponds to
• And finally, remove any JOYCODE_#, MOUSECODE_#, or GUNCODE_# numbers, since they aren’t necessary and will likely just be confusing (note, however, that ControllerRemap will ignore any of those numbers so this step isn’t technically necessary).
• Define controller aliases in MOTUMAME.cfg in the /ctrlr folder (if desired - I probably will)
• Backup MOTUMAME.cfg
• Execute remap .\utilities\ControllerRemap.exe /remap:\games\emulators\mame\ctrlr\MOTUMAME.cfg
• Open MOTUMAME.cfg and make sure everything looks good
• Run MAME to test
• If working, proceed to reboot machine for final testing, if not repeat above steps to adjust for any bugs/issues.
• Configure HyperSpin/HyperLaunch to run, using MydknyteStyrm's advice. I'll also need to add the remap function, though, so my command line for ControllerRemap.exe being called by HyperLaunch is going to be more like ControllerRemap.exe /remap:\games\emulators\mame\ctrlr\MOTUMAME.cfg

Does this all sound right? Any advice or tips would be greatly appreciated!

[yotsuya]

I know the good Dr. is super-busy, but I would love a GUI for the program. 

[processedmeat]

Same here. I would pay good money for an easy to setup version.

[drventure]

Yeah, I'd investigated what it'd take for a Gui, but basically, you're talking about essentially recreating the Mame controller setup functionality. And that was just going to be too much for me to take on.

Ideally, I'd just fold the remapping functionality in controllerremap directly into input.c in mame. That would likely be the least amount of work, and give the cleanest possible experience for people.

One of these days, I might take that on. Or if someone's interested, I might open up the code and help where I can with modding input.c

[drventure]

Just looked over your device list.

Looks like the sticks should be easy. I'm not sure what the ATRAK devices are, but they show as joysticks.

The mouse devices you'll have to use the HID numbers to ID, BUT you only have to use enough of the id to uniquely identify the device. See the doc file for a good example on that.


For testing purposes, the /test command line switch (and a file compare utility) can really come in handy. That way you don't have to actually continually run MAME in order to generate and check your mapping.

I know it's not the friendliest of contraptions, but once you get it going, it seems to work pretty stably.

[vindic8r]

Just looked over your device list.

Looks like the sticks should be easy. I'm not sure what the ATRAK devices are, but they show as joysticks.

The mouse devices you'll have to use the HID numbers to ID, BUT you only have to use enough of the id to uniquely identify the device. See the doc file for a good example on that.


For testing purposes, the /test command line switch (and a file compare utility) can really come in handy. That way you don't have to actually continually run MAME in order to generate and check your mapping.

I know it's not the friendliest of contraptions, but once you get it going, it seems to work pretty stably.

Thanks for the tips, drventure. FWIW, I found ControllerRemap easy enough to use, after reading the docs. It's MAME's error logging that I'm a bit frustrated with at the moment. And I too would rather see Input.c updated than a GUI for ControllerRemap. Better to heal the wound then make a nicer band-aid for it. 

I was able to build a new custom ctrlr mapping. But when I try to load into mame (groovymame 64, to be precise), it craps out. If I change nothing, but drop into the same game without the ctrlr file, the game (Area 51), loads in fine. So it's gotta be the .cfg file.

I've attached my .cfg file as well as verbose MAME output. I don't see anything in the output that is indicative of what the issue might be. And the XML file seems well-formed to me.

Any ideas?

[drventure]

Odd. I ran it through an XML validator and it checks out, so it doesn't look like bad xml.

And from what I can tell, controllerremap is recognizing your controller elements and mapping them.

You aren't running a very old version of Mame are you? I'm running 1.29 which is pretty old, but works just fine as far as I can tell.

I'll look at it again later with fresh eyes, but things sure look right to me right now.

[vindic8r]

I'm running the latest version of Calamity's GroovyMAME 0.149 w. SwitchRes v0.014b.

I'll give it a try tonight with MAME64 0.149 as well.

[vindic8r]

I tried it tonight with MAME64 0.149b. Still no dice. I've attached a log file.

[drventure]

Ok. this is probably a silly question, but when you run MAME are you specifying the ctlr file?

ie

Mame {romname} –ctrlr motumame.cfg

[vindic8r]

Yep. That's the only difference between when it works and when it doesn't. The -ctrlr parameter.

[drventure]

I just tried from the command line, loading your cfg file.

I gave you the wrong command line.

don't specify the .cfg extension, so just

Mame {romname} –ctrlr motumame


When I load from command line with the cfg extension, I get a message "Unable to load motumame.cfg.cfg"

So it appears that mame wants to add the extension.

When I took it off, it loaded up fine.

[vindic8r]

Of course! I'll give this a whirl back when I'm in front of my cab next, hopefully tonight.

[vindic8r]

Sorry for the delay. Went out of town for a wedding.

This did the trick! So all is well now, except one minor issue. On my CP, I've got P1 B1 mapped to both L-Control and Trackball B1 (lft mouse button). P1 B1 is also mapped to Gun 1 B1. Herein lies the trouble. Where in my .cfg do I define this button? Should it be under Gun 1, or under the trackball? I've currently got it defined under Gun 1, and the result is that Gun 1's trigger doesn't work properly. It's very odd, though, given that the GUNCODE_X_BUTTON1 assignment seems correct, while the MOUSECODE_X_BUTTON1 assignment is not.

Note that Gun 2's trigger button works perfectly, so I'm pretty confident this has something to do with the mouse button assignment.

Any ideas what to try? My post-ControllerRemap'd .cfg file is attached, so you can see the output.

[drventure]

I'm not positive it would make a difference but shouldn't there be a OR between the LCONTROL and the MOUSECODE


GUNCODE_BUTTON1 OR KEYCODE_LCONTROL (OR) MOUSECODE_BUTTON1

I can't test right now to be sure, but just glancing at my other CFG files, they all have OR between the different input  map elements

[vindic8r]

The lack of the OR is because, I think, my P1B1 is wired to be dual-purpose, and fires both a left mouse button signal and L CONTROL.

I worked around this issue by just disabling the left mouse button input in the file. So my Gun 1 button mapping became:

Code: [Select]

<port type="P1_BUTTON1">
          <newseq type="standard">
                    GUNCODE_BUTTON1 OR KEYCODE_LCONTROL
          </newseq>
</port>
I don't know of any games that use the left mouse button as input. Hopefully, there aren't any. In which case, this should work smashingly.

Thanks for all the help, drventure. You truly saved my cabinet with this little program of yours. Or at least saved me countless hours of reconfiguration every time I restarted the cab. If you lived in the Chicago-area, I'd totally invite you over for the MOTUMAME launch party.

[drventure]

As far as I know, mame needs the OR between all the different input types or they won't map properly (ie you can't tell mame that P1B1 is triggered via a KEYBOARD_LCONTROL +and+ a MOUSE_BUTTON1. It's always one or the other, but not both.

I've actually got the top 3 buttons on my P2 setup to be P2B1-B3, but they are wired to B1-B3 on my trackball one.

I did this so that, outside of Mame, I can use the trackball as a mouse and the mouse buttons are conveniently those top 3 buttons on the P2 cluster, but INSIDE mame, they act just like any other P2B1-B3 would. Works a treat.

But, if you don't have your buttons wired that way, you shouldn't need to bother with the mouse code mappings.


I used to work for a company in Schaumburg, so I have some good memories of Chicago (at least the Chicago land area).

I haven't been up that way in ages though.

Hoist one for ControllerRemap at the party and I'll be good!