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.