I found a bug in your CheckCSharpEvent class. It will only ever work when the FSM is running every frame. I have my FSMs set to run every 0.2 seconds and they never catch the events. The problem is that the CheckCSharpEvent task returns the result to the below methods in the parent ConditionTask class which only holds the result for a single frame. By the time my FSM fires again, the result it purged.
///Helper method that holds the return value provided for one frame, for the condition to return.
protected void YieldReturn(bool value) {
if ( isRuntimeEnabled ) {
yieldReturn = value ? 1 : 0;
StartCoroutine(Flip());
}
}
On a somewhat related topic, I’m setting my FSMs to run every 0.2 seconds in the hopes to avoid many FSMs running on the same frame. Am I correct in this assumption, or will all FSMs that are present at start run on the same frame always, just with 0.2 seconds breaks between execution? Do I need some other approach to stagger the execution of my agents?
Regarding your question/issue, indeed, certain event-based conditions (most of them really), only return true for one frame due to YieldReturn method. This was really made so by design, because I remember that latching the result and only “consuming” it after the condition is evaluated created some other implications. Having your FSMs evaluate every X seconds may or may not achieve what you want depending on how you implemented the “every X seconds update”. May I ask why you want to do this though? Is it a performance concern, or something entirely different? Because if it is a performance concern, the updating of an FSM is honestly very fast (unless of course the actions within it do some heavy lifting).
Yeah, I can see how caching the event results can potentially cause problems and hard to find bugs. No worries, I’ll set everything to execute on every frame for now and revisit this in the future with my own custom tasks if needed. Thanks for the quick response!
To answer your question, yes, I was planning to stagger agent execution to avoid frame-rate stalls – but this is premature for me right now. I’m making a colony management simulation and so there’s potential for heavy lifting depending on how I build out the AI – there’s lots of list searching in these sorts of games. I’ve managed thus far to keep things pretty quick by using dictionaries wherever possible instead of lists for (near) O(1) searching for tasks, resources, items, buildings, etc. I guess I’m more or less planning for optimizations that may not be needed at this point 😉 I’ve a bad habit of prematurely optimizing my stuff.
Thanks for your time; I’ve really loved using your product. Unity should pay you truck loads of cash to have it built into the editor. It’s honestly the only reason I’ve not bothered to explore other engines at this point.