Is this a correct way to do that I need to check instance’s state in RuntimeManager.cs update function,so I should add some code in fmod plugins.But Once I upgrade the project(like 1.0 to 2.0),the additional work is to check these files to merge,and why do you not add these functions such like “SetSoundCallBack” function in internal project?
To achieve my logic code separate from plugins project ,I do these work.
This is startup work.
https://drive.google.com/open?id=10s407WLZczlDtrONcRqozh4_i2NFVvXs This is “CallBack” code according to “timeline” example.But I’m doubt about it that AudioManager.cs and RuntimeManager.cs update() funtion’s order,RuntimeManager might run first and delete instance,so AudioManager didn’t receive correct callback.But it woks well.So is there correct work?
I wonder that set sound callback and when it’s called, change finished state,so I can check state in Update().Because callback is from another thread,otherwise I need to check state in RuntimeManager’s update. This work is in a global manange script.Is it acceptable as I don’t want change RuntimeManager.cs? I want some suggestions ~~
I’m not sure what you mean by this, there is a
EventDescription::setCallback which will be assigned to all event instances subsequently created from the event.
You can specify/change script execution order in Unity.
Perhaps,I don’t think you understand what I say.
At the beginning, I do use EventInstance::getPlaybackState, it need that I add some code in RuntimeManager.cs.Of course,it works.But when next upgrade,I need to merge these changes like
After that,I use EventDescription::setCallback,but it works in another thread,not in unity’s main thread.
However,I can change some parameters like you do in the Timeline example but it can not excute your delegate directly.And then I try to excute the delegate when I check the parameter’s change in the scrpt’s Update() function.It works too,so I ask that Is it also a right way ?
About script execution odrer in Unity,I know this.And I also let RuntimeManager.cs later then default script like that.
There shouldn’t be any race conditions that you need to worry about, our callbacks should execute on the same thread that calls RuntimeManager::update.
It doesn’t sound ideal to use a callback to set a bool on an object so that you can poll the object in Update later. You should be able to trigger your action from the sound stopped callback.
OK，thanks for your reply