I would indeed love to try it on my TS11! 
just so happens to be my one and only light with Aux, and in turn the only one on the list lol.
If I can work up enough guts to flash it… I’m still scared to death of bricking a flashlight lol.
Other stupid question; this applies to the Aux in lockout mode too, not just while on?
Yes, iirc it also works
In general, if a program logic change works, there isn’t much need to test it on multiple models unless it’s a case of significantly different hardware and code that might affect it (e.g. dual channel), but if it’s just things like new events that toggle variables, if it builds and works on one light it should work on any.
That’s right, there’s specific, separate code to support both lockout and “on” (actually, “off”) modes, and I’ve tested both.
I just made a zip file for all the hexes that build for rev.721 plus this mod (which I’m calling 8C_Quick_Aux_Switch), and anyone interested can download it here: https://durval.com/xfer-only/anduril.ALL_HEXES_THAT_BUILD_-_multi-channel_branch_rev_721+8C_quick_aux_switch_20230616.zip
Test reports welcome! 
You are right OFC, “code coverage” testing etc – but then where’s the fun in that? 
It can happen, but short of physical/electrical damage, (due to static electricity, bad flashing adapter, shorting of pins, etc) it’s not very probable AFAICS at least with the attiny1616 with UPDI as the flashing is really quick and only touches the devices’s flash memory (not fuses, lockbits, etc) and at worst (flashing process gets interrupted in the middle, bad hex, etc) you can always reflash to fix it.
Good advice is to always make a backup of your current, known-good-and-working firmware before flashing anything on top of it, so you can go back to it in case of any issues with new firmware or if you simply don’t like it.
OFC no guarantees, your mileage may vary, your warranty will be void, caveat emptor, etc 
The TS10 clips (both the original and the improved ones) have a hole where you can thread a lanyard – none of my lights currently carry a lanyard, but if I needed one on the TS10 that’s where it’s supposed to be installed.
Yep, I can see your point as I also had some difficulty handling the TS10 small size at first. But then I learned about and started practicizing the cigar grip and all has been well ITR.
Again I can see your point specially that there’s no fix or workaround for the tail switch (which is not a problem for me, but I can see it’s for you). Perhaps you should consider the FC13, I have one and it suffers from none of these negatives, and costs just about $10 more than the TS10 (but then no triple LEDs and no auxes on the optics – just on the switch, and it takes 18650s not 14500s).
UPDATE: just made a new version with a small fix for a problem I found yesterday (see my next post) when building for the Noctigon KR4 (thanks again @YBF650 for volunteering to test it), please see next post for an explanation; I’m calling it version 20230616, and here’s the source code (as always, a diff patch to TK’s original rev 721): 721-8C_quick_aux_switch_-_20230616.diff · GitHub
NB: this does not affect any light for which version 20230615 already built, so if you have a light with 20230615 on it, there’s no need to upgrade/retest with this new version.
UPDATE: As hinted in my previous post, that did not work for lights with some other MCUs (eg the T1634) for which Microchip for some reason (why, Microchip, why?! ) skipped defining EEPROM_SIZE in their avr-gcc include files. The fix to get my mod to build for these lights is simply to only compile this when EEPROM_SIZE is defined, so its respective code segment becomes:
// auto-detect how many eeprom bytes
#define EEPROM_BYTES sizeof(Config)
+#ifdef EEPROM_SIZE // avr-gcc doesn't define EEPROM_SIZE for some MCUs (eg 1634) so we can only check this when it's defined
+ // Abort compilation if eeprom size exceeded
+ // Good explanation on how this works: https://scaryreasoner.wordpress.com/2009/02/28/checking-sizeof-at-compile-time/
+ #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
+ __attribute__((unused)) static void build_bug_on() { // this is never called and doesn't generate any code, serves only to expand the macro
+ BUILD_BUG_ON(EEPROM_BYTES > EEPROM_SIZE); // EEPROM_SIZE comes from avr-gcc and so should adjust automatically for each MCU
+ }
+#endif
+
This is the only change from version 20230615 to version 20230616 of my mod.
Thank you so much for your work Durval. I’ll give you a feedback asap
Thank you!
I am waiting for a TS25 and the programmer.
I look forward to using and testing your version!
Yes, to get the custom build that @wolfgirl42 made for me to run, in my preferred form factor light, my only real option is the FC13. (I prefer 18650 or even better 18350 sized lights, even as short as 14500 sized lights, the fatter 18x form is a much better grip).
Unfortunately its basically identical to the light I have fallen in love with-- so much so I just replaced it with an exact copy-- over the last 10 months; Sofirn SC31 Pro.(heck, as far as I can tell they even come out of the same factory!).
I just can’t bring myself to get one…
Identical enough yes, that I could use it and be verry happy. But its not the same… Its a functional difference yes, for the different software, but theres nothing really wrong with the SC31. I really like my purple Sofirn!
Its actually ironic, One reason I got the lights I did, SC31Pro and SP10Pro, was for Anduril2, and ease of flashing them when I could get to learning the programming. I was actually unaware of Wurkkos at the time, or enough so to not consider them, I’d heard much more about Sofirn.
I just happened to get used to, and want to continue using a light that the new branch doesn’t support, so no one else is compiling for them. Lol.
I am learning the software/programming language, slowly, (and thankfully this code is well commented inside!), but its a while till I can really try to move the mods I see posted that I like to the other lights code, and try to compile it. Slow learner… lol.
As to quads and aux… if the TS25 was a 18650 form, just a bit slimmer, say FC13 sized, I’d jump on it… Even if I cant have it in Purple lol. I don’t pocket carry, I dangle them from a belt loop, but even then there are comfortable size limits, and I think the TS25 exceeds it. The TS11 does in general, Its just HUGE in head dia, but on a slim 18350 tube, its doable. But its a thrower that I dont get any use from in a daily light, so its a null point.
Yes I know I’m picky lol.
Nice work Durval, perfect! 7C and you find low and if you memorised high you’ll find always with 8C! Now I am ready to test a D4V2.
Glad to hear it works for you too! I’m actually running that same firmware in all my Anduril lights (all 2 of them, LOL) and I do love the 8C/7C thing!
Full steam ahead! Which ‘persuasion’ of the D4V2 is yours, if you don’t mind me asking?
2 flashlight for start is not bad😌
I hope ToyKeeper find a solution for this little issue in aux mode.
If I understand correctly because it has 7
Colors and I am curious to test with 8C and a memory
Well, considering it’s 2 of a total of 4 flashlights since I joined r/flashlight almost exactly 1 year ago, I fear I’m just a wimpy compared to the real aficionados like most of the people here that order dozens of flashlights per month
Sorry for not being clearer, what I actually meant is, which of the supported d2v4 hardware versions/variations is yours (ie emisar-d4v2-219 or emisar-d4v2)? This is important because there’s a couple of versions which actually aren’t building yet, not due to my mod but due to TK’s multichannel branch still being in development.
Sorry it’s my mistake.
My version is 219 without FET so the original firmware is KR4 without FET