Main > Software Forum
LEDBlinky - Arcade LED Control software and Animation Editor - v8.2
djm468:
So to clear up some confusion out there (and in here at the moment, as I am not 100% sure yet), all of the files (ctrlr, cfg, etc.) must be "right", but there may be cases where MAME and LEDBlinky disagree on what is right. This is probably what random posters over the years have reported as "lighting the wrong buttons for some games".
For example, if a control works in MAME, but LEDBlinky doesn't see it or vice-versa. Obviously, in a perfect world, LEDBlinky would use the same logic to determine the controls as MAME.
For starters, MAME respects None and LEDBlinky does NOT (at least in the case of inc/dec) and it doesn't make any difference if ctrlr or cfg is used. That one I'm 100% on and the results can be very confusing for implementers and users alike.
So what is the order for checking these files? I imagine it looks in the game-specific cfg first and if not there, then what? MAME looks in the game-specific ctrlr and then falls back to default ctrlr (all one file). Not sure where default.cfg fits in exactly, but shouldn't matter for my setup, as default.cfg is and always has been:
<?xml version="1.0"?>
<!-- This file is autogenerated; comments and unknown tags will be stripped -->
<mameconfig version="10">
<system name="default" />
</mameconfig>
...as it is basically useless. To see why, set up joystick controls with a gamepad plugged in, close MAME, unplug the gamepad, restart MAME and... oops, all that work down the tubes. That's why I put everything in the ctrlr file.
And there are more complications, as documented by the inc/dec stuff not working per the above, requiring the use of cfg files, where none should be needed. That seems to be a bug in MAME and leads specific game "drivers" to internally assign whatever they want for inc/dec (e.g. Tron uses X and Z). Am certain that LEDBlinky is not hip to those machinations either and the workaround is to copy redundant inc/dec sequences to individual game cfg files. Then MAME acts as expected and LEDBlinky can figure out what to do.
djm468:
Also, let's take the example of Tron and the requirement to add (otherwise useless) DIAL_EXT PORTs to the ctrlr (or game-specific cfg) file (else LEDBlinky gets confused). If you go into the in-game menu for Tron and select Input (This Machine), you won't see DIAL_EXT anywhere. I've never seen any _EXT suffixes on those screens.
I have one INPUT in my tron.cfg:
<input>
<port tag=":ssio:IP1" type="P1_DIAL" mask="255" defvalue="0">
<newseq type="increment">
KEYCODE_7PAD
</newseq>
<newseq type="decrement">
KEYCODE_9PAD
</newseq>
</port>
</input>
...which prevents MAME from substituting X and Z. I used to use None for these, but that confuses LEDBlinky. There is an identical entry in the ctrlr file, which is ineffectual due to whatever the game's driver is doing internally. And the final kicker is that there is a similar entry in the ctrlr file for player 2 and it works without recreating it in the tron.cfg file.
<port type="P1_DIAL">
<newseq type="standard">
MOUSECODE_XAXIS OR JOYCODE_1_XAXIS
</newseq>
<newseq type="increment">
KEYCODE_7PAD
</newseq>
<newseq type="decrement">
KEYCODE_9PAD
</newseq>
</port>
<port type="P2_DIAL">
<newseq type="standard">
MOUSECODE_XAXIS OR JOYCODE_2_RXAXIS
</newseq>
<newseq type="increment">
KEYCODE_7PAD
</newseq>
<newseq type="decrement">
KEYCODE_9PAD
</newseq>
</port>
All quite ridiculous on MAME's part, but completely predictable once the rules are reverse-engineered. The source code would reveal all of this as well, but would likely take much longer to figure out. And the documentation is obviously lacking, with decades of confused forum posts to further cloud the issues.
djm468:
In controls.ini:
;;Controls.dat INI file Version=0.141.1, Time=2011-01-05 18:17:26, Generated by=SirPoonga
SirPoonga used an odd structure to define analog controls. Or perhaps it is just antiquated, as _EXT suffixes don't seem to appear in the typical MAME configuration (or any that I've seen) and doesn't translate directly to what does appear in MAME configurations. I suppose it's fine for a "database" full of control labels.
It's consistent throughout, like this:
P1_AD_STICK_Y=Increase Edge
P1_AD_STICK_Y_EXT=Decrease Edge
In the odd case where an LED indicator would exist for an AD stick (or the stick is illuminated), I'd expect LEDBlinky to say something like: "Increase Edge and Decrease Edge", plus anything associated with P1_AD_STICK_X and P1_AD_STICK_X_EXT, while blinking.
But the more common case, where there are only the digital translations to consider, LEDBlinky should be looking at the increment and decrement entries for input codes (or the lack thereof):
<port type="P1_AD_STICK_Y">
<newseq type="increment">
KEYCODE_7PAD
</newseq>
<newseq type="decrement">
KEYCODE_9PAD
</newseq>
</port>
But my experience with dial-based games showed it looking for the _EXT version in the ctrlr or cfg files to figure out the increment half of this. And as the _EXT version isn't necessary for MAME (the above says it all) and isn't even presented in the UI, it's a quandary with no formal documentation that I could find.
Was glad to see that new versions of thing thing are still coming out. April of this year? There appears to be a couple of typos in the timeline (2020 instead of 2022 I think). I'd say the _EXT thing, None handling and honoring per-game entries in the ctrlr file (if that's not currently working) would help a lot.
One workaround for the _EXT issue is to just remove all of those entries from controls.ini. Neither my spinner nor my flight stick have LEDs, so those entries don't matter. Or make sure that every _EXT variation is defined in the ctrlr file. They don't need to be in the cfg files (even for the "problematic" games like Tron), as this is strictly an LEDBlinky workaround.
The workaround for None is to assign unused keys instead. Really only need one "dummy" key for this.
Will be interested to see if the per game ctrlr entries work...
EDIT:
After a little more thought, I realized the first workaround for _EXT won't work. For example (Tron again), I expect LEDBlinky is looking for decrement in DIAL and increment in DIAL_EXT. Will have to confirm that next time I mess with the thing. I think that LEDBlinky should consider if there is no DIAL_EXT in either ctrlr or cfg files, then it should look at both increment and decrement in DIAL. That would solve the whole issue and could be applied to all of the analog control types (e.g. pedals, paddles, ad stick, etc.)
djm468:
How to reproduce the None and _Ext issues:
Here are the port mappings for my "admin" buttons (plus two flippers):
<port number="31" label="VOLUME_DOWN" type="R" inputCodes="NONE"/>
<port number="32" label="VOLUME_DOWN" type="G" inputCodes="NONE"/>
<port number="33" label="VOLUME_DOWN" type="B" inputCodes="NONE"/>
<port number="34" label="EXIT" type="R" inputCodes="KEYCODE_ESC"/>
<port number="35" label="EXIT" type="G" inputCodes="KEYCODE_ESC"/>
<port number="36" label="EXIT" type="B" inputCodes="KEYCODE_ESC"/>
<port number="37" label="VOLUME_UP" type="R" inputCodes="NONE"/>
<port number="38" label="VOLUME_UP" type="G" inputCodes="NONE"/>
<port number="39" label="VOLUME_UP" type="B" inputCodes="NONE"/>
<port number="40" label="SHUT_DOWN" type="R" inputCodes="NONE"/>
<port number="41" label="SHUT_DOWN" type="G" inputCodes="NONE"/>
<port number="42" label="SHUT_DOWN" type="B" inputCodes="NONE"/>
<port number="43" label="FLIPPER_1" type="R" inputCodes="NONE"/>
<port number="44" label="FLIPPER_1" type="G" inputCodes="NONE"/>
<port number="45" label="FLIPPER_1" type="B" inputCodes="NONE"/>
<port number="46" label="FLIPPER_2" type="R" inputCodes="NONE"/>
<port number="47" label="FLIPPER_2" type="G" inputCodes="NONE"/>
<port number="48" label="FLIPPER_2" type="B" inputCodes="NONE"/>
Other than Exit Game (esc), these buttons are only expected to light up during animations (and that's generally the case), as the buttons use mouse clicks, volume and power control. I wouldn't mind making them light up all the time, but apparently that requires customizing the animations. NBD and beside the point.
So, if you use None in your ctrlr or cfg files to un-assign MAME defaults (e.g. left and right arrows for dial inc/dec), LEDBlinky strangely "matches" that None to the NONEs above and all of those buttons blink and announce themselves for whatever you were trying to un-assign. That should be an easy fix.
In my case, again using Tron as an example, the announcement for these "ghost" controls is "Aim Left".
From the same file:
<port number="4" label="P1JOYSTICK" type="R" inputCodes="DOUBLEJOY4WAY|DOUBLEJOY8WAY|DOUBLEJOY2WAY|VDOUBLEJOY2WAY|KEYCODE_UP|KEYCODE_RIGHT|KEYCODE_LEFT|KEYCODE_DOWN"/>
<port number="5" label="P1JOYSTICK" type="G" inputCodes="DOUBLEJOY2WAY|VDOUBLEJOY2WAY|DOUBLEJOY4WAY|DOUBLEJOY8WAY|KEYCODE_DOWN|KEYCODE_UP|KEYCODE_RIGHT|KEYCODE_LEFT"/>
<port number="6" label="P1JOYSTICK" type="B" inputCodes="DOUBLEJOY2WAY|VDOUBLEJOY2WAY|DOUBLEJOY4WAY|DOUBLEJOY8WAY|KEYCODE_UP|KEYCODE_DOWN|KEYCODE_LEFT|KEYCODE_RIGHT"/>
Now, if there is no DIAL_EXT defined in the ctrlr or cfg files AND there is a lighted control on the CP that uses KEYCODE_RIGHT, it will blink and announce as "Aim Right". You can imagine the confusion of these two together (5 buttons for Aim Left that have nothing to do with the spinner and, for example, the player 1 joystick claiming to be Aim Right).
As noted previously, there are workarounds for both of these. I imagine the None issue is universal, but don't yet know if the _EXT issue affects paddles, pedals, AD sticks, etc. Will check those next...
As for dials, at least for my setup, I don't see any harm in just removing every DIAL and DIAL_EXT entry from controls.ini. Those would only be needed if using a light up spinner or allowing inc/dec (digital to analog) on the CP (e.g. buttons to do what the spinner handles much better).
And for the None issue, the best workaround I can figure is to remove the NONEs from LEDBlinkyInputMap.xml, replacing them with unused keys (as I had previously done throughout my ctrlr and cfg files). That should stop the incorrect matching of None and NONE.
Ideally, these issues can be addressed in a future release, as the behavior is very confusing and somewhat difficult to diagnose. Have to figure that at least some aspiring users have downloaded and tried this thing over the years, only to give up and not buy it. :(
Still wondering if the per-game ctrlr definitions will be parsed. If not, that's a much bigger bug than the other two, with dizzying possibilities for incorrect control highlighting and announcements. Will know by the weekend anyway...
EDIT: I figured out that the flippers can be assigned mouse buttons 1 and 2; will have to see if "MOUSE1" works for me, as I don't use multimouse in MAME. For example:
<port type="P1_BUTTON1">
<newseq type="standard">
KEYCODE_LCONTROL OR JOYCODE_1_BUTTON1 OR JOYCODE_5_BUTTON2 OR MOUSECODE_BUTTON1 OR GUNCODE_1_BUTTON1
</newseq>
</port>
Am hopeful that LEDBlinky understands MOUSECODE_BUTTON1 means any mouse or that editing the LEDBlinkyInputMap.xml file to change it to use the generic MOUSECODE_ prefix will work. Hard to say what the UI will show after such an edit, but I'm about done with the UI anyway. :)
As for the others, the solution is to remove NONE from the inputs in the UI (or the file), which the UI then shows as "none". Yes, NONE and none have very different meanings, with the latter outputting "" for inputs in the XML and the former "NONE", which is then apparently matched up with MAME's None. Very confusing. :(
Haven't tested yet, but presumably that fixes the NONE problem. I'd recommend taking NONE out of the list of port inputs, as it won't lead to useful results in any case I can think of.
Also, missing pedal 3 in that list, not that it should matter to anyone (who has LED pedals?) Only games I know of that use that control are Hard Drivin' and Race Drivin', but there are likely a few others. The 2011 controls.ini file does not list any of them, which may explain why pedal 3 isn't in the list.
djm468:
On an unrelated note, before I even attempt to edit any of the LEDBlinky configuration files, I saw a post that mentioned a "tip found on the Web" or some such that implied that LEDBlinky cannot parse UTF-8 encoded files, which is the default encoding used by most Windows-based text editors (e.g. Notepad). I expect this only comes up when using Save As, else an editor should respect the original encoding.
Is it the case where ANSI encoding is required for these files?
Also unrelated, the "Audio" tab on the config app always alerts that I have no "audio devices" or some such. I believe this tab is for configuring audio input processing for animations that try to mimic sound. It's been a long time since I messed with audio inputs on a PC, other than microphones. Presumably the PC in question will work with a microphone (like any PC), but I haven't tried that yet.