Wow - where to start with this post?
First, let me make sure I understand what you're trying to do - you have LEDs (angle eyes?) mounted around your spinners and also illuminated joysticks. And when you play a single player game you only want the P1 joystick (or spinner) to light up - correct? When a 2-player game is running you want both P1 and P2 joysticks (or spinners) to light up - correct?
I'll start by saying that the concept of a "primary control" as defined by LEDBlinky is any control that's not a button. In my original design, I added a set of generic primary control input codes (JOY8WAY, JOY4WAY, TRACKBALL, DIAL, etc.) as a way to
speak the controls that are not normally illuminated. So for example, LEDBlinky will speak "Primary Control... 8-Way Joystick", telling the user what to expect for the current game. Since these were non-illuminated controls, there was no need to distinguish between player 1 and player 2 primary controls. Later I added the feature to also light the primary controls using the generic input codes. That's a brief history of the code evolution.
So there's two ways that LEDBlinky can illuminate the primary controls; you can use the mame input codes (JOYCODE_1_UP, JOYCODE_1_DOWN, JOYCODE_1_ANALOG_X, MOUSECODE_1_ANALOG_X, P1_DIAL, etc.) OR you can use the generic primary control input codes (JOY8WAY, JOY4WAY, TRACKBALL, DIAL, etc.). Each method may have advantages or disadvantages depending on what you are trying to achieve.
Using the generic primary control input codes is the easiest, but has the disadvantage that it does not distinguish between P1, P2, P3, and P4 controls. This is commonly used with the Trackball as most control panels only have a single illuminated trackball. But if your cp has 4 illuminated joysticks for example, and you play a single player game, all 4 sticks will light up.
The second method uses the mame primary control input codes. These give you the ability to identify each set of player controls, and also identify each individual control axis/action. The higher resolution works great for lighting the controls, but can be a problem when speaking the control actions. If you are not using the LEDBlinky feature to speak the control actions, then you may only need to assign one of the mame input codes. For example, with your spinners, you could just assign P1_DIAL to the P1 spinner and P2_DIAL to the P2 spinner. Then any game that is defined as using P1_DIAL or P2_DIAL in controls.ini or mame.xml will illuminate correctly. For your joysticks, you could just use JOYCODE_1_UP and JOYCODE_2_UP since any game that uses the joystick will most likely use the "UP" axis. BUT, as I said above, the problem arises with speaking the control actions. With my joystick example, LEDBlinky would most likely speak "UP" while blinking the joystick. The only way around this would be to edit the controls.ini file and edit all the actions for the primary controls. For example, you could do a replace on "P1_JOYSTICK_UP=Up" and change it to "P1_JOYSTICK_UP=" (effectively lighting the joystick but preventing LEDBlinky from speaking any action).
In a future release I may have to reevaluate how this works, but for now, these are your options.
Also, here's a bit of clarification; LEDBlinky uses the controls.ini file to determine the Controls and Control Actions used by each mame game. If a game does not exist in controls.ini, then mame.xml will be used. You can override both these files using the LEDBlinky Controls Editor. When a mame game is loaded, LEDBlinky identifies the Input Codes for each control using these files in this order; <rom>.cfg --> default.cfg --> mame's default input codes. It's a bit more complicated than that but that's the basic logic.
Hope this helps.
By the way, you asked about getting the latest controls.ini data - check
here.
Home
Help
Search
Login
Register
Send this topic
Print
Topic: LEDBlinky and control.ini question. (Read 10591 times)
