HasHeadset natives not working properly on OneSync

Client

Using canary? No
Windows version: Windows 8.1
System specifications: A10 6800K, 16GB RAM, GTX 1060

Server

Operating system: Local
Artifact version: 1626 (still on 1933)
IP address: Private
Resources: 100+
System specifications: Local server

Incident

Summary: These natives was not working properly on OneSync (On Non-OneSync they work normally):

  • NetworkPlayerHasHeadset (is only returning false)
  • NetworkHasHeadset (is only returning false)

Expected behavior: To return true when is using a headset
Actual behavior: Returnin false in any case
Steps to reproduce: Just use these natives and print the result
Server/Client? Client

EDIT:
NetworkGetEntityKillerOfPlayer is broken too (returning invalid player killers)

Are these ever false on PC normally? This sounds like a console thing to rely on. :confused:

Got any example of using such?

NetworkPlayerHasHeadset and NetworkHasHeadset: On Non-OneSync they return true when microphone is configurated properly, and active (On menu: Settings -> Voice-chat). I will give more details when this return true on other cases too, because i don’t remember if sensibility affect these natives too.

NetworkGetEntityKillerOfPlayer (not returning valid player killers): I have a script who collect when players die and save a log about it, after the OneSync was activated, these logs stopped working properly, rarely it return a valid entity, seems like it not returning a valid player killer when their slot is higher then 32. I will do some tests about this native in specific. The Headset ones i’m 100% sure it’s not working on OneSync for a long time.

No, it’s not ever false on PC, it’s true when Microphone is enabled on (Settings -> Voice Chat).

Sensitivity, volume, or other things don’t make the return to be false. It will return true even when the Sensitivity is zero, or the volume is zero too, what it’s check is if the Microphone is enabled. MAYBE it’s checks if the microphone is valid, but i’m not sure about that.

Ah. Should this, then, be changed for Mumble scenarios to ‘is Mumble connected’ and ‘is player connected to Mumble’?

If players without Microphone cannot connect to Mumble, yes.

Oh - you’re talking about the input toggle, not the output toggle? That’s going to be an interesting state to transfer… local mute could perhaps work for this.

If i understand correctly, yes.