Access/Expose AIController variables


Hi have a noob question.

I have 3 types of NPC.

A basic one (move and idle) An Aggressive one (move idle chase and hunt) A Scared one (move idle run away from you)

I made 2 blueprint

Basic NPC Char Basic NPC Cont

those 2 blueprint handle all the default things that occur with every NPC.

Now I’m doing the others one, but i have a problem. Since one patrol, one fly away from certain things etc… they need a different behaviour tree AND different variables.

I would like to set those variables in the Controller and put them in public, and edit them. I found more logic that the controller handle the custom params of those NPC and not put those variables in the character (maybe I’m wrong?)

The problem is, since the Aggressive NPC Cont is spawned ONLY when i press play, I can’t edit those custom variables in the “inspector”.

My question is, is it possible to expose the variables of the controller in the “inspector” before pressing play? Or do I must add those variables in the character ?


When you say ‘inspector’, to what do you mean?

Here is how I would do what I think you are describing, given what information is here:

  • Set a variable in your character actor which you use to designate which kind of behaviour you want for a given NPC. e.g. an integer where 0 = basic, 1 = aggressive, 2 = scared
  • Make sure this variable is editable.
  • Create child blueprints of this actor with the variable modified, for each of the types of NPC.
  • Within your task blueprints, check the variable of the AI controller and use conditional branches to make tasks which don’t apply to that NPC fail in the tree.

I would think a separate controller would be the best way to go. Or at least a core class which covers the shared behaviour, and extend this with the different behaviours for each NPC. This way is more modular, and can be re-used if you want to introduce a new NPC class. This is the way a C++ (or other object orientated language) programmer would do it, and a good habit to get into.

EDIT: Oops! Ninja-d! By several hours…

Mbel is right. I’d also say that you should look at making the suggested integer for the behaviour an Enum, to keep control of the range of behaviours.