Add error message on path not found

[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.