TimeMonitor only works if Tick is called every frame
wilg opened this issue · 7 comments
It does not seem like there is a way to call Tick() less than every frame, due to the way TimeMonitor just wraps Time.deltaTime. It seems like it should calculate the delta itself in this case.
How exactly could it calculate the delta without knowing the previous frame though? You'd essentially have to do some caching on the current frame and check if it changed I believe. Open to implementation ideas here and pull requests are always welcome
Well I'm happy to calculate it myself, but the built in helper functions pass in a newly created TimeMonitor so I cannot pass my own implementation in.
My workaround is to make copies of functions like WaitTime that take my own TimeMonitor which calculates the delta time from the difference in Time.time since Tick was last called.
Perhaps the time monitor should be somehow a part of the tree (or builder) itself, not each node, so that it can easily be overridden in one place?
Another design could be an overload of Tick that takes a deltaTime and it's internally passed to where it needs to be. Or Tick or a similar function could do its own bookkeeping. But the main issue that prevents a user of the library from handling this problem is the hardcoded TimeMonitors being created in the extension methods.
I think the easiest way to change the implementation might be to allow an injectable interface that overrides the time calculations. ITimeManager or something like this.
interface ITimeManager {
getTimePassed: () => float;
}
You would then have to create a custom implementation of the TimeMonitorBase<T> probably and inject the interface implementation. So with that much effort it feels like it might be easier to just create a custom action at that point. Let me know your thoughts.
Semi-related note: not updating every frame also causes the (great!) debugger window to flicker.
Interesting. What version of Unity are you using? Don't think I've seen that behavior.
Closing this one out since it would essentially require a new time logic calculation rewrite. Feel free to create a new PR or move this convo over to the discussions https://github.com/ashblue/fluid-behavior-tree/discussions