Occasionally, ResoundingEngine.evalEnv() will return a sendGain[0] value of NaN. Currently, this has been observed (in high-reverb environments) to happen only if the sound event matches block.lava.ambient, but not every sound event of this type produces the issue. This behavior is rather peculiar, as there is not much code in Resounding that depends on the particular sound event. That is how we maintain support for modded sound events. The idea that this code is somehow flawed concerns me.
To Reproduce
Steps to reproduce the behavior:
In the resounding config menu, enable general debug logging.
In a normal world, go to a cave with naturally generated lava, either flowing or in a pool.
Wait and listen. Eventually the log will show that the first value of Send Gain and Send Cutoff (Reverb Gain and Reverb Gain HF respectively) is not a number (NaN)
Expected behaviorsendGain should consistently return an array of valid numbers, regardless of the environment or sound event.
Additional context
I have attempted to fix this issue, to no avail. Still, I have greatly reduced the number and frequency of NaN errors to what is described here, despite not actually knowing the cause. I have implemented a failsafe on line 751 of ResoundingEngine.java (f7d9fcf641afebbd246e06979b59463413c6188e) so that the code can continue to operate even in the event that it encounters this particular NaN value. This should be sufficient until the cause of the issue is discovered and eliminated.
Occasionally,
ResoundingEngine.evalEnv()will return asendGain[0]value ofNaN. Currently, this has been observed (in high-reverb environments) to happen only if the sound event matchesblock.lava.ambient, but not every sound event of this type produces the issue. This behavior is rather peculiar, as there is not much code in Resounding that depends on the particular sound event. That is how we maintain support for modded sound events. The idea that this code is somehow flawed concerns me.To Reproduce Steps to reproduce the behavior:
NaN)Expected behavior
sendGainshould consistently return an array of valid numbers, regardless of the environment or sound event.Additional context I have attempted to fix this issue, to no avail. Still, I have greatly reduced the number and frequency of
NaNerrors to what is described here, despite not actually knowing the cause. I have implemented a failsafe on line 751 of ResoundingEngine.java (f7d9fcf641afebbd246e06979b59463413c6188e) so that the code can continue to operate even in the event that it encounters this particularNaNvalue. This should be sufficient until the cause of the issue is discovered and eliminated.