So, always on the bleeding edge of cabinet technologies, I have just started using LEDBlinky. I like it!
However, I have found a very odd bug, that seems to be exacerbated by a bug in MAME (.219) (or maybe it is an expected behavior, but can't imagine).
My first encounter with the issue was running Tron. The software got everything right, except for "Aim Left" and "Aim Right", which blinked the P1 joystick for one (don't remember which) and *every unassigned button* for the other. Tried some others with dials and got similar results.
So it turned out that I had set dial inc/dec to None in my ctrlr file. I switched that to unassigned keys that don't exist on the CP and... One of the bad results went away. So I dug into the controls.ini (or whatever it is called) and found that one of the "Aim" mappings was using something called "DIAL_EXT".
This also came as quite a surprise, as I have tested my setup with hundreds of odd games that use various analog controls and the suffix "EXT" has never come up. Google seems to know little about it as well. Is this a relic of some sort?
So added this to ctrlr:
<port type="P1_DIAL_EXT">
<newseq type="standard">
MOUSECODE_XAXIS OR JOYCODE_1_YAXIS
</newseq>
<newseq type="increment">
KEYCODE_7PAD
</newseq>
<newseq type="decrement">
KEYCODE_9PAD
</newseq>
</port>
...for only one reason: to stop this software from announcing/blinking a single incorrect "Aim" control (I don't use 7 or 9 on keypad for anything).
And that would have been the end of that, except for a bizarre bug in MAME (or at least I have to assume it is unintended behavior). Dials and pedals (and possibly paddles) inc/dec just don't take for
some games unless they are defined in the volatile game-specific cfg files; putting the same in the stable ctrlr file does absolutely nothing (whether game-specific or not).
I have a theory that these troublesome games (e.g. Caliber 50) do some remapping of their own internally and fail to account for
some inputs defined in the ctrlr file. For example, this Caliber 50 thing, barring a game-specific cfg, insists on using X and Z for P1 dial inc/dec. Why would that be?
Likely because the internal default for these is left/right and those are also the internal default for joystick left/right. This game has both a joystick and a dial (or a rotary joystick or whatever), so it changes dial inc/dec to X and Z for player 1. In doing so, it steps on the configured ctrlr inputs (which were initially None and then changed to unassigned keys). Have found that racing games with pedals run into the same issue and fail in the same way, again requiring use of volatile cfg files for inc/dec.
Posting this, as I found the combination of these two bugs maddening and could not find any documentation or forum posts that helped.
The LEDBlinky part of the solution appears to be to assign anything unused to unused keys (not None) and to make sure this DIAL_EXT thing is defined in the ctrlr file (possibly PADDLE_EXT too) and it may need to go in cfg files for some odd games.
On the MAME end, some games need cfg files for inc/dec, as MAME will ignore the same entries in ctrlr files. Anyone else notice this over the years?
And just what is this _EXT suffix anyway?! It can't exist just to affect LEDBlinky behavior, yet I've never needed it
at all in ctrlr or cfg files. Thanks in advance for any enlightenment in that area.