Nice! I'm so glad some other smart people realized how to accomplish the off-time by only adding one tiny component :)
It is so simple and obvious, once I read the code! 
I never would have thought of it on my own. I was thinking R-C circuits to keep the controller running long enough to determine short press or not. 
I like your version very much and I use it now, but is there any way I can turn ON the light with a single short click?
Now when the light is off I can only use long press for entering directly to high, or double click to enter in low… but the single short click does noting.
For me the perfect version would be short click for turning ON/OFF and long click for next mode, with memory and strobe… but I can’t make it 
Weird - one short click should go to the lowest mode. What's the value you are using for the lowest? If you are using 7135's, the lowest mode should be a value of 5, not 1. With a FET, you should be able to use a pwm value of 1. Actually my last BLF17DD build I used 1 as moonlight, and 1 is really, really low - the LED basically barely glows...
Quick single clicks should go to the next, and next mode upward (brighter).
That was the problem, I was using value 1 for 7135. Now it starts with a single short click.
Thanks!
I’ve changed it to 0,92,4,15,125,255 so it will start with 92, the mode I am using most. Now it is perfect
interesting…never thought of that…a med/hi as 1st mode, then back thru to moon on up…
One more beginner question
How can I get rid of the noise, especial in medium mode?
My default setup is 9.4 kHz - "Fast PWM" at 18-19 kHz should be noise free, but I never tried it - everyone else is using it though, seems like. If you have a solid ground for the driver, nothing else you can do I would think, accept to try Fast PWM. With Fast PWM, you probably need to raise the moonlight PWM 5 value even higher, maybe 8 or 9? Not sure...
Ohh - by setting mode #1 to a medium level kind of breaks the auto battery level detection/savings, because the way JC wrote this, as the battery drains low, he auto drops down modes, so it's expecting modes to start low and go higher.
oh, I didn’t think of that…get a weak battery then drop to lowest of low mode
But it will still shut the light off at 2.80v, am I right?
P.S. Will fast-PWM (18 kHz) drain battery faster or it won’t be noticeable?
Yes, 2.8v cutoff should still work (accept in my last BLF17DD board build -- duuni wut is wrong... 
)
Don't think PWM rate will have any effect on power drawing, ie battery drain time.. Shouldn't, cant see how - I'm no expert though.
Yeah, sorry about that :-/
I can’t flash this one, I am getting this error at the end:
Did anybody tried to flash this STARSTROBE1.0.c
I’ve tried the .hex file that @WarHawk-AVG compilled for me but I get the same error. 
I want to know it anybody tried it and succeed?
Well the Tiny13A has 1K ROM/flash, and an address of 0x410 is 16 bytes past the address range. Maybe with certain combo of compile options, you went over the 1K limit?
0x400 (hex) is 1024 decimal (1 K)
I compile it like all other .hex files, following this instructions and all works nice except for that STARSTROBE1.0.c .
Now I tried to compile STAR On-time memory v1.1 and I flashed it without any problem :~
Here is a screenshot of STARSTROBE1.0.c error:
Hey smart people I’m having an issue I can’t get rid of- first I thought it was limited to my E12 with a tiny10 running a baby FET but I’m now getting it on my TC300 with a BLF17DD v2 running with a zener mod and MT-G2…
When the light is off (I’ve changed the default to no memory without soldering the star) it will come on in moonlight PWM =1, true “moonlight mode” (also set in the programming to default on without soldering star, not just low set to 1)and at initial start up it works fine but when cycling up threw the modes when it rolls around back to moonlight there is an extremely bright flash after turbo. Like I said at first I was thinking it had to do with the baby FET I have on the tiny10 but now it’s doing it on a 17dd that started with completely different code, not just a rewrite.
Other variables to mention are 1 WDT tick before mode is memorized, on-time and fast PWM.
priest77 - dunno, haven't dlnd'd and tried that source code. Did this come from JC or RMM? Maybe they know? Wonder if the Dev Studio versions are the same - what you use and they used, or something like optimization settings for the build. If you used same source with nothing edited, then could be the tools you are using are generating compiled code that's not as efficient or optimized as they did.
I use Atmel Studio 6.0, or newer.
@priest77
afaik different compiler might produce different hex file sizes while compiling the same source code.
0x0410 means your hex file is larger than 1024 byte which is max for Attiny13a, as Tom E wrote.
Atmel Studio shows the size in the bottom window (scrolling up a bit) after compiling, so you can see if it is too large before flashing.
You might try reducing the code slightly by removing unneeded features, as you are only slightly above 1kB.
You are both right. I’ve installed latest version Atmel Studio 6.2 and now it tells me this:
Now I am not sure what code part can be removed.
I want to remove the feature of “Star 3 = H-L if connected”