Main > Software Forum

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

<< < (376/381) > >>

Ginsonic:

--- Quote from: djm468 on June 12, 2022, 06:29:31 pm ---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.

--- End quote ---

According to http://mirrors.arcadecontrols.com/easyemu/mameguidenew/mameguide-controlini.htm  _EXT means a reverse movement of a controller.

djm468:

--- Quote from: Ginsonic on June 13, 2022, 01:33:10 am ---
--- Quote from: djm468 on June 12, 2022, 06:29:31 pm ---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.

--- End quote ---

According to http://mirrors.arcadecontrols.com/easyemu/mameguidenew/mameguide-controlini.htm  _EXT means a reverse movement of a controller.

--- End quote ---

Aha. So presumably this applies only to the fallback inc/dec for dials, paddles, pedals, etc., as the analog mapping is by axis, which covers two directions. And IIRC, for example, in the controls file, Tron uses DIAL to define "Aim Left" and DIAL_EXT for "Aim Right".

Surely, in a perfect world, LEDBlinky would be able to look at this alone (from ctrlr 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>

...and figure out that both Aim Right and Aim Left are keys that are not assigned to any LEDs. But it apparently does not do that, instead requiring the addition of:

<port type="P1_DIAL_EXT">
                <newseq type="standard">
                    MOUSECODE_XAXIS OR JOYCODE_1_XAXIS
                </newseq>
      <newseq type="increment">
                    KEYCODE_7PAD
                </newseq>
                <newseq type="decrement">
                    KEYCODE_9PAD
                </newseq>
            </port>

...and that has no effect on MAME that I'm aware of. It's just redundant, but apparently required to prevent LEDBlinky from highlighting these "ghost" controls.

And, as mentioned, through no fault of LEDBlinky, putting the dial inc/dec stuff in the ctrlr file is not enough (at least not with MAME .219) for "problematic" games (e.g. those with joystick + dial). I believe LEDBlinky will respect ctrlr rules for those, but MAME surely doesn't, with the game "drivers" (or whatever the internal per game configuration is called) doing whatever they want, unless overridden in game-specific cfg files (which really sucks).

Thanks!

djm468:
I'd say that's a wrap on my LEDBlinky experience. Everything seems to be working as expected with it. Was initially no picnic and took more than a few hours, but not bad considering the results.

Before taking the plunge on this thing, I had seen various vague complaints about it "lighting the wrong buttons for some games" and such and that it was "a pain" to set up. I'd say it's more difficult than it could have been, due to an awkward UI and too many apps to keep track of. And I wasn't enamored with the little icons on the taskbar at first either. They all look like colorful dots and shapes and meant nothing to me until I memorized their functions.

Best advice is the same as with any of these things. Study the INI or XML or whatever the often-awkward UIs spit out. Eventually you can stop using the UI and just copy and paste stuff around (or automate the generation with scripts). Definitely RTFM as well, as this has a decent one. Once over the hump with this thing, I've found it to be very predictable and the settings files look like a much easier way to program it, avoiding a lot of repetitive dialog manipulation.

HyperSpin integration seems to work perfectly and was just a couple of lines in an INI file (presumably HyperHQ or whatever has controls for this as well). MAME works great with it, apparently with or without a front end. And it looks like it is pretty easy to set up other emulators and their games.

As for MAME, I recommend using a ctrlr file and don't forget to tell LEDBlinky where it is. Not sure why it doesn't get that from the MAME INI. And make sure you cover everything in it. Don't leave anything open to defaults and do NOT use None, at least not for analog inc/dec sequences (use a key that is not assigned to anything on the CP instead). And, as mentioned, perhaps depending on the MAME version, some games require redundant entries in their cfg files for inc/dec as well. What is it with inc/dec? :)

Goes without saying it was well worth the $26 (US) and Arzoo was very responsive to questions by email (after all these years!) Thanks!

If I have one question left, which I haven't looked into, it's why there seems to be no fading going on with the animations, blinking, etc.? Am using the Ultimarc RGB buttons, trackball, etc. and the demo script in their app does some nice fading effects that I'd like to replicate in LEDBlinky if possible...

arzoo:

--- Quote from: djm468 on June 13, 2022, 03:22:47 am ---If I have one question left, which I haven't looked into, it's why there seems to be no fading going on with the animations, blinking, etc.? Am using the Ultimarc RGB buttons, trackball, etc. and the demo script in their app does some nice fading effects that I'd like to replicate in LEDBlinky if possible...

--- End quote ---

Using the Animation Editor you can create fade and color transition effects.

I'd also like to mention that for mame, LEDBlinky uses a number of files (controls.ini, mame.xml, <rom>.cfg, ctrlr, etc) to determine which controls to light up and is only as accurate as the data in these files and the user configured input map. That being said, using the mame .cfg files (rather than hard-coding a ctrlr file) is the preferred method for using LEDBlinky. The .cfg files are updated by mame whenever a game's controls are modified (via mame's in-game menu) and this allows LEDBlinky to light the correct controls for each game. But glad you got it working with the ctrlr file!

djm468:

--- Quote from: arzoo on June 13, 2022, 08:55:36 am ---
--- Quote from: djm468 on June 13, 2022, 03:22:47 am ---If I have one question left, which I haven't looked into, it's why there seems to be no fading going on with the animations, blinking, etc.? Am using the Ultimarc RGB buttons, trackball, etc. and the demo script in their app does some nice fading effects that I'd like to replicate in LEDBlinky if possible...

--- End quote ---

Using the Animation Editor you can create fade and color transition effects.

I'd also like to mention that for mame, LEDBlinky uses a number of files (controls.ini, mame.xml, <rom>.cfg, ctrlr, etc) to determine which controls to light up and is only as accurate as the data in these files and the user configured input map. That being said, using the mame .cfg files (rather than hard-coding a ctrlr file) is the preferred method for using LEDBlinky. The .cfg files are updated by mame whenever a game's controls are modified (via mame's in-game menu) and this allows LEDBlinky to light the correct controls for each game. But glad you got it working with the ctrlr file!

--- End quote ---

Animation editor is the next thing to try out. Glad to hear it has fading.

Yes, certainly LEDBlinky is GIGO, but I would differ on CFGs being preferred for anything. Those were always a disaster to edit, as MAME will rewrite them under some circumstances (e.g. starting up a game with the joystick unplugged will lose all joystick settings). Seems like an odd choice by MAME, but they apparently meant to do that.

I think they should just ignore (and perhaps *warn* about) mappings that don't make sense for the current environment, rather than wiping them out. I mean, if I plug the joystick (or gamepad or whatever) back in, things should go back to normal, rather than making me go back and set up the CFG again.

Also, they are not stable, due to Windows device enumeration. AIUI, that was the main reason for the invention of the ctrlr file.

I'd say you should modify game controls in the in-game menu as a last resort, typically to see what it generates and then copy that stuff to the ctrlr file. That file has a "default" section, which can be optionally followed by per-game sections. Here is a per-game excerpt from my ctrlr file:

<!-- Console has only one AD stick and no pedals, so barring gamepad use we need buttons to inc/dec the AD Stick Z axis (pedal in this game) -->

    <system name="propcycl">
       <input>
       <port type="P1_AD_STICK_Z">
                <newseq type="increment">
                    KEYCODE_LCONTROL
                </newseq>
                <newseq type="decrement">
                    KEYCODE_H
                </newseq>
            </port>
   </input>
    </system>

I haven't played around with this thing enough to say for sure, but LEDBlinky should certainly handle the above from the ctrlr file. If not, I'd have to generate redundant CFG files for every "system" (game) in the ctrlr file, which would be bad. Please let me know, as I probably won't get back to this thing until the weekend.

Thanks!

EDIT:
Aha, found the little icon to edit these posts. Wanted to add that the ctrlr "systems" may be per-game or they can cover multiple games. For example:

<system name="sf.c">
   <input>

What follows are sequences for all Street Fighter games. I wouldn't be too disappointed if LEDBlinky fails to decipher those, but it should definitely handle per game settings in the ctrlr file.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version