According to your testing, does the issue occur with ONLY Immersive Portals mod installed?

Yes

Forge Version

40.2.4

ImmersivePortals Version

1.4.17

Latest Log

N/A

Crash Report (if applicable)

N/A

Steps to Reproduce

1. Setup Music Triggers to play audio based on player dimension
2. Cross Dimensional Portal Boundary
3. Music Triggers does not update the player current dimension and will not play the correct audio based on location

What You Expected

Music triggers is meant to track player location and audio events can be assigned accordingly. When dimensions are stacked using Immersive Portals, the player location according to the Music Triggers debug menu will update when the player crosses the portal boundaries.

What Happened Instead

The player current dimension. according to Music Triggers, remains in the first dimension they spawned in.

Additional Details

No response

Please Read and Confirm The Following

• I have confirmed this bug can be replicated without the use of Optifine.
• I have confirmed the details provided in this report are concise as possible and does not contained vague information (ie. Versions are properly recorded, answers to questions are clear).
• I have confirmed this does not happen on the fabric version (If it does please report to here instead).
• I have confirmed I'm not using a hybrid server (Magma, Cauldron) or a different (non official) Forge Server release.
• I have confirmed this issue is unique and has not been reported already.

Here's an example multi mc export to showcase the bug. Loading up a new world and stacking the Overworld on top of the Nether dimensions will cause the music track to restart constantly and/or bounce back and forth between the 2 tracks.

It seems as though Music Triggers is not aware of what dimension the player is in and constantly swaps back and forth:
music_triggers_imm_portal_test.zip

Music Triggers is reading the LocalPlayer.level field, that is swapped between all visible dimensions in order to allow ticking of the (client)world to occur correctly. As it runs it own thread, from time to time Music Triggers ends up with the "wrong" dimension, thus changing the played music. To resolve this, I currently see the following potential fixes:

1. I'm simply going to mixin into Music Triggers in order to patch each mention of LocalPlayer.level with our own helpers (ClientWorldLoader.getWorldAsync(RenderStates.originalPlayerDimension)). However, the triggers are actually Bi-Functions, Mixin into them is not fun, as it randomly likes to explode /hj. Also I'd like to avoid using any more mod-specific Mixins, as that blows compile times if I want to actually test my fixes.
2. The Entity class (LocalPlayer extends Entity) contains a getter for this field. (getLevel()). If Music Triggers would switch from direct field access to using the getter, I'd be able to mix into the getter, thus enhancing it with the ability to give the expected value to Music Triggers thread. This would however require checking the thread, as such adding quite some overhead to an often called method.
3. An option to easily overwrite the triggers in music triggers. This would allow IP to load a module simply replacing all Bi-Functions with patched ones. This would be my preferred fix, but would requires some work on Music Triggers side. (I'll be in touch with them shortly)
4. Simply adding multiworld aware triggers. But that wouldn't fix the issue, just circumvent it.