Is it possible to mute/unmute the microphone via keybind?

[shbztzg]

Hello,

I’m wondering if it’s possible to mute and unmute the microphone via a keybind when using pma-voice, without relying on the Push-to-Talk or Always-On options in GTA’s voice settings.

In SaltyChat with TeamSpeak, users can mute themselves completely using a dedicated keybind. I would like to achieve a similar behavior with pma-voice, where pressing a key (e.g., "J") mutes the microphone and pressing it again unmutes it.

My Questions:
Is this functionality currently supported by pma-voice?
If yes, how can I implement a toggle mute keybind?
If not, would it be feasible to add this feature in a future update?
I appreciate any guidance or suggestions on how to achieve this!

Thank you in advance for your support!

[AvarianKnight]

Most of what pma-voice does is just wrap the built in FiveM mumble calls into a way that users most commonly want to use them, if it isn't exposed via that then we cannot do it natively.

You can implement this via an export, but its not very nice

pma-voice/client/init/proximity.lua

Lines 17 to 23 in 8908dd6

	exports("overrideProximityCheck", function(fn)
	addProximityCheck = fn
	end)
	exports("resetProximityCheck", function()
	addProximityCheck = orig_addProximityCheck
	end)

And return false in it like so

exports['pma-voice']:overrideProximityCheck(function()
    return false
end)

and call the reset function when you're done

exports['pma-voice']:resetProximityCheck()

I've noted down to myself that there isn't a way to do this and already wrote some stuff to add it to the mumble implementation

[shbztzg]

Thank you for the quick and detailed response!
I really appreciate your help and the explanation. I’ll keep an eye out for future updates and I’m excited to see this feature being added to the mumble implementation.

Thanks again for your support – and keep up the great work! 😊

[SeaLife]

Most of what pma-voice does is just wrap the built in FiveM mumble calls into a way that users most commonly want to use them, if it isn't exposed via that then we cannot do it natively.

You can implement this via an export, but its not very nice

pma-voice/client/init/proximity.lua

Lines 17 to 23 in 8908dd6

exports("overrideProximityCheck", function(fn)
addProximityCheck = fn
end)

exports("resetProximityCheck", function()
addProximityCheck = orig_addProximityCheck
end)
And return false in it like so

exports['pma-voice']:overrideProximityCheck(function()
return false
end)
and call the reset function when you're done

exports['pma-voice']:resetProximityCheck()

I've noted down to myself that there isn't a way to do this and already wrote some stuff to add it to the mumble implementation

Hey,

Since switching from Salty and testing PMA, I've implemented some modifications for additional mute checks that I believe would be valuable as default features.

While overrideProximityRange is useful for specific scenarios like megaphones:

exports['pma-voice']:overrideProximityRange(120.0, false)
-- [...]
exports['pma-voice']:clearProximityOverride()

I've also modified our PMA version to allow for a dedicated local mute status. This enables players to mute themselves by pressing a key. (As mentioned in another issue, we faced server hangs using MumbleSetPlayerMuted, which isn't relevant to this discussion.)

My current implementation prevents adding any targets if a player is muted, regardless of active proximity overrides. This acts like a separate, overarching mute. This approach makes it easy to:

• Mute a player when they are dead (they can't reach any targets, effectively muting them).
• Mute a player when they press a key:

local function ToggleLocalMicrophone()
    if exports['pma-voice']:isMuted() then
        exports['pma-voice']:setMuted(false)
    else
        exports['pma-voice']:setMuted(true)
    end
end

lib.addKeybind({
    defaultKey = 'Y',
    description = 'Mutes your microphone',
    name = 'mutemic',
    onPressed = function (self)
        ToggleLocalMicrophone()
    end
})

I'm happy to provide a pull request if this is something you'd consider. I believe the role-playing (RP) community could greatly benefit from a native replacement for SetPlayerAlive and a robust local mute function, both of which PMA could easily provide.

Modifying PMA ourselves creates difficulties with future updates, so we're keen to incorporate these RP-related features directly into PMA. What are your thoughts on this, @AvarianKnight?

//EDIT:
Yes i've read #180 and i think due to the latest changes you could reconsider those decisions. 😊
I understand why there should be no checks to player liveness but a mute state could be leveraged by another script which does that. A dedicated mute state would greatly improve the usability and would prevent any additional scripts which overrides any proximity checks/ranges to accidentially override those checks if another script had overwritten them for muting

Best regards,
SeaLife
Project Lead, Altera Vita RP

[AvarianKnight]

Before something like this is added I would like to have a better way for clients to mute other clients, I already wrote it up a while ago but never had the time to actually test that it doesn't break stuff, and I also did a bunch of fixes to the mumble protocol FiveM uses since then.

It should also be noted that something like this shouldn't really be a simple true or false since we're the "manager" of everything we have to make sure this is usable for every resource that needs to use it.

You can see here for how its done on for radios, something similar would probably be necessary for a mute state too so one resource can't accidentally unmute a player when they should've been muted.

[SeaLife]

If i can be of any help, dont hesitate to contact me. We could do testing in a production environment for example. :)

You can see here for how its done on for radios, something similar would probably be necessary for a mute state too so one resource can't accidentally unmute a player when they should've been muted.

This Bit-behaviour would require every script to use a unique bit, right? I think it would be better to remember a mute state per resource rather a bit number which could be duplicated - maybe even a combination of resource and bit/identifier so you could issue multiple mute states per resource independently from other resources.

I will demonstrate the issue with some pseudo code:

-- Resource A
exports['pma-voice']:addRadioDisableBit(2)

-- Resource B
exports['pma-voice']:removeRadioDisableBit(2)

This will remove the disableBit from resource A "by accident". You would nee to configure unique bit numbers for each resource which may be a problem for paid resources.

PMA could use GetInvokingResourceName() to enfore a "if you mute, you need to unmute again" rule. Maybe a additional exports to overrule this, but idk..

[AvarianKnight]

If i can be of any help, dont hesitate to contact me. We could do testing in a production environment for example. :)

You can see here for how its done on for radios, something similar would probably be necessary for a mute state too so one resource can't accidentally unmute a player when they should've been muted.

This Bit-behaviour would require every script to use a unique bit, right? I think it would be better to remember a mute state per resource rather a bit number which could be duplicated - maybe even a combination of resource and bit/identifier so you could issue multiple mute states per resource independently from other resources.

I will demonstrate the issue with some pseudo code:

-- Resource A
exports['pma-voice']:addRadioDisableBit(2)

-- Resource B
exports['pma-voice']:removeRadioDisableBit(2)

This will remove the disableBit from resource A "by accident". You would nee to configure unique bit numbers for each resource which may be a problem for paid resources.

PMA could use GetInvokingResourceName() to enfore a "if you mute, you need to unmute again" rule. Maybe a additional exports to overrule this, but idk..

It can run into the same issue, yes, but it would be up to the end user to handle that, at that point. One would hope paid scripts would document which bit's they use to disable voice chat.