0
0

Due to a file rename of an fsb, one of our calls to getEvent was failing.

While debugging, I dragged the execution of the program such that it called getEvent again. To my surprise, this succeeded. I found this very odd.

Basically if you call getEvent() and it returns FMOD_ERR_FILE_NOTFOUND (and doesn’t give you an event handle back), you can call it again and it will return FMOD_OK (and give you back an event handle). (Obviously it’s not going to play)

Is this intentional? Because it’s rather inconvenient when two different places in our code happen to try to get the same event by name, because one will succeed and one will fail, but neither of them will actually play anything.

  • You must to post comments
0
0

No but you shouldnt be renaming fsbs under fmod’s feet, i’m not sure how you thought it would work properly after that.

  • You must to post comments
0
0

Of course I don’t expect it to work. I realise it was an error on our part to rename the fsb. That is just anecdotal.

What I’m saying is that the fact that FMOD sometimes returns success when calling getEvent even though it failed to load is bad. Literally calling getEvent twice in a row will succeed the second time if the event references an fsb that cannot be opened.

group->getEvent( "test", EVENT_DEFAULT, &event ); // fails
group->getEvent( "test", EVENT_DEFAULT, &event ); // succeeds:

It should return FMOD_ERR_FILE_NOTFOUND no matter how many times I call getEvent.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.