Main > Software Forum

LEDBlinky - Arcade LED Control software and Animation Editor - v8.2

<< < (375/378) > >>

PL1:

--- Quote from: Temp123 on May 18, 2022, 12:00:59 pm ---
--- Quote from: PL1 on May 18, 2022, 12:44:30 am ---The LED controller, are separate from the encoder,

--- End quote ---
Then why does this device make it seem like they aren't separate? This is where the confusion stems from...

https://www.ultimarc.com/control-interfaces/i-pacs/i-pac-ultimate-i-o/

--- End quote ---
In the case of that Ult. I/O board (and the LED-Wiz+GP), the encoder and LED controller are on one PCB and they share the USB connection, but the software configuration and wiring you need to do are the same as if they were on separate PCBs.

For the encoder part of the PCB, you still have to configure the front end, games, emulators, and maybe the encoder (you may not want to use some of the MAME default "modifier" keystrokes  ;) ) plus you have to wire the switches/spinner/trackball to the encoder part of the board as you would with a standalone encoder like an IPac2 or GP-Wiz40.

For the LED controller part of the PCB, you still have to configure the front end and LEDBlinky plus you have to wire the LEDs to the LED controller part of the board as you would with a standalone LED Controller like a PacLED64 or an LED-Wiz.

Like Arzoo suggested, you may want to start by getting the front end, games, and encoder part up and running before you work on the LEDs and LEDBlinky part.


Scott

SuperMagoAlex:
Hi, I'm using LEDBlinky with Maximus Arcade, is it possible to blink the leds to the rhythm of the Maximus ambience mp3?

arzoo:

--- Quote from: SuperMagoAlex on May 25, 2022, 05:53:34 pm ---Hi, I'm using LEDBlinky with Maximus Arcade, is it possible to blink the leds to the rhythm of the Maximus ambience mp3?

--- End quote ---
Yes, using an audio animation when the FE (Maximus Arcade) is active would most likely do what you want.

djm468:
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.

djm468:

--- Quote from: djm468 on June 12, 2022, 06:29:31 pm ---                    MOUSECODE_XAXIS OR JOYCODE_1_YAXIS

--- End quote ---

Typo: JOYCODE_1_XAXIS. But unrelated to the issues at hand.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version