For now leave this aside, or bring it up-to-date with CBA.

Imo it should be up to the user to check whenever it's ready. This should only return false or an error code that it couldn't run. The removal of these waitUntilAndExecute would make the _onDisplay event redundant.

The display on which the QTE is drawn should be an argument, so that people can run it wherever they want to (e.g. Zeus interface). Because of comment below, this is no longer relevant.

I really dislike this strongly. It uses CBA settings for keybind sets, when we can use CBA keybinds instead.
This would allow for way more flexibility and customisability, as 3rd party mods or mod makers could add their own extra keybinds.

Register 4 keybinds. Here's an example (strings would need to be localised and improved):

["QTE Keybinds", QGVAR(keyUpQTE), ["QTE up key", "Up key used in QTE events."], {
    ["↑"] call FUNC(keyPressedQTE); // return
}, {}, [DIK_UP, [false, false, false]]] call CBA_fnc_addKeybind;

In fnc_keyPressedQTE, you'd check if the keypress is good or not:

params ["_eventQTE"];

// Check if the passed parameter is the next key in the QTE sequence
// If yes, continue
// If no, stop

Imo, we should make the QTE agonistic of the QTE chars themselves ("↑"). That should be configurable by the user. It will add an extra layer of complexity to the whole things, so we'll have to see if it's worth it.

Let's keep it simple and start with assigning keys to "↑" etc then we can look at expanding to other keys.

Personally have a problem with QTE events cuz it expands into Quick-Time Event events.

Making it Quick-Time Events ain't just 2 letters longer, I admit, but shouldn't matter:

Up key used in QTE events.
Up key used in Quick-Time Events.

The other headers are formatted different from this one.

A lot of tabs in this file at least.

Argument needs description.

It would be None, but the whole point of using a function over an event is so that you can return something.

We want to "override" input if it's a valid QTE keypress, meaning that e.g. if you have bound your arrow up key to move forwards, you wouldn't move forwards while you are doing a QTE.

Is this where we return true/false in terms of input override?

Yep

I'm still not a fan of this. Depending, we might have to wait indefinitely. It also means that multiple QTE can queue up, which could cause unforeseen headaches, albeit unlikely.

I think we'd be better off returning a boolean telling the caller if the QTE was successfully run or not.

As far as I can tell, there is no reason to use a hashmap object.

You can't pass _this when using default arguments. The default arguments are not inserted into _this, you'll have to pass each argument individually in an array.

Regardless, _this here does not make sense. Pass [_object, _start_time, _timeout, _max_distance] and read those in the loop instead - unless reading from GVAR(QTEArgs) is faster?