Event ends up with incorrect casing of starting letter

Hey there, I have a funny bug to report which seems to be a one-in-a-million case!
In my FMOD project, I got an event named beep_single_v2 and a folder called BulletHits/.

When iterating over the events in Unity using EventManager.Events, I noticed though that for some reason, my beep_single_v2 event is called Beep_single_v2, with a capital B, which it doesn’t have in FMOD. Rebuilding the project or renaming didn’t help, it always does the same thing.

I wanted to figure out why, so I opened the Master.strings.bank file in a hex editor and I think I found why this is happening:


You can see that the B is only present once, and then it’s missing from both my beep_single_v2 event and the BulletHits folder. Is this some sort of compression method to store same consequetive letters only once? Because if it is, it seems to ignore letter casing, which might be the culprit for my issue.

It’s not super important for us, but still a funny thing I thought I’d report. Cheers!

Indeed you are absolutely correct, the strings are stored in a case insensitive radix tree which can cause some odd capitalizations when reconstructing the strings back from the bank. This is done for efficiency reasons but does have that slight consequence.

I see, thanks - glad I was right with my assumption! It would be cool if this would be optional though, as we’re building editor tools and the wrong capitalization makes some problems currently.

All the FMOD APIs that accept the paths should be case insensitive, so there should be no issues there. If you are creating hashes from the paths I’d recommend lowercasing them before hashing.

Unfortunately this behavior can not be changed without switching to a completely different internal data structure. In the original design we decided that the advantages of the radix tree structure, in terms of memory and performance wins, outweigh the disadvantage of imperfect case preservation, especially considering that path lookups are meant to be case-insensitive anyway.

Yea, as I mentioned, it’s not about accessing events but more a matter of displaying them in a list as we’re comparing them against an internal list to find discrepancies. But we’re doing that with a lowercased check now, so all good! Thanks for the insight :slight_smile: