-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in BTree Selector #72
Comments
Are you sure that this change does not break sequence? |
No I'm not sure, i haven't tested it On July 29, 2016 11:13:02 AM GMT+02:00, davebaol notifications@github.com wrote:
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
It looks like it even fixes a bug in sequence. I just made a test with a This AIScript throws a StackOverflow on the same code. With the new Code root I also might have found a mistake in the BehaviorTreeViewer. On 29.07.2016 11:13, davebaol wrote:
|
Good catch! |
I'm sorry to bring it up again. I think something broke when fixing this. A Sequence with a guarded Task will fail, if the guard fails. I'm not sure, but I think its not how its supposed to be.
I suppose the following behaviour of a guard in a sequence/selector: |
No, when the guard fails the whole task, made up of the guard and the guarded task, fails.
|
I've just stumbled across this problem. I think it comes down to the definition of whether a task can be considered a failure when it didn't even run. In my use case I have a sequence of things to do (namely to shoot at a player), and there is this line:
With the current behavior such "optionals" would have to be wrapped into an alwaysSucceed, throwing away the result of ReloadWeaponAndWait or need a custom Sequence Node. I can see that this would break every existing behavior, but I wonder what the best approach would be for such conditionals part of a sequence? Another example would be example 2:
This could be simplified to
Which would be less verbose and much more intuitive. Edit: And in the new case the old behavior could be replicated by explicitly specifying the guard, which to me seems more clear/intuitive. See
That way e.g. someone only enters the room when the door could be unlocked, just like the regular behavior would've been and it's obvious now that "doorLocked?" is a task in the sequence which has to be fulfilled. |
Issue details
The guard in a selector is not handed correctly. The guard is checked and if it fails the run method is called anyway. In SingleRunningChildBranch line 88 is an else missing. The run method is called later on the child that succeeded. This child is called twice.
I could only see it in the debugger, when executing step by step. I used to set a breakpoint in LeafTask:42, this gets called twice for the last child.
Reproduction steps/code
Version of gdx-ai and/or relevant dependencies
gdx-ai1.8.0 and below
Solution
I solved it myself with the following code:
SingleRunningChildBranch: Line 82
instead of
The text was updated successfully, but these errors were encountered: