Donât know if this is a documented feature but I havenât seen it in the diagrams and thought Iâd share: 3H in lockout will scan the tint ramp for momentary moonlight, super useful imo.
Nice catch! I donât think this was intended. The handling of 3H is global so that it is available everywhere. It can be overridden by other handlers (like 3H from off for blinky), but thereâs nothing for lockout yet.
Hi ToyKeeper,
I wanted to ask if it would be possible to make anduril 1 hex files for the DM11 an maybe for the D4SV2 with the new regulated cc drivers? I really prefer anduril 1and would like to know if its possible.
Thanks in advance.
I donât see a need for this. Anduril 2 can be configured to behave almost identically to Anduril 1. What specific Anduril 1 features are you looking to replicate? Perhaps we can walk you through how to set your light up to behave like that.
Hello TK I was wondering about the aux disco and color run-through it seems that the whitish color is left out I have the latest anduril 2 firmware in my D4S and KR4 is this normalâŚand thank you so much for your diligence and hard work creating this UI it is an absolute masterpiece
NG420
I have been using Anduril 1 for a while on my EDC18 and just got a D4v2 recently and flashed it with the latest Anduril 2.
Pros:
Hybrid memory is great UX
Simple UI. Two UIs for the price of one.
Setting a single configuration value at a time is much easier and less error prone
User configurable treatment of Turbo mode (A2 style for me)
Momentary Turbo
Hold for +10 in configurations is a great time/button saver
Auto lockout
Cons:
So many clicks! 4 clicks for a high traffic function like lockout seems excessive and the 7/10 click configs start to feel gratuitous
(Subjectively) inconsistent choice of clicks
10H vs 10C to change modes. Much harder to remember 2 inputs, and their direction, as opposed to a single toggling input. Getting it wrong can drop you into an unexpected menu
7H for ramp config but 10H to access the same settings for Simple UI
Memory mode config
First item is input a number to set a boolean
3 different settings sat behind two separate configs
First menu item flash is easy to miss in configs, especially if the light was already on
Suggestions:
Swap 7H from ON and 10H from ON to access Ramp config consistently
Use the same sequence for toggling Simple mode. e.g. 12H for both directions
Flash the config menu item number. e.g. F_P_FF_P_FFF (F = Flash, P = Pause). Would help me know what item Iâm on
Move Momentary mode to some higher number. I canât imagine people are dropping in and out of it regularly so seems a waste of a low (accessible) number
Use 6 & 8 click functions. I know it was a choice to spread things out but Iâm not sure the tradeoff is worth it. Iâm much more likely to get things wrong because 10H is overloaded than because I mis-clicked. Having more inputs means you can have more consistent behaviour which lowers cognitive load. It also means that you will get fewer collisions (e.g. Iâm trying to set the floor for the Simple UI ramp but I was in moonlight mode so now Iâm actually just disabling Manual memory mode)
I donât have a good suggestion for another way to configure memory mode, but I feel there might be one
Feature requests:
Blink out battery/temp etc on the aux lights rather than main emitter
Add battery voltage blinks as one of the aux light patterns
If I enter a menu item but donât set anything then blink the stored setting back. Gives me way to read the setting, not just write
Shortcut to moonlight (from off) enters lockout mode after a fews seconds more holding (if Ramp after moonlight is off). Nice easy way to lockout the light with cold hands or gloves
Mostly just thank you! Fantastic, thoughtful piece of software designed to be both user and developer friendly.
The sequence to switch mode is useful as is, because this leads to the desired mode and there will be no chance to know in which mode the flashlight is without probing some features to find out.
Requesting features is nice, but see, memory on most used Attinyâs is already running full with the existing code. Ok, there could be some sort of adaptive feature-trimming depending on target chip, but this would lead to several completely different Anduril 2 in the field.
My point wasnât about the mode switching itself so much as using that as an example of how innaccesible I find the UI.
Basically Anduril takes 3 bits of info to decide how to respond to input. input code, current state and saved settings. To use it without a manual you need to memorise a matrix of those combinations.
i.e, just for 10H:
input code
current state
settings
result
10H
OFF
SIMPLE_MODE
Switch to Advanced mode
10H
OFF
ADVANCED_MODE
Simple Mode ramping config
10H
ON
ADVANCED_MODE
Manual Memory settings
10H
LOCKOUT
LOCKOUT
Set Auto-Lockout Timer
By re-using the same input codes for multiple unrelated functions we get two and a half problems.
1) The user canât mentally group functions by input code. If we could, it would effectively reduce the number of combinations to be remembered.
2) Collisions. If you misremember (see #1) then you are more likely to hit an unintended function. If this happens to change the state or saved settings then youâre doubly in trouble.
2.5) Collisions mean you canât safely just memorise some of the settings relevant to you, you have to have access to the whole flowchart in case you end up going down the wrong path.
From experience I can say that the combinations are quite easy to remember and logical.
Mode switching for instance usually happens only once after a reset.
And in case you need to switch modes frequently, you can remember them.
Configuration happens only a few times at the beginning, in the âplaying phaseâ and after that, the diagram is still everywhere in the net, if youâve lost yours.
A longer sequence prevents unintentional switching, but it must not be too long, as it will become unusable.
Same for the lockout:
Having fewer clicks would lead to more likely unintentional unlocking. Having a more complex pattern would make it more complicated. 4c is an excellent and broadly accepted compromise.
Plus there is that automatic lockout.
Lockout from off in one motion works by just holding the button until the ramp up and down ends with a short blip.
This helps as well, if a light is trapped in a bag and the button gets constantly pressed for a few seconds until this cycle is past.
Need just remember the 4c from lockout.
Moon from off exists. Hold from off and release as soon as the light comes on.
I am sorry, but your argument is not leading to a sensible goal.
There are only so many combinations you can have with a single button interface without having to click way too many times.
I think what you are missing here is that almost all of the config menus are accessible via 7C/H and 10C/H regardless of what they are doing. Yes, you'll have to memorize the contents of the menus but with your suggestion I would have to memorize the <number-of-clicks-to-access> on top.
Just tried and still works fine for me. Looks like Launchpad deprecated the âlp+â syntax for anonymous access but still works fine over HTTPS/SSL. Shout if you want me to tar the latest commit.
There are a fixed number of functions to access so the number of possible combinations you would need to memorise doesnât change either way. However, if you have functions grouped by clicks you can start to pattern spot (which human brains are good at) reducing cognitive load. Thatâs basically the core of UX design in software.
e.g. if 10H/C was consistently used for config menus then thatâs a pattern people could easily internalise and use. Instead it sometimes uses 7H/C and sometimes uses 10H/C and then re-uses both for non config functions.
Youâre never going to escape the problem entirely because, as you say, you only have a single button, but using 6+8+9 and more numbers above 10 would help.