Custom AI Rig / disabling automatic sensing

[SaurianParticipant]

Hi! For performance purposes I wrote a centralized queue for all AI where I can tell each one to sense, one at a time, once per frame. I call the AI.Sense function from it — however, I noticed today that AI.Sense is automatically called from AIRig in AIUpdate. I want to get rid of that call to AI.Sense in AIRig, so I tried making my own AIRig class, with identical code to the original AIRig (from what I was able to decompile, at least). However, when I attached it to my GameObject, several important parts of it didn’t work — the main ones I’ve noticed being that I can’t add sensors on the Sensing tab, none of the properties are displayed on the Animation tab, and the colors are a bit off.

Is there a better way for me to disable the call to AI.Sense? Or is there a better way I can create a custom AIRig? This queue system is crude but I think it will be very effective for performance, so I’d really like to use it, and I’d really like to keep using RAIN since overall it’s fantastic, but I’m not sure if I can if I can’t deal with the performance hog that simultaneous sensing creates.

Thanks!

[SigilKeymaster]

So once upon a time, we had a more centralized sensor system that would get updated each frame whether you were detecting or not, and detecting only did lookups and filtering on the list of aspects we had already gotten from BasicSenses. At least I think, it’s been awhile. So this is why you see all that infrastructure, and not to say it won’t be used in the future, but most of it is empty at this point. AI.Sense calls UpdateSenses() on BasicSenses, and that function is currently empty. You don’t need to call them either, so the queue isn’t quite working yet.

So most of the work actually happens in the detect node, when it either calls AI.Senses.Sense (can be expensive) or when it calls IsDetected (not as expensive, but if it fails it’ll call AI.Senses.Sense as well). So to handle your queue system, the easiest solution would probably be to use a custom action that takes the place of your detecting until it is the AI’s turn to detect:

selector
   custom action (class: DetectQueue)
   detect

DetectQueue would return success as long as it isn’t allowed to detect for real, at which point it would return failure, allowing the real detect to run.

[SaurianParticipant]

Thanks for the quick reply! So I actually don’t use a detect node to sense, and UpdateSenses being called anyway; I’m using my own custom sensor manager that inherits from Basic Senses and have my calls to Sense in UpdateSenses. Right now I have my queue entirely disabled, and my AI are still sensing, so I assume that the calls to UpdateSenses must be coming from AI.Sense being called from the AIRig. Could you think of any other explanation? If not, then can you potentially suggest a solution?
(If possible, I’d prefer to keep my behavior trees solely for behaviors and keep my optimization stuff separate).

• This reply was modified 6 months, 2 weeks ago by  Saurian.
• This reply was modified 6 months, 2 weeks ago by  Saurian.

[SigilKeymaster]

Yes, the rig calls AI.Sense, which calls AI.Senses.UpdateSenses. The actual intent for UpdateSenses is to do anything you need to do before the AI gets an opportunity to use its sensors (with a detect node or custom element).

The easiest solution would be to not do any actual work in UpdateSenses. Create a public function that you can call from your queue instead, and have that do the work.

[SaurianParticipant]

I just came to write that I had done that and saw you’d suggested it, my bad! Thanks again!

[SigilKeymaster]

[Author]

Posts