Hi @malcolm, pinging you again on the theory this has escaped your attention. Can you confirm that my issue above is user error and not implementation error? Thanks.
1 Like
Sorry for the late reply! This is… somewhere in the weird gray area between user error and implementation error! It was working as designed, but the design had a subtle non-obvious non-optimality.
If you moused over the # icon, it used to say “track number in the task; either the last number or the number in the first regex group” and since your regex has a group, it was looking in there for the number. This is useful because it lets you beemind multiple numbers from the same intention. I used this for tracking calories, carbs, protein, awhile back:
But this seems pretty obviously dumb, so I’ve changed it so that it only tries using the user’s regex to find the number iff the user’s regex contains (\d+) somewhere. It doesn’t do this in the smartest way atm*, but I think it’ll suffice for all current implementations. And your thing should work now!
(*it uses the first regex group result that successfully parses as a number.)
2 Likes
Thanks, @malcolm! Looks like it’s working perfectly now. Gracias for digging around and solving the mystery. 
2 Likes
Is there a configuration option that can get a complice task to send a zero to a Beeminder goal? I was thinking that I would use Complice with a manually-tracked do-less goal.
If I do the thing I’m trying not to do, I log the data point manually. If I avoid it all day, then I complete the Complice task and get a zero sent to Beeminder, blocking the pessimistic presumptive.
1 Like
Hmmmmm… I don’t think so. You could set the multiplier to zero (that might be disallowed but you could set it to epsilon for sure) but the Complice system also sends a zero for a matching task that is incomplete (it needs to, to cancel out if that task was at some point accidentally completed or something)
There might be another way to do it, with eg the # or sum tracker and you would put in a zero or a number.
1 Like