Ahha! Got it. Reproduction when I realized it only happened when the Behavior Tree Reference had to not only supply variable values but also get those values from bound variables! (yeah, that’s kind’a complicated but it makes sense if you’re a Behavior Designer user. Comment if you’d like an explanation.) Right, time to package up and send my minimal reproduction case to Justin who, knowing him, has probably fixed it already in his usual paranormally prescient mien! (sorry, I should have mentioned that I’m an incorrigibly loquacious inkhorn 😛 )
Right, done. Time to confirm his ‘fixed’ version doesn’t. (Not expecting to since it didn’t in actual project.)
Nope, got myself a drink, a shave, a quick play with my kids and he’d fixed it in 30 minutes. Seriously, are there any better asset developers than Justin at Opsive?
So no errors but no movement either. Debugger! Oh, not getting calls to my OnFixedUpdate() call again! Did I lose my change to allow super-classes to be recognized as holding Behavior Designer callbacks again? Think I need to feedback to Justin that his fix for this just doesn’t. Hmm, restored my change but still doesn’t recognize as having OnFixedUpdate()? There’s some change directly above. Hm. Ah, yep, he’s added System.Reflection.BindingFlags.DeclaredOnly which precludes inherited members! Doh. Let’s remove that and check. Yup. Feedback time (I supplied a patch for this previously but he went with a different solution which doesn’t seem to do the job I’d expect — not sure why).
OK, with that fixed, my PIDController works perfectly in the AIDev project — time to try it on an actual Snowman? Oh, nope, forgot I was working through a list from part 1 of this endeavour. So, repathing rate seems like the next part. Then over to actual SnwScf project.
So, repathing. Should it check whether the target position has changed or simply repath regardless? It’d be more efficient not to repath if it’s not changed but perhaps a new path is required just for the seeker being in a new position? Could make it an option but think will go with always repathing for now. (YAGNI)
Done that, of course now need something to test it’s updating its path with! Re-enabling my old waypoint following TargetBot for it to chase 🙂 Done.
Next to create a new BT to do chasing! After dinner. Roast chicken! Yum!
After dinner, it didn’t take long to make this:
Works! Left branch is all merely finding the closest GameObject tagged “Target”. The right branch gets target position moves towards it and periodically repaths.
My only concern with it is one of efficiency: that Parallel doesn’t really need to do the left branch every frame — out really only needs to do that when when repathing is needed. Think I should probably leave as is for now since (a) it’s not a costly other branch and/or (b) optimized later if profiling says needed. Part of me wonders how behaviour trees most efficiently do a “when consumer needs it” operation? I find myself wondering whether one ends-up bastardising a Composite or a Decorator Task as the top level such that it can do part of its logic then indicate whether it’s child/children should run (then the rest of its logic).
Lost er, ‘invested’ the rest of the evening (after putting the boys to bed) playing Duck Game and Move or Die with a friend — online! (think they both started as local multiplayer, Duck Game definitely — I originally played this on my Ouya!). Both excellent! Both on Steam Sale this weekend (and DG is free-weekend)!
More development tomorrow morning (before swimming with 1.5 year old in afternoon) and we should see the AI not getting stuck any more … well, unless it’s against another player since I’ve not integrated the A* Project’s RVO facility. But the way it’s used means it should be OK so another YAGNI.