@armi0024 Thanks!! Would you belive I never owned a fightstick and this is my first one ever!! I remember playing in arcades and having a blast when I found SRK it blew my mind so I just leaped into the community. Thanks for making the Kaimana as this is going to be so much fun to make enhancements, I need to brush up on arduino, C, and c++ coding as it has been a long time.
I dont have one in hand yet (no shipping since the 19th yet) but it looks like the constants should be reused instead of idexes changedā¦ or am i wrong?
so instead of
{iLED[LED_K2] = true;}
else
{LEDCOLOR[0][2]=random(255);
LEDCOLOR[1][2]=random(255);
LEDCOLOR[2][2]=random(255);
iLED[LED_K2] = true;}
you would resue the constant as the second array index
{iLED[LED_K2] = true;}
else
{LEDCOLOR[0][LED_K2]=random(255);
LEDCOLOR[1][LED_K2]=random(255);
LEDCOLOR[2][LED_K2]=random(255);
iLED[LED_K2] = true;}
seems like that would work regardless of button config as long as you have your constants defined correctly. Cant test it though.
@YellowCan - Working on extending the Ryu code now. Lots of great ideas I just need to put into code.
@wahoo747 - Yup, those constants you changed look correct at first glance. Iāve fixed all of that in my copy of the code (see below) which should help everyone later.
@jwyder - Thatās a really sweet looking wiring job on that panel of yours. My wiring is quite the mess at the moment so I wonāt be posting pics anytime soon. I also updated the pollSwitches() function so we should chat. If you have time to tinker with code over the weekend, send me a PM.
So, I forked the basic Kaimana code @armi0024 posted the other day and spent some quality time reorganizing it and adding a ton of stuff to make it easier to work with. I converted the demo to a C++ class library and wrote new functions to make it easier to detect combos, button patterns and other fun stuff.
The beta source had a lot of early legacy code that had been commented out and was a mix of code contributions from several individuals in there so I cut all of the extra stuff. I am now working on consistent variable naming and source formatting. Everything compiles and runs but Iām not quite done with it just yet. I think I need another day or two and a second set of eyes to double check my work.
Hereās a teaser of the new test for combination code:
(function names subject to change)
// combo #1
// test for: Ryu Hadouken (Fireball)
// combo is: DOWN, DOWN+RIGHT, RIGHT, RIGHT+P1 or RIGHT+P2
if( kaimana.historyTest( ATTACK_RIGHT + ATTACK_P1, ATTACK_RIGHT, ATTACK_DOWN + ATTACK_RIGHT, ATTACK_DOWN ) )
Animation_Combo_1();
So many cool ideas an so little timeā¦
I just looked at my copy of the source code and noticed I had replaced that random color generator with a function using the colors from the joystick . Question is, should this random color function be part of the Kaimana C++ base class or something completely optional and in the main Arduino code file?
Is this the appropriate place to be discussing code?
// definitions of RGB values use by random color generator
//
#define COLOR_RANDOM_1 127,220,000 // lime green
#define COLOR_RANDOM_2 127,000,220 // purple
#define COLOR_RANDOM_3 000,220,220 // blue
#define COLOR_RANDOM_4 000,255,127 // cyan
#define COLOR_RANDOM_5 000,127,255 // cobalt blue
#define COLOR_RANDOM_6 255,000,000 // red
#define COLOR_RANDOM_7 220,127,000 // orange
#define COLOR_RANDOM_8 220,000,127 // magenta
// set LED to one of 8 predefined colors selected at random
//
void setLEDRandomColor(int index)
{
switch(random(1,8)) // pick a random color between 1 and 8
{
case 1:
setLED(index, COLOR_RANDOM_1);
break;
case 2:
setLED(index, COLOR_RANDOM_2);
break;
case 3:
setLED(index, COLOR_RANDOM_3);
break;
case 4:
setLED(index, COLOR_RANDOM_4);
break;
case 5:
setLED(index, COLOR_RANDOM_5);
break;
case 6:
setLED(index, COLOR_RANDOM_6);
break;
case 7:
setLED(index, COLOR_RANDOM_7);
break;
case 8:
setLED(index, COLOR_RANDOM_8);
break;
default: // any undefined value so discard data and set led to BLACK
setLED(index, BLACK);
break;
}
}
Note: Updated with latest code version
wahoo747 - what is your name so I can check that order for youā¦I had two orders stuck on Paypal on the 19th that did go outā¦
stezo - same hereā¦name please 
If anyone has issues with your order not registering on the websiteā¦please email me or call me susan@paradisearcadeshop.com or 651-332-3665
@ZonbiPanda I would assume that the rainbow effect would not belong in the base code file. If it isnt dealing directly with hardware (button on/off, light on/off) or a library function like the historyTest, Iād put it with the optional/customizable code. I imagine it will be stripped out by most people for space anyway. If you dont specifically want a ārainbow modeā and have precious little memory squeeze your game patterns, combos, and menus into, i imagine that the rainbow thing will be the first to go for size concerns. Better to put it in the file that you want people messing around in, would be my guess.
And you are right, this probably isnt the place to have this discussion.
@SusanInParadise Iāll send an email right away, thanks!
Yes codersā¦ work your magicā¦ 
So hereās what I have for the logical grouping of the Kaimana Arduino project files. I have emailed @armi0024 my latest code changes to see about having it published.
Main Arduino project file (.ino)
Kaimana header and cpp class file - Kaiman base class code typically not modified
Kaimana custom header file - modify constant definitions here to match physical hardware installation
Animation header and code file - edit to modify or replace various custom animations
http://support.paradisearcadeshop.com/lib/exe/fetch.php?media=kaimana-cpp-class-map.png
Thanks @armi0024!
So, good newsā¦
@jwyder sent me an update that he was able to try the new Kaimana class library code. It worked on his panel with just a change to the #define LED_* values in the header file to match the order he has his LEDs connected. I have 12 LEDs on my panel and he is running with 8 LEDs so the order in which the LEDs are chained together was modified as discussed previously.
I have more coding I want to do and waiting on additional feedback but the Kaimana library is looking very promising so far.
going to make a video today with one of my Foe Hammer cases showing the full installā¦
@Zonbipanda that code is AWESOME!! Nice job, the Kaimana is a great product and is very open to what anyone can imagine!!
The kaimana_custom.h is a great idea as it will make it easy for users to just change their LED index
@armi0024 Thanks for getting this going!! There are definitely new ideas flowing!!!
Just placed an order for two Seimitsu joysticks and some minor parts (shaft covers, balltop) todayā¦
Question though, armi ā
Are you ever going to carry the LS-56 spring by itself?
I canāt find them in any US store right now and I would like to re-equip an LS-58 with one of theseā¦ the default LS-58 spring is too soft!
Oh, and after some internal wrangling, I did get a butteroj balltop!
I seem to be stingier when I actually do have payday moneyā¦
@jwyder thank you, very fun project
@Georgec, excellent! We do have LS-56 mod springs here: bottom of the page
Also, check out the new youtube video!!!
Awesome! I was thinking about animations for the Kaimana and I had an idea. Juri can store a Fuhajin (up to 3 actually) and I was wondering if you could make an animation that would pulse outward from a button that you were holding down in a slow rhythm. This would be really cool for Zero players too. While charging the buster the leds could pulse inward to the button you were holding just like the animation on screen. Also, would there be any way of making the Kaimana aware of how much health a life bar had? That way when you were low on life the buttons could flash or turn red or something or is this beyond the capabilities of the Kaimana/current games or peripherals?
Here is a short video showing inside my case. The wiring is bad but I just wanted to test if I could wire it up properly. The bottom panel when on without a problem so I am just going to keep it for now. I have two longer kaimana harness on the way to help space out the adapter boards. Also I can break apart the boards right but I may just keep them connected.
@iNendoi just cut your restrictor plate, sorry for the delay
The LED programming can be done as you stated. The health detection could be tough. Are there any controllers that detect that?
@Yellowcan that wiring looks better than 90% of the arcade cabinets I open up
@Armi0024 - No worries on the delay. I have no idea about the controller thing. The Fighting Edge uses the vibration signal to detect hits and light up but I donāt think any can detect things like that. Maybe if a game sent a vibration signal when your life was lowā¦I dont think any fighting games have that feature. It would be really cool if your controller could detect things like X-Factor activation, etc.
This is doable. I have been considering it for Zero. The hard part about getting this done is that you would want the rest of your LEDs to function normally during the hold/store animation. That means your history logic needs to be able differentiate between a hold and a press and filter out the held buttons and treat them as 2 different states (unless you want to repeat your LED code many times over for the different āHold buttonā states) and light appropriately. I imagine this will be a few days coming before someone posts a good example as none of the samples I have seen so far touch on this.
I dont see how this would be possible. I was considering options for palette swapping when you change change toons (yellow buttons for nova, bring in doom they switch to green, etc) and there just isnt a way to know when you have been snapped in or killed. That data would have to be sent to the stick and as far as i know it isnt. Maybe in the future if there is a readout on the gamepad that shows HP or current toon we could intercept that data and use it ourselves. But Capcom is going to have to make a game that actually talks to joysticks first i think.
Yes, the only ācommunicationā that the console has with the controller is the signal to activate the rumble - in fact, the rumble signal is what makes the Fighting Edgeās LEDās turn red. To actually have that in the LED controller, it would a) have to be receiving input signal from the controller, and b) be able to detect and respond to the rumble signal, and c) the game itself would be the one sending the signal, so it would have to be sending the signal when you want it to begin with.