For the sake of having a more robust code, I suggested to the developer to use GUIDs instead of names, so that I could reorganize my FMOD project names and folder without consequences. However, it seem that parameters GUIDs has no use. Parameter value can only be set from the parameter’s name or the parameter’s ID (which has to be retrieved… by the parameter’s name). So what’s the point in having GUIDs for parameters if there’s no use for them? Am I missing something?
The developer found the GUID format a bit… heavy (3 number and an array). What’s the point in having the possibility to define 3.4*10^38 (32 hexa digits) different events/snapshots/parameters within the same FMOD project?
By the way, the doc says something ambiguous:
Objects can only be identified by path if the project’s strings bank is loaded.
Does that mean that if the strings bank is loaded, we can’t anymore use GUIDs? But because parameters seem to be accessible only by name, we must load the strings bank (are we?). So… we can’t use GUIDs at all, if I understand well. This doesn’t make really sense, I’m probably missing something. Could someone explain?
Firstly, everything in FMOD has GUIDs, it’s part of the foundation of how the Studio project format works. GUIDs were chosen to allow remote teams to build content in isolation and minimize collisions when merging everything back together again.
Regarding the strings bank, it is simply a mapping from Event path to GUID, without the strings bank loaded the Engine does not know how to map the provided event:/path/to/event to its internal GUID (which is how it is stored). The idea here is you use paths within your level editor because they are human readable, then serialize the corresponding GUID for use at runtime (faster lookup) and not load the strings bank in game. Conceptually you can bind your game objects to your Studio project by either using GUID or path depending on your desired behavior when things are renamed, regardless, seeing the paths in your editor helps.
Parameters work in a similar fashion, you can enumerate them within your editor using names for user friendliness, then use the IDs at runtime for speed. Previously (before we had parameter IDs) we used indices instead, nice and small, quick to lookup at runtime, however horrible if you use LiveUpdate because the parameter order would shuffle. This is why we switched to IDs, which are stable and always work regardless of live update changes.
Now finally, why IDs and not GUIDs? As you say GUIDs are heavy and we were deprecating the index method which was really light. It wasn’t reasonable to switch a 4 byte lookup to a 16 byte one, we compromised at 8 bytes. Additionally this is a trial run, we believe we can transition all GUIDs to IDs reducing the overall bulkiness of the memory footprint considerably, parameter IDs is the first step.
This is probably more than you wanted to know about how the sausage is made, but that’s the current rational, I hope that answers your questions.
I have a similar problem, are GUIDs still the way to go? They’re a bit big so currently I store all the GUIDs inside an array and then just use 32bit indexes to put in my entity structs.
GUIDs are still the way to go for the benefits I mentioned above, however if you want to manage your own lookup table in front of those, then that could be good for reducing the bulk.
How are GUIDs way to go as there’s no way to get PARAMETER_ID using them?? There’s only getParameterDescriptionByName and getParameterDescriptionByID. Even when using getParameterDescriptionList, descriptions have no GUIDs so there’s no way to get Parameter using GUID.
The lack of any easy way to get a Parameter ID from a GUID is frustrating, so thanks for pointing it out - I’ve added it to our internal feature/improvement tracker. That said, here’s an example C# function that does a Parameter GUID to ID lookup:
FMOD.Studio.PARAMETER_ID ParamGUIDToID(FMOD.GUID guid)
{
FMOD.Studio.PARAMETER_ID paramID = new FMOD.Studio.PARAMETER_ID();
studioSystem.lookupPath(guid, out string path);
studioSystem.getBankList(out FMOD.Studio.Bank[] banks);
foreach (FMOD.Studio.Bank bank in banks)
{
bank.getEventList(out FMOD.Studio.EventDescription[] eventsDescs);
foreach (FMOD.Studio.EventDescription eventDesc in eventsDescs)
{
eventDesc.getParameterDescriptionCount(out int count);
for (int i = 0; i < count; i++)
{
eventDesc.getParameterDescriptionByIndex(i, out FMOD.Studio.PARAMETER_DESCRIPTION paramDesc);
if (paramDesc.guid == guid)
{
paramID = paramDesc.id;
}
}
}
}
return paramID;
}
I’d advise against using this lookup function repeatedly however, especially if your Studio project and banks are quite large. If you do use the script, or rewrite it in whatever language you’re using, let me know whether you run into any issues with it.
Just to make sure I understand you correctly: Would you advice not to use GUIDs for parameters for large projects, snd thus having to rely on (fragile) strings for parameters?
There’s nothing specifically bad about using parameter IDs vs string paths, besides the weak vs strong link to your FMOD Studio project. What works best for you will depend on your project/game and workflow.
My advice specifically relates to the code snippet I posted - since it iterates over banks and events in order to perform the Parameter GUID to ID lookup, it’s computationally expensive at runtime, especially if your project is large/complex. This could be reduced by optimizing the code, caching the results, etc.
Here in 2025. Is there not a simpler way to get a PARAMETER_ID from a GUID? It does feel like having parameters treated so differently throws a wrench into things.
I see we can get a GUID from a PARAMETER_ID but not the other way around. It’d be lovely to have that functionality.
At the time of writing, no - the code snippet I posted above is the simplest way of doing so. That said, I’ve noted your interest in the functionality in our internal improvement tracker.