Initial voice range needs to be reduced (and actually set)

#1

When loading into the game the initial voice range is global because it’s not set (int 0, and we need a float), and we can not set in a timely fashion.

This results in a timeframe from 1-5 seconds where you can hear everyone on the server when joining in.
Kinda annoying on packed RP server, where people talk all the time.

Here’s a clip from on of our streamers, which ofc also finds it quite annoying, lmao.

Clip 1

Clip 2

Here’s a monkaS solution that we are currently using, but still gives “ear rape” when joining in:

-- fix for OneSync global voice -- attempt 1 -- not working
AddEventHandler('onClientResourceStart', function(name)
	if name == GetCurrentResourceName() then
		NetworkSetTalkerProximity(7.0)
	end
end)
-- fix for OneSync global voice -- attempt #2
Citizen.CreateThread(function()
	local fixingVoice = true
	NetworkSetTalkerProximity(0.1)

			while true do
					NetworkSetTalkerProximity(7.0)
					if not fixingVoice then
						 print("[srp_voice] OneSync Voicecancer work-around succeded")
						 break
					end
					Wait(1)
			end

				-- we break the loop after 15 seconds
			SetTimeout(15000, function()
					fixingVoice = false
			end)

end)

Suggested solution
A simple solution to this would be that the default is not 0 (global)
It did make sense for testing & debugging purpose voice at an earlier point.

A value like 10.0 would be could for starters.

2 Likes

#2

Another solution would be to delay the voice authentication by 5-10 seconds, so that we can set the value client-side before connection is established!

0 Likes

#3

I did notice something, this is effecting all thing that rely on proximity as they join they join the server. For example in that period of time where you can hear everyone I could also hear local sound effects played through JS and local text chat.

Seems like their is an overlap period where they have spawned but have no positional data.

0 Likes

#4

Which resources you are using?
I was using esx_voice till one week ago and there was no issues like that. Now im using teamspeak and there cant be issues like that :smiley:

Dont know how it is with the onesync mumble integration

0 Likes

#5

@kn0pee - That is actually true. We’re using local commands for RP, those can you see within the same period when joining in.

So that confirms your tese about no positional data.

0 Likes

#6

Yeah what “no positional data” actually translates to in OneSync I’m not sure but hopefully it is somewhat useful.

0 Likes

#7

Probably fixed :eyes: https://github.com/citizenfx/fivem/commit/8d3aef0805375e70fbcdaf477db037315177e2ed

1 Like