Summary
On an island with Voice Attenuation (proximity voice) enabled, Verse voice channels have no effect on who hears whom.
-
Setting CanBroadcast := false for a player on EVERY registered voice_channel (the island’s default game channel returned by GetVoiceChannels() and a custom channel registered with AddChatChannel) does not mute that player. Everyone nearby still hears them exactly as before. Reading the value back returns false, so the write is accepted, but voice routing ignores it.
-
Two players in a custom voice_channel cannot hear each other beyond the attenuation distance, even though BeginBroadcastEvent fires for both on that channel.
The client keeps attaching the speaker’s voice to their pawn (LogFortProximityChatBusPoolSubsystem), and the client’s “prioritized player list” depends only on distance (1 player near, 0 far), whatever the channel state is.
As a result, the Verse Chat API cannot be used for anything that should not follow proximity: phone calls, radios, muting, private channels.
Please select what you are reporting on:
Unreal Editor for Fortnite
What Type of Bug are you experiencing?
Verse
Steps to Reproduce
- Island Settings: Voice Attenuation ON (Full Volume / Falloff around 30 m). Voice Chat Scope: .
- Add the Verse device below to the island and place two Button devices. Link them to MuteAllButton and PrivateChannelButton. Build Verse.
- Publish a private version (also reproduces in a UEFN launch session). Join with two accounts on two PCs. The two accounts must NOT be in the same Epic Party, and both use the Game voice channel.
- Stand side by side and talk. Both players hear each other (expected proximity voice).
- Press the Mute All button. The log should print:
[Repro] channel ‘BR.Any..Minigame_PlayerCreated_…_minigame0’: 2 member(s), 0 still CanBroadcast
(In our island, the equivalent on-screen report showed CanBroadcast = false for both players on that channel.) - Keep talking side by side.
- Second check: press the Private Channel button (registers a voice_channel holding both players). Walk 50+ m apart and talk.
Repro device (compiles on 42.30):
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /Verse.org/SceneGraph }
using { /Verse.org/AgentGroup }
using { /Verse.org/Chat }
using { /Verse.org/Verse }
repro_member_info := class(has_voice_member_info):
var CanBroadcast<override> : logic = true
ReproChannelName<localizes> : message = "Repro Private Channel"
voice_channel_repro_device := class(creative_device):
@editable
MuteAllButton : button_device = button_device{}
@editable
PrivateChannelButton : button_device = button_device{}
OnBegin<override>()<suspends>:void =
MuteAllButton.InteractedWithEvent.Subscribe(OnMuteAll)
PrivateChannelButton.InteractedWithEvent.Subscribe(OnPrivateChannel)
# Repro 1: after this, nobody should be able to send voice on any registered channel
OnMuteAll(Agent:agent):void =
if (SimulationEntity := GetSimulationEntity[]):
for (VoiceChannel : SimulationEntity.GetVoiceChannels()):
Members : [agent]has_voice_member_info = VoiceChannel.Group.GetMemberMap()
for (Info : Members):
set Info.CanBroadcast = false
var StillBroadcasting : int = 0
for (Info : Members, Info.CanBroadcast?):
set StillBroadcasting += 1
Print("[Repro] channel '{Localize(VoiceChannel.Name)}': {Members.Length} member(s), {StillBroadcasting} still CanBroadcast")
# Repro 2: every player in one private voice_channel; speaking events confirm the server sees the voice
OnPrivateChannel(Agent:agent):void =
if (SimulationEntity := GetSimulationEntity[]):
Group := agent_group(repro_member_info){}
for (Player : GetPlayspace().GetPlayers()):
Group.AddMember(Player, repro_member_info{})
Channel := voice_channel(repro_member_info){Name := ReproChannelName, Group := Group}
Channel.BeginBroadcastEvent().Subscribe(OnSpeaking)
Registered := SimulationEntity.AddChatChannel(Channel)
if (Registered.GetSuccess[]):
Channel.Enable()
Print("[Repro] private channel registered, {Group.GetMemberMap().Length} member(s)")
else:
Print("[Repro] AddChatChannel failed")
OnSpeaking(Speaker:agent):void =
Print("[Repro] BeginBroadcastEvent on the private channel")
Expected Result
- After step 5, nobody can be heard. The API reference for has_voice_member_info.CanBroadcast says: “Determines if the participant can send voice messages to the channel.” Every member of every registered channel has CanBroadcast = false.
- After step 7, the two members of the private voice_channel hear each other. voice_channel is documented as “a group of agents who can communicate via voice chat”, and nothing in the reference says membership is limited by Voice Attenuation. If attenuation is meant to override voice channels, that should be documented.
Observed Result
Observed in our island. Our phone-call system makes the same API calls as the repro device above, which is a minimal extraction of them.
- After step 5, nothing changes: both players keep hearing each other normally within ~30 m. CanBroadcast reads back false for both players on the default channel. Muting them on the custom channel as well (CanBroadcast := false there too) changes nothing either.
- After step 7, nobody hears anything beyond ~30 m, while BeginBroadcastEvent keeps firing for both players on the custom channel. The server sees the voice; the client does not play it.
- Client log (FortniteGame.log) after the speaker was set to CanBroadcast = false on the default channel:
LogFortProximityChatBusPoolSubsystem: Attaching voice chat audio for player [PlayerB] to pawn [PlayerPawn_Athena_C_…]
LogVoiceChatManager: Updating prioritized player list. Player Count: [1] (players side by side)
LogVoiceChatManager: Updating prioritized player list. Player Count: [0] (players far apart) - The client never joins a separate voice room for a custom voice_channel. It only joins the game room:
Joining channel Type=GameServer Name=BR.Any..Minigame_PlayerCreated_…_minigame0 … VoiceChatChannelType=Positional SpatialMode=PrioritySelection RenderingMode=AudioBus
with ProximityChatPriorityListProviderClass [FortProximityChatPriorityListProvider_UEFN].
Platform(s)
PC (Windows 11). Fortnite / UEFN 42.30 (++Fortnite+Release-42.30-CL-58557680). Reproduced in a private version and in a UEFN launch session
Additional Notes
- Found while building a phone-call system for a roleplay island. The real project shows the same behavior, with an on-screen report confirming CanBroadcast = false on the island’s default channel (“mudo/mudo”, Portuguese for muted/muted) while both players kept talking normally
- Log excerpt attached (server Verse prints + client voice log of the same seconds; player names and account IDs removed).
- Not tested yet: the same steps with Voice Attenuation OFF.
- Side note, possibly a separate issue: in UEFN launch sessions, where testers end up in the same Epic Party, Game-channel voice between party members was unreliable. Every Party/Game channel switch logged EOS warning 7002 “The channel has already applied in another streaming process”. The decisive test above was run in a private version, outside of a shared party.