Call another quest behavior from my own behavior

[Sanjo]

Hi,

I'm currently writing a custom quest behavior that should combine some other behaviors to simplify to write profiles by minimizing the needed input from the prfile writer. In my behavior tree I dynamically want the quest bot to execute another quest behavior. How do I inject the behavior (tree) of the other quest behavior in the root behavior tree, so that this behavior will be executed immediately?
Will this code do it?

var currentRoot = TreeRoot.Current.Root;
if (currentRoot is GroupComposite)
{
   var root = (GroupComposite)currentRoot;
   root.InsertChild(0, anotherBehavior.CreateBehavior());
}

Or AddChild or is there a methode in the BotBase I missed?

 

[chinajade]

Hi,

I'm currently writing a custom quest behavior that should combine some other behaviors to simplify to write profiles by minimizing the needed input from the prfile writer. In my behavior tree I dynamically want the quest bot to execute another quest behavior. How do I inject the behavior (tree) of the other quest behavior in the root behavior tree, so that this behavior will be executed immediately?
Will this code do it?

var currentRoot = TreeRoot.Current.Root;
if (currentRoot is GroupComposite)
{
   var root = (GroupComposite)currentRoot;
   root.InsertChild(0, anotherBehavior.CreateBehavior());
}

Or AddChild or is there a methode in the BotBase I missed?

My understanding is this is not possible without a lot of hacking and code bloat in your behavior. The problem is the way the HBcore invokes behaviors. Each behavior is contained in a stand-alone DLL that is dynamically linked into the HBcore when needed (a single behavior invocation), then unlinked when no longer needed.

This causes a lot of problems:

• Behaviors have a very difficult time passing information from one invocation of themselves to the next.
  UserSettings does this, but it had to do a lot of gyrations, and had some significant limits on what it could do.
  
  
• Behaviors cannot call other behaviors because those other behaviors are not in the code segment address space if your behavior is running.
  To get around this, you would have to load the other behavior's DLL inside your behavior, and make clumsy arrangements for the proper calling sequences. If the other behavior wasn't yet in DLL form, you would have to make arrangments to have it 'compiled', also.
  
  
• Behaviors have no way to pass information 'out'.
  By HBcore design, information flow is one way--into the behavior only.
  
  
• etc.

I've begged Nesox to get us an area where we can place 'common code' for behaviors. This would include other sub-behaviors like 'anti-drown', 'hunting ground', 'move near location', 'target selection', etc that almost every behavior needed.

Alas, he is still considering technical solution to the problem, and I'm afraid its not very high up on his priority list either.

In short, you're screwed and must resort to cut-n-paste of the items that you need from the other behaviors. Its a nightmare, I know. I've obviously not been very clear on how much of a nightmare when making my requests for a solution.

sorry for the bad news,
chinajade

 

[Sanjo]

Thanks for your reply. The main behavior I wanted to invoke is the built-in ForcedObjective. Is it possible to get an object of it? Are these limitations of dynamic loading only for custom quest behaviors (that are not in Honorbuddy.exe)? If I can get an object of ForcedObjective this is all I need. Because then I can get the behavior tree of it and can integrate it into my behavior tree dynamically. OnTick and OnStart etc. can be called in the same methodes of my behavior I think.