fmod improvements

[NotVeryProfessional]

I've added parameters to the fmodwait sequencer command. Feel free to use the code or improve on it in the next update:

In Start(), add/change after the event path:

Code: Select all

	        string paramName = GetParameter(2, "");
	        float paramValue = GetParameterAs<float>(3, 0);

	        PlayDialogue(voiceData, paramName, paramValue);

Then change the method:

Code: Select all

	    protected virtual void PlayDialogue(VoiceData inVoiceData, string paramName, float paramValue)

and inside the method after setting userData, add:

Code: Select all

	        if (paramName != "") eventInstance.setParameterByName(paramName, paramValue);

This is a pretty crude hack, but it works for me.

[Tony Li]

Hi,

Thanks! I've made the equivalent change, which will be in FMOD Support in DS 2.2.54. The code's slightly different, but the syntax is the same so you won't need to change anything in your content.

[NotVeryProfessional]

Cool. I was trying to make the syntax better, but couldn't quite make it work.

It seems to me that the first parameter (event) is only ever used in the callback (userData is not even available inside fmod), so IMHO it should be the last and optional parameter, but I'm new to fmod and maybe I'm missing something.

[Tony Li]

Events are used more often than parameters, although parameters are quite useful, too (e.g., to vary heartbeat audio when the player's health changes), so we'll keep events first in the list.

[NotVeryProfessional]

Yes, but it's actually the eventPath that determines which event to play.

For example, this:

Code: Select all

FMODWait(DefinitelyNotAValidEvent, event:/Voices/IntroComms, Track, 1)

Works absolutely fine. In fact, I can set the first parameter to whatever I want and I'll get the same sound playing.

Since the first parameter is stored in voicedata.key:

Code: Select all

            voiceData.key = GetParameter(0);

which is then sent into userData:

Code: Select all

	        eventInstance.setUserData(GCHandle.ToIntPtr(voiceDataHandle));

which is, as the FMOD documentation writes:

This function is primarily used in case the user wishes to 'attach' data to an FMOD object.
It can be useful if an FMOD callback passes an object of this type as a parameter, and the user does not know which object it is (e.g. if many objects of this type exist). Using Studio::EventDescription::getUserData would help in the identification of the object.

(https://documentation.help/fmod-studio- ... rData.html)

So userData is, AFAIK, just some arbitrary data that fmod doesn't actually do anything with (except handing it through to the callback).

Parameters are not just for heartbeats. I've seen discrete or label parameters recommended as the way to play voice clips and that's how I am using it:

Bildschirmfoto 2025-05-28 um 16.50.59.png (144.84 KiB) Viewed 2007 times

This is what I use the "Track" parameter for. I tell fmod to play the event event:/Voices/IntroComms and to set "Track" to 1 and it'll play the clip that I dropped into slot #1. In the next dialog node I'll do the exact same call and just change the 1 to some other number.

[Tony Li]

Got it. You could make a new sequencer command that a copy of SequencerCommandFMODWait.cs (e.g., call it SequencerCommandFMOD.cs or something) and change the order of the parameters. We'll keep the current order so it doesn't break other devs' existing projects.