NetworkSetTalkerProximity not working as intended (OneSync)

[TheDumpap]

How to reproduce:

1. Try setting a single clients talking proximity to: 5.0 (Using key controls, for example).
2. The other clients are still able to hear you, as long as their talking proximity is set higher.

What should happen:
When setting NetworkSetTalkerProximity(5.0) for a client, only clients within that radius should be able to hear him talk - regardless of their value in NetworkSetTalkerProximity.

[TheDumpap]

Is this something that you guys will acknowledge is a bug?

[barium]

@TheDumpap

What should happen:
When setting NetworkSetTalkerProximity(5.0) for a client, only clients within that radius should be able to hear him talk - regardless of their value in NetworkSetTalkerProximity.

Are you sure of this? Do you have any documentation from R* or code that says that ‘should’ happen?

This isn’t a ‘bug’ though, on OneSync it’s designed to set the range at which you can hear other players.

[Nathan_C]

NetworkSetTalkerProximity only sets how far you can hear other voices. It’s always been that way. Why would it work any differently?

[TheDumpap]

Before OneSync it would set the range of your voice - meaning how far you would talk.

[Mooshe]

The normal behavior for NetworkSetTalkerProximity is that it set both the hearing and talking range for the client.

For example, let’s say we have ClientA which has their proximity range set to 5.0, and ClientB which is someone else who is 8 meters away, has their proximity range set to 10.0.

Neither ClientA nor ClientB would be able to hear each other, despite ClientA being within ClientB's proximity.

Here is a diagram of how it works:

[TheDumpap]

Exactly. And right now if another client sets the native to a higher value, they can hear the player with the lower value - even if they’re out of range.

[nihonium]

Not sure how this can be resolved - I’m not sure if there’s a way to add arbitrary metadata (the sending client’s range setting) to the voice channel.

[Mooshe]

@nihonium

Not sure how this can be resolved - I’m not sure if there’s a way to add arbitrary metadata (the sending client’s range setting) to the voice channel.

Yeah, with the legacy system all clients had to be aware of each other’s proximities, and from what I can see in the mumble implementation, there’s no easy way to do that.

I think a better compromise would be supporting the native NetworkOverrideReceiveRestrictions which would allow developers to build legacy-like (or custom) behavior when it comes to VoIP in OneSync. I believe Mumble also supports client-sided overrides for hearing as well.

[TheDumpap]

Yeah. Implementing a way for developers to implement their own behavior for VoIP would be the best solution in my opinion.
Also, thanks for the detailed diagram explaining my issue

[aGift4u]

Anyone got a workaround for this?

[PERPGamer]

There was a script released here:

[Release] Better voice chat (no more voices through walls)

Hello everyone, I’m releasing a lite version of my “custom voip” resource. This time it is in lua. This version provides a better 3D voice chat of the current built-in GTA:O VOIP. It is obviously, a standalone and optimized resource. Commands F6 > toggle voice range FYI With this system you can build some new communication system without any others VOIP: phones, radio, megaphone etc… It doesn’t work on “hearing range” unlike NetworkSetTalkerProximity, the script transport your voice to ot…

That fixes this but it doesn’t work on OneSync (like Mooshe said)