You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could mean that FiveM thinks that some keys are pressed when they are not or vice versa. Especially because mumble checks
for that control usage for either in-game controls or the InputHook controls and your voice will get stuck if the stream is created after you start talking.
I've done some debugging myself and traces show that:
Windows API call received
Key 32 is now UP
Windows API call received
Key 68 is now DOWN
Windows API call received
Key 68 is now DOWN
Windows API call received
Key 68 is now UP
Windows API call received
Key 68 is now DOWN
Windows API call received
Key 68 is now UP
Windows API call received
Key 68 is now DOWN
Windows API call received
Key 68 is now UP
Windows API call received
Key 87 is now UP
Windows API call received
Key 160 is now UP
Windows API call received
Keyboard message for voice: true
Key 222 is now DOWN
vKey 222 is my bind for push to talk and I create the stream at the first PTT usage. After 222 key is pressed down - userMedia stream is created - its never lifted UP and no further events are passed by windows.
I have not done enough audio programming to have an intuition as to why that may be. Maybe two sources - mumble and NUI trying to get the same data and corrupting something? Maybe something is eternally waiting for some mutex to unlock?
Maybe someone that knows the codebase a little better can find/give me ideas where to find problems and solutions?
Expected result
The rage input hook should keep updating states
Reproduction steps
Create userMedia output for audio when clicking the Push to talk button
Importancy
Slight inconvenience
Area(s)
FiveM
Specific version(s)
3258, 3095 FIVEM
Additional information
No response
The text was updated successfully, but these errors were encountered:
What happened?
Whenever you create a CEF userMedia output stream in a NUI resource ex:
It freezes the
GlobalInputHandlerLocal::WndProc
and so noGlobalInputHandlerLocal::KeyboardMessage
is ever fired.code/components/rage-input-five/src/GlobalInput.cpp
This could mean that FiveM thinks that some keys are pressed when they are not or vice versa. Especially because mumble checks
for that control usage for either in-game controls or the InputHook controls and your voice will get stuck if the stream is created after you start talking.
I've done some debugging myself and traces show that:
vKey 222 is my bind for push to talk and I create the stream at the first PTT usage. After 222 key is pressed down - userMedia stream is created - its never lifted UP and no further events are passed by windows.
I have not done enough audio programming to have an intuition as to why that may be. Maybe two sources - mumble and NUI trying to get the same data and corrupting something? Maybe something is eternally waiting for some mutex to unlock?
Maybe someone that knows the codebase a little better can find/give me ideas where to find problems and solutions?
Expected result
The rage input hook should keep updating states
Reproduction steps
Importancy
Slight inconvenience
Area(s)
FiveM
Specific version(s)
3258, 3095 FIVEM
Additional information
No response
The text was updated successfully, but these errors were encountered: