Sound Events Don't Play Simultaneously At The Portal And At The Actual Sound Event

[MalekiRe]

• Only the latest version is being supported. If you are using an outdated version, upgrade to the latest version.
• If you find an issue, check whether this issue happens with only this mod. If not, check which mod it's incompatible with. And include that mod's link in the issue.
• The Forge version is not being supported. If you find an issue of the Forge version, check whether the same issue exists for the Fabric version. Forge-version-specific issues belong to https://github.com/qouteall/ImmersivePortalsModForForge/issues

Sound Events don't play simultaneously at the portal and at the actual block or entity creating the sound event. This leads to sound "cutting out" when you go through a portal, prevent smooth non-jarring transitions. I specifically have a sound that I like to play at the creation of my portal and want to be able to walk through the portal and still hear the sound. I know this would probably need a larger rewrite of how the sound engine works, probably some sort of mixin into the SoundSystem class at the public void play(SoundInstance soundInstance) method. More specifically starting at line 316 down to line 328 where it determines if the game should notify listeners that a sound event happened based on if a player is near enough to it, as well as a small change to the MixinClientWorld_Sound mixin that changes how sound works, to play sound simultaneously.

public void play(SoundInstance soundInstance) { ... if (h == 0.0F && !soundInstance.shouldAlwaysPlay()) { LOGGER.debug((Marker)MARKER, (String)"Skipped playing sound {}, volume was zero.", (Object)sound.getIdentifier()); } else { Vec3d vec3d = new Vec3d(soundInstance.getX(), soundInstance.getY(), soundInstance.getZ()); boolean bl3; if (!this.listeners.isEmpty()) { bl3 = bl || attenuationType == SoundInstance.AttenuationType.NONE || this.listener.getPos().squaredDistanceTo(vec3d) < (double)(g * g); if (bl3) { Iterator var14 = this.listeners.iterator(); while(var14.hasNext()) { SoundInstanceListener soundInstanceListener = (SoundInstanceListener)var14.next(); soundInstanceListener.onSoundPlayed(soundInstance, weightedSoundSet); } } else { LOGGER.debug((Marker)MARKER, (String)"Did not notify listeners of soundEvent: {}, it is too far away to hear", (Object)identifier); } }...

[qouteall]

How did you play the sound? Did you use ClientWorld's playSound?

[MalekiRe]

I used world.playSound(); which includes client world in one of the ticks technically.

[MalekiRe]

This applies for literally anything though. Jukeboxes, if you start them playing when you're on one side of a portal, then move through the portal, you stop hearing it, etc. It doesn't play the sound events on both sides, and, from my own experimentation, changing it so it does play the sound event on both sides doesn't actually work.

[froyo4u]

odd, why does that not work

[MalekiRe]

I think it may have something to do with the game not playing sound events if there is not a player near enough to hear it.

[MalekiRe]

https://youtu.be/LhLSiQ7WRSs?t=80 This is mumbo jumbo talking about how a mod that had made a skulk sensor, (before skulk sensors were actually in the game) only worked if a player was near enough to the sound source for it to actually trigger, the Minecraft devs had to change the sound engine in some way that plays sound events no matter if there is a player nearby or not, in between those two versions. This is a perfect example of what I'm talking about. In 1.16 sound events wont start playing if there isn't a player near enough to them for them to actually start.