Overriding _tick in BTCondition doesn't make sense

[alijaya]

Problem statement

For now, if we want to create BTCondition, we need to override the _tick function even if we don't use delta and we will only return SUCCESS or FAILURE, never RUNNING status.

Proposed solution

It would be great if the _tick function has already wrap another function that return boolean value.
So if in BTCondition has something like this:

func _condition() -> bool:
  return true
func _tick(_delta: float) -> Status:
  if _condition(): return SUCCESS
  else: return FAILURE

So in the subclass we could only override the _condition

func _condition():
  return something > another_thing

Alternatives

[limbonaut]

The way it's done right now is idiomatic in behavior trees. Each task is required to override the _tick method. Doing it in any other way would require additional documentation and would probably cause even more confusion, but this time among those who already accustomed to BTs. It's also expected that tasks would perform their work in the _tick method. And I'm not sure if both ways can be reliably supported at the same time.
We could introduce a separate task, let's say BTSimpleCondition, which would have the proposed solution and inversion #169 baked into it. That would also preserve backward compatibility, as it wouldn't break things for existing users.

[alijaya]

The way it's done right now is idiomatic in behavior trees. Each task is required to override the _tick method. Doing it in any other way would require additional documentation and would probably cause even more confusion, but this time among those who already accustomed to BTs. It's also expected that tasks would perform their work in the _tick method. And I'm not sure if both ways can be reliably supported at the same time. We could introduce a separate task, let's say BTSimpleCondition, which would have the proposed solution and inversion #169 baked into it. That would also preserve backward compatibility, as it wouldn't break things for existing users.

Ah yes, subclass from BTCondition would make better sense for it. :D