Initialize to empty path if .strings.bank not loaded

[ambiguousname]

As a follow up to #428, an error/warning message would be useful here to help people in situations like mine diagnose the problem more easily.

Since not everyone might want to load in strings, happy to make this a warning instead; also happy to move this message to more bus/event specific loading code. Let me know what would work best.

[Copilot]

Pull request overview

Adds diagnostic logging to help users understand why FMOD objects fetched by path (e.g., buses/events) may fail at runtime when the corresponding strings bank isn’t loaded (follow-up to #428).

Changes:

• Replaces the silent getPath(...) check in FMODCLASSWITHPATH with ERROR_CHECK_WITH_REASON(...) to emit a helpful message when path resolution fails.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

wrapped->getPath(...) can fail (e.g., when the strings bank isn’t loaded), but the return value from ERROR_CHECK_WITH_REASON(...) is currently ignored. If it fails, path remains uninitialized and ref->_path = String(path) can read garbage / run past the buffer (undefined behavior) while also continuing to populate _guid. Handle the failure explicitly (e.g., initialize path to an empty string and/or early-return an empty Ref or set _path to "" when getPath fails).

[ambiguousname]

I noticed the PR checks timed out; I currently have FMODPASS and FMODUSER as secret variables in my fork if that helps.

I'm also not sure if you'd like me to address Copilot's review: the feedback seems to be outside of the scope of "add an error message to a pre-existing error". I'd be happy to expand scope to include more checks for the result of getPath, if that's a preferable solution.

Let me know if there's any other concerns I can address.

[CedNaru]

Hello.
So from what i undestand, we would still get an error if no string bank is used, which doesn't go well if one with to use pure guid. So probably, trying to get the path itself shoudln't trigger an error and silently pass set the path to a null value.
Then if one wish to use that path in anyway, the getter for the path shoud in this case raise the error and print that message.
What do you think?

[ambiguousname]

I think that makes sense to me. I will update this PR when I have some time to include those extra checks.

[ambiguousname]

Finally had some time to test this, I improved the error checker, initialized the path with empty values (in case loading fails), and added a message which prints the guid of the event that fails to load.

[ambiguousname]

Ah, and I forgot to address the feedback about moving the errors to the getter, will do so shortly

[ambiguousname]

So, I looked into implementing the above, and I don't think inserting errors into the getter works because of the caching system. When a bank is loaded, strings_to_guid is updated with the getter get_path, leading to an error on bank load regardless if the user intends to use strings.bank or not.

The cache emits warnings for the editor/debug builds when it cannot find a path from strings_to_guid, so maybe the fix here is to just initialize to an empty path on a failed load and let the existing cache warnings at least signpost where something has gone wrong.

Related to this, I found a bug in _create_event_instance where it does not check the validity of the event description before attempting to get its inner wrapper (i.e., when .strings.bank is unloaded). I've updated this PR to include a fix for that.

Edit: Just found another similar bug in FMODServer.play_one_shot