Native Audio, voice occlusion in same room

FiveM Discussion Bug reports
1

For a good bug report you should probably include:

  1. Client (production/canary) and FXServer version
    Canary 2189, FXServer 4193
  2. What you expected to happen
    If two players are in the same room they should hear each other without occlusion
  3. What actually happens
    Some camera placement will make occlusion in the same room
  4. Category of bug (eg. client, server, weapons, peds, native)
    Native Audio
  5. Reproducible steps, preferably with example script(s)

Hello,

With certain camera placement (back to a portal, leading to camera being in the other room?), audio occlusion will happen even if the 2 players are in the same room.
I understand that camera should be used for audio calculation but if two players are in the same room it should not have occlusions.

See the video:

Thank you

2 Likes
2

This seems more like a feature request than a bug to me.

3

2 players in the same room that hear each other like there is a closed door between them seems like a bug to me.

This is reported a lot by players in small rooms. Because camera goes to limbo on room next to current room.

4

I am talking about occlusion, not attenuation here.

In the video you can see that when the camera is in my back the portal occlusion (door office) are taken into account even if my camera was not in the other room totally

1 Like
5

Both are the exact same thing, neither is handled by our code, no matter if it’s occlusion or attenuation it’s the same, not a bug at all, R* design choice most likely, as it’s the way pretty much every game works.

Rather, what makes you think it ‘should’ take into account the player’s position and not the audio listener position which is the camera? In fact, does the game even have any built in interior like this without a door?

I also don’t know what the hell ‘a camera being in a room totally’ means, a camera origin is a point, not a sphere, it’s either somewhere or not somewhere, it can’t be somewhere ‘totally’. If the portal is misplaced somewhere that the camera clipping based on collision places the camera origin behind a portal, that’s a bug, but an art bug - not an audio bug.

Again: post a feature request topic maybe but I doubt this is easy or possible at all to decouple/change.