NetworkSetTalkerProximity not working as intended (OneSync)

TheDumpap · 2019-06-26T16:51:33.852Z

How to reproduce:

Try setting a single clients talking proximity to: 5.0 (Using key controls, for example).
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 · 2019-06-28T11:54:41.920Z

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

barium · 2019-06-28T13:21:10.928Z

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 · 2019-06-28T13:29:55.794Z

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

TheDumpap · 2019-06-29T10:51:33.472Z

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

Mooshe · 2019-06-29T16:21:00.815Z

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:

image512×512 16.6 KB

TheDumpap · 2019-06-29T16:32:59.958Z

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 · 2019-06-29T19:01:08.104Z

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 · 2019-06-29T23:31:17.185Z

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 · 2019-06-30T17:38:14.463Z

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 · 2019-06-30T18:10:27.938Z

Anyone got a workaround for this?

PERPGamer · 2019-06-30T22:04:39.162Z

There was a script released here:

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

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)