Went out to the city and spent ten hours at the lathe. Was taking my time, but being efficient; cut fourteen new primers so I'd have a small stock of them, fitted the guts in two bodies, and then went and cut two more full-function grenades from scratch. Even with the loss of efficiency in doing them serially instead of in parallel, took less than two and a half hours each.
And still had a spring in my step when I returned (with a heavy backpack filled with aluminium stock, metal working tools, laptop, and a thermos full of coffee.)
Somewhere in there I roughed out possible layouts for the Duck Light. That thing is still bugging me. For me, the platform works, because I can program and I have the ISP to access a minimal AVR. Well -- there's a potential solution via the XBee node, to include in the serial command set to the Duck Light commands that will re-write constants held in flash.
Still, the very flexibility of the thing is my boon but the downfall in making it really useful to non-programmers. I'm building a tool that allows me to create a lighting look for each specific project as it comes up. I can really only think of one option that I can hard-program so it is a mere button-press or the quick soldering of a jumper away for the end-user who doesn't program, and that's making a lantern (and even then; the power of the complete platform is I can tweak the color, the depth and rate of the flicker, the length of the fade, even the brightness.)
Sigh. Even if I make up a remote programmer wrapped in a GUI that is friendly to the end-user, it wouldn't handle the hardware end. Even something as simple as adding a capacitance sensor, or a microphone input hard-coded to a DalekEye circuit, means jumpers, or dip switches, and of course adds to the number of components on the board.
(For that matter; I really need to allow space for an accelerometer/accelerometer breakout in the footprint. Which, like the XBee, is an expensive part so it doesn't want to be hard-soldered as part of the basic package.)