Skip to content
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

add attack.bt #2962

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

add attack.bt #2962

wants to merge 2 commits into from

Conversation

sweet235
Copy link
Contributor

@sweet235 sweet235 commented Mar 31, 2024

This is the fifth bot behavior players can use on my server. It makes a bot attack the enemy base.

For reference, I use this on my server:

set g_tacticBehaviors "default, defend, attack, follow, stay-here"

This is similar to reckless.bt, but more elaborate. I do not dare to change reckless.bt. It is the simplest interesting example behavior, and was the first behavior I studied while learning the behavior tree language.

// reset the suicide timer
decorator return( STATUS_FAILURE )
{
action resetMyTimer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suicide timer is stuckTime, not myTimer. "My timer" is not used anywhere in this BT so this seems pointless.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the general purpose timer. It is not set or read in C++. But default.bt uses it to wait for 20 seconds before suiciding to spawn as builder. If you change a bot from attack.bt to default.bt, it might suicide immediately if this timer has not been reset in a while.

We should do this in all behavior intented to be available to regular users.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh so old state is not cleared when switching behaviors? We should fix that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not think about this problem when I added that timer. All I cared about was a timer independent of the paths taken in the behavior tree (decorator timer is closely tied to these paths and success/fail).

We could reset it on behavior changes. Indeed, we should reset bot targets on behavior change too. But what if someone wants to use that timer in an "inverted" way? Like setting it when some positive condition is met, lets say when alertedToEnemy. And later query that time to find out how long a bot has not sensed an enemy. Automatic reset would break this instead.

Copy link
Contributor

@slipher slipher Apr 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But what if someone wants to use that timer in an "inverted" way? Like setting it when some positive condition is met, lets say when alertedToEnemy. And later query that time to find out how long a bot has not sensed an enemy. Automatic reset would break this instead.

I guess the appropriate way to reset myTimer is to set it to the time that the behavior tree was set, rather than 0. Then it would behave the most similarly to as if the game had just started.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opened #2971 to fix this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the appropriate way to reset myTimer is to set it to the time that the behavior tree was set, rather than 0. Then it would behave the most similarly to as if the game had just started.

That seems to be the most sensible choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants