Composite.Start() method

[RahlRB]

Mastahg,

While playing around a bit with a combat routine for pet classes, I've come to realize that when I'm doing both my players rotation, along with trying to handle the casting for pets....I can only actually cast 1 of the abilities at a time.

What I am looking to do is create my own "PetCombatBehavior".

It would look something like:

private ActionRunCoroutine _petCombatBehavior;
public ActionRunCoroutine PetCombatBehavior
{
    get { return _petCombatBehavior ?? (_petCombatBehavior = new ActionRunCoroutine(ctx => PetRotation.Combat()));
}

I can get this code to work just fine. What I'm realizing is that I will need to actually start a new worker thread and actually pulse that Composite myself on that new worker thread.

I'm not worried about the details of starting up a new thread and making sure I don't have syncing issues, but where I would like a little help is in actually starting the Composite itself and doing the ticks.

I see that ActionRunCoroutine has a Start() method, but it takes an Object as a parameter and I really don't know what I should be passing into it.

The idea I have is that in my event handler for OnBotStart, I would create a new thread while passing it a cancellation source. In this new thread is where I'd call the Start method on the PetCombatBehavior and handle anything else I need to.

Then in my event handler for OnBotStop, I would call cancel on my cancellation source so that I can gracefully exit the Pet thread.


Do you see any problems with the above ideas?

What do you pass into the Start() method on a Composite?


Thanks in advance,
-Rahl

 

[mastahg]

You need to backtrack, your heading down a path that doesn't lead to what you want to do. Spooling up another thread is the #1 no no for too many reasons to list. Use a treesharp hook on "Heal" or add some logic to the top of your heal rotation that always returns false so that it will always execute the logic below it.

 

[RahlRB]

You need to backtrack, your heading down a path that doesn't lead to what you want to do. Spooling up another thread is the #1 no no for too many reasons to list. Use a treesharp hook on "Heal" or add some logic to the top of your heal rotation that always returns false so that it will always execute the logic below it.

First, let me start off by saying that I completely understand the pitfalls/hurdles you have to go through when spooling up another thread. I've already tested doing things on another thread and am not having issues with them.

What I want to have happen is basically having 2 CR's running at the same time. The main thread will be running the normal CR for my actual class. Then I want another thread that will be doing using it's own tree to run all of the Pet logic I want. I'll be writing specific rotations for the pets.

The reason I'm looking at doing this is because if I do as you suggest and leave the main logic and the pet logic on the same thread, then I'm slowing down the main CR's casting of spells for the player in order to cast spells for the pet.

What I'm asking for from you is not anything regarding the threading work that I've done. I just want to know about making my own tree and what I should be passing into the Start() method of that tree.

Thanks in advance,
-Rahl

 

[mastahg]

The reason I'm looking at doing this is because if I do as you suggest and leave the main logic and the pet logic on the same thread, then I'm slowing down the main CR's casting of spells for the player in order to cast spells for the pet.

The amount of time that the pet code would take on the main thread is so minuscule that it'd be even hard to measure. Even if you could reliably measure the amount of time that it would take it would still be way way below what any human could reliably execute.
Secondly, if you really cared about performance then you wouldn't even use a behavior tree for the second thread.

You are free to do obtuse things but don't expect support in doing them as its not something I want to proliferate on these forums and its definitely not something I want uploaded and shared.

 

[mastahg]

Sorry i think i sounded a bit harsh. Let me try and explain more why a second thread is bad and will actually degrade performance.

Rb uses two kind of locks a framelock and a codelock. The framelock does two things 1 lock the game engine so that nothing changes during our code 2 allow any code that needs to get injected to be run immediately. The codelock is used by any function that injects code to prevent two api calls from trampling each other.
Without a framelock any functions you call will take much longer to execute to completion. This delay will slow down the main thread due to the code lock. If you were to use a framelock to speed up the api calls you would then be slowing down the main thread as it would only be able to run every other frame. So you can see that running another thread would not accomplish your goal of not slowing down the main thread.

I'm on my phone at the doctors office atm. I'll try to clean this up a bit when i get home

 

[ExMatt]

I think the issue here is not that you need a new thread, but that you need to try to run the pet action and player action before returning each time, not one or the other. If you want it to be perfect, you will likely need to add in some custom components that are not used in a standard combat routine.

 

[RahlRB]

First, I'd just like to say thank you Mastahg for the clarification. Since RB is using a codelock, that makes complete sense as to why doing Pet logic on another thread wouldn't be any benefit.

I think the issue here is not that you need a new thread, but that you need to try to run the pet action and player action before returning each time, not one or the other. If you want it to be perfect, you will likely need to add in some custom components that are not used in a standard combat routine.

ExMatt,

The basic gist of what I wanted to have happen is Player logic happening on Thread "A" making calls to the actionmanager and Pet logic happening on Thread "B" making calls to the actionmanager. Since RB runs inside a lock on any calls that inject anything into the game, I can never achieve simultaneous calls to the actionmanager from both threads. The lock would prevent Thread "A" from starting until Thread "B" was done and vice versa.

It was a good thought to try and separate the different calls I think, but with the way RB is designed to work, I have to agree with Mastahg that all Pet logic should just be at the top of your logic tree.

Thanks again to Mastahg and ExMatt both for taking the time to think about my little idea.
-Rahl