Where would the above code go ? Seems really cool.
I was reading back through this, and for this purpose wouldn’t:
inline constexpr float degreesToRadians(int32_t deg) noexcept {
return deg * M_PI / 180.F;
}
Be more ideal? Just that way you’ve a function to clearly do what’s desired syntactically rather than a macro.
Wherever you’d like to trigger the control to move the presets like that. Which is probably inside a case in Event2.
Maybe, I don’t have a strong oppinion either way.
Can it be added “as is” in Event2 from Saber_Fett263_Button.h, just after
#else
// 2 Button Controls
(on line number 5241) ?
Not unless you want it trigger every single time Event2 is called. You would combine a switch trigger (and/or gesture) along with the angle check and preset switch.
I think we are not both talking about the same code.
I was talking about:
Doesn’t that trigger an Event2 (if inserted in the right place)?
Indeed, we were not referring to the same thing.
That would not “trigger an Event2,” though. That segment does have a case label to be put inside the Event2 switch already.
let me rephrase that.
Would this code:
When inserted in saber_Fett263_buttons.h just after
Would that work as intended or would it create some conflict with some of the other “case” ? I am asking because further down, there is:
// Choreographed Battle Mode
case EVENTID(BUTTON_AUX, EVENT_HELD_LONG, MODE_OFF):
which is the same “case” (line 5761)
Yes it would, for exactly the reason you pointed out. If you try to compile, it would show the exact same problem of a duplicate case.
This is why prop building is so tricky. Finding an unused button event that makes sense can be tough.
Now if the 2 identical cases are guarded from one another, then they can exist since only one of them is considered at a time.
For example the 2 button control case you mentioned is contained within
#if NUM_BUTTONS == 2
so a duplicate case outside of that would not be a conflict.
Ok, thanks for confirming. I thought so. I changed EVENT_HELD_LONG to EVENT_HELD_MEDIUM because this is not duplicating another “case”.
EVENT_HELD_* might not duplicate a case, so it will compile, but it’s likely that it still causes problems as long clicks and long “holds” can either both be triggered, or one just overriding the other, depending on the code.
As Profezzorn stated, this will likely prevent EVENT_HELD_LONG from ever happening, provided the medium case returns or breaks.
So what could be my option(s) to make it work ?
You just need to find a button action that’s not in conflict. Maybe adding a mod of power or aux button, or maybe a third click? I think fett263 despises multiple click things so that’s probably available and likely an option if you’re ok with it.
Thanks NoSloppy,
i went with this:
// 2 Button Controls
case EVENTID(BUTTON_AUX, EVENT_THIRD_PRESSED, MODE_OFF):
Only Power uses some “third pressed” and only in the one button config.
I recommend using SAVED_CLICK events instead of PRESSED events.
It causes less conflicts with other things.
Did you try that? I think you’d want more like EVENT_THIRD_SAVED_CLICK_SHORT.
edit - Like he said 
1 Like
Done, thanks:
case EVENTID(BUTTON_AUX, EVENT_THIRD_SAVED_CLICK_SHORT, MODE_OFF):
I didn’t know there was a difference between a press and a click. On the mouse of my PC I can do a double click or a double press (without release on second time) and they do the exact same thing.
I went with the 1st “THIRD_something” I found since I do not know the difference in implication between:
- EVENT_something_PRESSED (this I guess press X times)
- EVENT_something_RELEASED (this press X times and release the last time)
- …_CLICK_SHORT (the Xst click is short, but the others could be medium or long ?)
- …_SAVED_CLICK_SHORT (this one I don’t even understand what the “SAVED” is for ? As in the other cases the clicks are not saved so they can’t be counted ?)
And then there are these two:
- EVENT_THIRD_HELD_LONG
- EVENT_THIRD_CLICK_LONG Is it a long pause before the 3rd click ?
I would love to understand the idea behind the different options.
ProffieOS/buttons/button_base.h is good to have a look at, as well as
ProffieOS/common/events.h.
Pressed is not great for most things as it registers as soon as the button contact closure happens. But it’s great for something like “wake up the motion chip” after a nap.
Released happens when the button is let go of, … pretty obvious. Mostly good for ending lockups for example.
A CLICK is a pressing and releasing of the button.
Not quite. They’re all short clicks in succession. (pressing and releasing each time).
A timed click (medium or long) is held down for N duration. There are defaults set for these times in the aforementioned file. They can also be customized in a prop file.
The designated click in the event (like THIRD in EVENT_THIRD_HELD_MEDIUM) is the one that the timing applies to. In this case, the 1st and 2nd click would be short, followed by the third held for more than 800 but less than 2000ms.
I may be off on these exact numbers, but you get the idea.
The “saved” click is a way to allow the user to “get to” a click that would normally be pre-empted by an “un-saved” click.
For example, say you want to trigger your double click button action. Well, sequentially this goes like:
1st click happens - this is where the code WANTS to execute whatever you have set for a single click action, but if it did that, you’d never get to a 2nd or 3rd click without always triggering your 1st click action. So instead, we “save” that click for later so we can wait a moment to see if another click is going to occur, and then if it does, consider the 1st click as 1 of N on the way to a numerous click event.
So if you had both an EVENTID that used EVENT_FIRST_CLICK_SHORT, and another that used EVENT_SECOND_CLICK_SHORT, you’d always get 2 EVENT_FIRST_CLICK_SHORT events instead of being able to "get to " your 2nd click event.
A bit wordy, but does that make sense?