EffectPreset .csv format + fixes on SaXAudio

[DV666]

This PR contains some fixes to complement the last Odin's PRs (about SaXAudio).

The major issue is, when "spamming" a sound, it's not called again immediatly : the sound is still played until the end and silently. Seems the same sound is not recycle correctly.

Here is the summary of my PR :

➡️ EffectPreset .txt => .csv format

By default, the AudioEffects is a .txt file at the root of the mod folder => Imo, i prefer to move it into a .csv file, since it's the usual format used in Memoria.

=> New path: "StreamingAssets/Data/Voices/AudioEffects.csv"

The data on this file is the same as previous, i didn't change anything.

➡️ AudioEffectManager.Init() wrongly Init

I tested the Unity Debug mode made by Odin's PR and... my Visual Studio finds a critical issue on this part:

Memoria/Assembly-CSharp/Global/Sound/SaXAudio/AudioEffectManager.cs

Lines 296 to 309 in a7e58e0

	if (watcher == null)
	{
	watcher = new FileSystemWatcher("./", $"*{FILENAME}");
	watcher.IncludeSubdirectories = true;
	watcher.NotifyFilter = NotifyFilters.LastWrite;
	watcher.Changed += (sender, e) =>
	{
	if (e.ChangeType != WatcherChangeTypes.Changed) return;
	initialized = false;
	Log.Message($"'{e.FullPath}' changed");
	};
	watcher.EnableRaisingEvents = true;
	}
	initialized = true;

To be more precise, the FileSystemWatcher (line 298) was wrongly declared (because of this *).
If i understand correctly, since this thing was wrongly init, the Mono.dll was spammed a lot by this... and maybe that's one of the reason of these random crashes from SaXAudio ? (the famous crash with Mono.dll i get a lot of time from my previous investigations since the last year)
Anyway, with this little fix, the Debug don't say anything when launching the game now :)

➡️ SaXAudio.dll Sound Recycling Fix

As i said at the beggining, the major thing about this PR is to fix an issue where a sound wasn't recycled/replayed correctly immediately after being stopped with a fade-out.

An IA help me on this one to fix this issue (quite easily) : basically, a sound that used a fade prevented the engine from being re-invoked.
This small fix in SaXAudio.dll resolves the issue.

➡️ NCalc Expression Caching

This is an approach I’ve applied to quite a few features that use NCalc in Memoria (from my other PR #1255): the idea is simply to "pre-calculate" basic NCalc functions, particularly these ones.

Memoria/Assembly-CSharp/Global/Sound/SaXAudio/AudioEffectManager.cs

Lines 162 to 165 in a7e58e0

	Expression c = new Expression(condition);
	c.EvaluateFunction += NCalcUtility.commonNCalcFunctions;
	c.EvaluateParameter += NCalcUtility.commonNCalcParameters;
	c.EvaluateParameter += NCalcUtility.worldNCalcParameters;

This saves a considerable amount of processing time for the game: for SaXAudio, I don’t think it’s particularly useful… but at least it’s there :)

➡️ Little QoL for Debug Menu

The research bar is available for every type of sounds... i think it's more comfortable in that's way

[DV666]

With my old version of SaXAudio (which I tried my best to fix using ChatGPT/Gemini and my own experience)
However, I couldn’t get past Black Waltz 1 without it crashing (the mono.dll crash) with the Echo-S mod (which is great for testing SaXAudio)

Example :

mono.dll caused an Access Violation (0xc0000005)
in module mono.dll at 0033:099c3426.

0x00007FFB099C3426 (mono) mono_set_defaults
0x00007FFB099A8315 (mono) mono_print_thread_dump
0x00007FFB099A84A2 (mono) mono_print_thread_dump
0x00007FFB099A8921 (mono) mono_walk_stack
0x00007FFB098D0A2D (mono) mono_domain_finalize
0x000000001EF88B6F (Mono JIT Code) (wrapper managed-to-native) System.Reflection.Assembly:GetCallingAssembly ()
0x000000001EF88AAD (Mono JIT Code) System.Diagnostics.Trace:TraceInformation (string)
0x000000001EF6FFAE (Mono JIT Code) NCalc.Expression:Compile (string,bool)
0x000000001EF6FDFD (Mono JIT Code) NCalc.Expression:HasErrors ()
0x000000001EF6F0D3 (Mono JIT Code) NCalc.Expression:Evaluate ()
0x000000004665A642 (Mono JIT Code) btl_stat:SetOprStatusCount (Memoria.BattleUnit,Memoria.Data.BattleStatusId)
0x00000000466A5B25 (Mono JIT Code) btl_stat:CheckStatusLoop (Memoria.BattleUnit)
0x00000000466A2D7B (Mono JIT Code) battle:BattleMainLoop (FF9StateGlobal,FF9StateBattleSystem)
0x000000004663B900 (Mono JIT Code) battle:BattleMain ()
0x0000000046639E89 (Mono JIT Code) HonoluluBattleMain:UpdateBattleFrame ()
0x0000000046633ED2 (Mono JIT Code) HonoluluBattleMain:UpdateFrames ()
0x0000000046633606 (Mono JIT Code) HonoluluBattleMain:Update ()
0x000000000699725B (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
0x00007FFB099B4087 (mono) mono_set_defaults
0x00007FFB099083DD (mono) mono_runtime_invoke
0x00007FF63B54CDE3 (FF9) ScriptingArguments::AddString
0x00007FF63B54CB27 (FF9) ScriptingArguments::AddString
0x00007FF63B4702B0 (FF9) IIMGUI::IIMGUI
0x00007FF63B47295A (FF9) GetMonoBehaviourInConstructor
0x00007FF63B44C7BF (FF9) BaseBehaviourManager::~BaseBehaviourManager
0x00007FF63B50521E (FF9) RectT<int>::Contains
0x00007FF63B5D48F0 (FF9) PlayerMainWndProc
0x00007FF63B5D72EC (FF9) PlayerWinMain
0x00007FF63B9F171C (FF9) Unity::Component::CalculateSupportedMessages
0x00007FFB71A8E8D7 (KERNEL32) BaseThreadInitThunk
0x00007FFB72D8C48C (ntdll) RtlUserThreadStart

With this new version of Odin and the new Debug: before my fixes, I can confirm that Odin’s solution offers much more stable RAM (seems capped to ~1,7 - 1,8 Go)
I ran a test this weekend, where I managed to get as far as Clayra’s Temple… but I crashed whilst picking up a treasure…? (but no crashes in combat!)
The game froze for 2 seconds and shut down suddenly; nothing in the Memoria.Log and no Unity crash.
The next step for me is to run another test by starting a new game with Echo-S and the latest fixes I’ve made (particularly with the EffectPreset, which will really put it to the test).

[julianxhokaxhiu]

I personally reviewed the SaXAudio related patches and LGTM - well done and thanks again @DV666 :)