Please read the wiki before submitting a bug report!

Bug description
If you fly the camera away from a conversation, it becomes quieter despite the player not moving server-side. Other parties in the conversation hear you at normal volume.

Steps to reproduce the issue

1. Install both simple-voice-chat and a Freecam mod
2. Engage in a conversation
3. Activate Freecam
4. Continue conversation

Expected behavior
Expected proximity to be based on player position, not camera position. This may sound counter-intuitive, until you remember that other players and the server only have the player position, not the camera's.

Proposed Solution
I've put together a small branch, but I haven't opened a PR since I'm new to your codebase and I haven't had chance to test my changes yet. 1.19.3...MattSturgeon:simple-voice-chat:freecam

Log files
N/A

Versions

• Minecraft version
• Forge/Fabric/Bukkit/Spigot/Paper version
• Mod/Plugin version

Other mods
Freecam

Screenshots (Optional)
Visible in several of Xisumavoid's Hermitcraft episodes.

Thanks for taking the time to look over this. Merry Christmas btw, assuming you celebrate the holiday season 🎄

I hadn't realised you intended the F5 screen to use camera position over player position too. For me the latter still makes more sense, but I see how that's subjective.

I think it'd be good to avoid having to resort to using groups or similar if there's a possibility of making proximity work properly.

Would you consider having a method that checks if the camera is in third-person-mode and then returns either player or camera position accordingly?

Alternatively, would you consider an optional feature that selects between player or camera positioning?

The only other approach I can think of would be to have the Freecam mod inject into your methods when freecam is active, but IMO that's less elegant than fixing the incompatibility at the source. This would mean every freecam mod has to implement and maintain mixins targeting your mod.

I think it'd be good to avoid having to resort to using groups or similar if there's a possibility of making proximity work properly.

Thats not the solution I proposed.

Alternatively, would you consider an optional feature that selects between player or camera positioning?

You could do that with the API

The only other approach I can think of would be to have the Freecam mod inject into your methods when freecam is active, but IMO that's less elegant than fixing the incompatibility at the source. This would mean every freecam mod has to implement and maintain mixins targeting your mod.

My solution to this problem would be to measure the distance between camera an player. If its more than lets say 16 blocks, the voice transmission is changed to a static audio channel (See API for reference).

But this won't be a part of the base mod. If you have some modding experience, you can archive that with a few lines of code. If not, I might take a look at it and create an addon mod.

This is completely intended. It would also break the F5 screen. You can create an addon mod with the voice chat API that switches the audio source to a static one like a group, if the camera is further away from the player.

I've reflected on this a little more I feel like I've done a poor job of explaining my perspective.

I'll try and illustrate the point using an example that doesn't need freecam:

If I've understood your intended behaviour correctly, when I am in F5 mode, I will hear voices as if my ears are 4 blocks behind the player, yet other clients will hear still hear my voice as coming from my player's mouth (not my camera's position). This is effectively the same bug I described before, just at a smaller, less noticeable, scale.

I don't think a "static" mode is the correct solution either, since I still want further away players to be quieter and I still want to sound quieter to them too. Unless I'm misunderstanding what you mean by "static".

I think the point of contention comes down to “which entity am I whilst I'm playing Minecraft”; am I the camera entity or the player entity? I would argue that the player entity is what interacts with the world, interacts with other players, and it is the player entity doing the talking and listening.

If you insist that the camera is what is talking/listening, not the player, then the server should be kept in sync with the camera position (in addition to the player position).

This way every client can agree on where voices are coming from.

Regarding your proposal of a small "compatibility" mod: if you're unwilling to include compatibility fixes in your codebase then, sure, they'll have to be implemented elsewhere or left broken.

It seems excessive to require users to install an additional mod just for a single minor bugfix, but I guess affected mods might choose to bundle it as an additional library within their jar. Still a heavy solution to a small problem.

Another issue I have with a dedicated compatibility mod is that it will require maintenance every time Minecraft or SimpleVoiceChat updates. Any mods bundling the fix-mod would also require additional maintenance every time the fix is updated, or worse those mods may be blocked from updating until the fix has been. If the fix was implemented within an existing codebase, any additional maintenance would be far less.

I may sound argumentative, but I do respect that this is your project that you volunteer time to maintain. I really do appreciate you taking the time to listen to my proposals, make counter-proposals and explain your views and intentions.

There already is freecam support in the latest beta version (in #beta-testing on the discord).
I would appreciate feedback on that implementation.

There already is freecam support in the latest beta version.

Thanks for working on this! What a wonderful surprise 😀

I would appreciate feedback on that implementation.

I've been playing around with it this evening, I've got a few points of feedback/discussion:

1. config option

I'm assuming you made the fix optional to make testing during the beta stage easier? I can't see why it'd be needed for the finished version.

2. behaviour

While in freecam mode, if the camera is within 8 blocks of my player, I hear other players at roughly the correct volume, although it does shift slightly as the camera moves around.

However, as soon as the camera is over 8 blocks from my player, other players are heard at full volume. This is particularly noticeable if you move the camera across the 8-block threshold while another player is speaking.

Instead, while in freecam mode I would expect to always hear other players at the volume they would be if my camera was positioned at my player's eyes.

3. implementations

I would replace the getFreecamDistance() >= 8D check with something like

!(mc.player.isSpectator() || mc.player.equals(mc.getCameraEntity()))
//aka
!mc.player.isSpectator() && !mc.player.equals(mc.getCameraEntity())

This is simpler and avoids hitting a weird threshold when moving the camera to/from the player.

I've spent the evening experimenting with your implementation and playing around with different approaches. This branch seems to be working pretty well. I'll open a PR if you'd like to review/discuss my changes.

My aim was to seamlessly transition in/out of freecam without other player's volume changing, but to also ensure that stereo affects are not applied while in freecam. I've tried to follow suit from your implementation where possible. I haven't tidied up the commit history yet, in case you were interested in my iterative thought process.

It is not possible to make it sound the same as if your camera was at the player while in freecam. You only get audio data and the players UUID. So if your freecam is further away than players are rendered, the mod doesn't know how to position the audio.

It is not possible to make it sound the same as if your camera was at the player while in freecam.

Distance-based volume was working fine in my test branch.

So if your freecam is further away than players are rendered, the mod doesn't know how to position the audio.

That isn't how freecam works, rendering distance is still centered on the player (not the camera) because the server isn't told the camera is moving around independently.

So if the camera goes out of (the player's) render distance, nothing gets drawn to screen.

I know, but the other players around you won't get rendered after a certain distance from the camera. Independently from render distance.

Ok, maybe my assumption was just wrong. Or maybe this depends on the implementation of the freecam mod. I think I tested it and it didn't work after being far enough away. But I also don't remember which mod I used to test it.

In testing my branch, voice chat continued to work as expected even after flying the camera several chunks out of render distance, so long as both my player and the other player were in proximity of each other.

I was using hashalite's freecam and an open-to-LAN world.

I'll test again later more thoroughly, checking behaviour is the same on a dedicated server and with other freecam mods.

If it does turn out to be some freecam mods working differently than others then this is probably a bug on their end. I would imagine handling entity lists differently when in/out of freecam would lead to other issues with their mod too.

Tested again more thoroughly, still working as intended. I haven't test any other freecam mods yet as I couldn't find any other's that could run on 1.19.4. I may backport the changes to older versions and test other freecam mods if I get time, no promises.

I've cleaned up my changes and opened #555 for review.