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:
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 2001 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.