-
Notifications
You must be signed in to change notification settings - Fork 27
PopFile Mods: TFBot
String specifying path to custom model file.
If specified, then the bot will use the custom model file provided when it spawns, instead of using the normal MvM robot models.
This key is mutually exclusive with UseHumanModel and UseBusterModel and takes priority if multiple keys are present.
Boolean (0 or 1); default: 0
If set to 1, then the bot will use the Sentry Buster model when it spawns, instead of using the regular MvM robot player model for its class.
This key is mutually exclusive with UseHumanModel and takes priority if both keys are present.
Boolean (0 or 1); default: 0
If set to 1, then the bot will use the regular human player models when it spawns, instead of using the MvM robot player models.
Block containing multiple sub-keys; see example below.
Allows the mission author to specify a condition that the bot should spawn with. Multiple AddCond blocks can be specified in a single TFBot spawner.
Each AddCond block must contain an Index or Name value to indicate which condition to add. You can use condition numbers with Index, or symbolic condition names with Name.
Optionally, a Duration value can be specified, to indicate that the condition should only last for the given number of seconds. If no Duration is specified or if it's negative, then the condition will last forever (unless some other part of the game intentionally removes it).
Optionally, a Delay value can be specified, to indicate that the condition shouldn't be added to the bot immediately, but that the game should instead wait for the given number of seconds after the bot spawns before applying the condition. If a Delay is used, the Duration starts as soon as the delay period ends.
Example:
TFBot
{
// ...
// Make the bot be coated in Jarate for the first 30 seconds after spawning
AddCond [$SIGSEGV]
{
Index 24 // <-- here we use a condition number
Duration 30.0 // <-- here we specify a limited duration
}
// Make the bot have the Bonk! Atomic Punch phase effect forever, starting 10 seconds after spawning
AddCond [$SIGSEGV]
{
Name TF_COND_PHASE // <-- here we use a condition name rather than a number
Delay 10.0 // <-- here we specify an initial delay before the condition is applied
}
// Make the bot have the Disciplinary Action speed boost forever, starting immediately
AddCond [$SIGSEGV]
{
Name TF_COND_SPEED_BOOST // <-- we could have alternatively done "Index 32"
// <-- notice that we didn't specify any Duration or Delay settings
}
}
Block containing multiple sub-keys; see example below.
Similar in syntax to the AddCond block, except that instead of applying to the bot itself, the condition is applied to all players that the bot hits with its attacks.
As with the AddCond block, it's required to specify either a condition number with Index or a symbolic condition name with Name.
And as with the AddCond block, a Duration value can optionally be specified; if none is specified or if the value is negative, then the condition will last essentially forever (until some other game mechanic removes it).
Example:
TFBot
{
// ...
// Make any player hit by the bot's attacks start bleeding for 10 seconds
DamageAppliesCond [$SIGSEGV]
{
Name TF_COND_BLEEDING // <-- required: condition name/index
Duration 10.0 // <-- optional: limited duration
}
}
Enumeration with special named values; see below.
This key can be used to override the bot's initial AI action. A maximum of one value can be specified per bot.
Supported values:
-
Action FetchFlag: Makes the bot do the usual "get the flag or escort the flag carrier" type stuff. Useful for making battle-engineer/battle-medic/revolver-spy bots, since those classes are typically forced into their own special AI actions in MvM mode. -
Action PushToCapturePoint: Similar toFetchFlag, except that this makes bots run to the bomb hatch first, as if they hadAttributes Aggressive. -
Action Mobber: A custom AI action developed by me, which makes bots chase down and "mob" enemies while essentially ignoring the objective. Bot spawned with this action will implicitly be given the equivalent ofAttributes IgnoreFlag: their AI will not be compelled to go fetch the flag if it's been on the ground for more than 10 seconds, and if they inadvertently touch the flag for any reason, they will not pick it up.
The game normally makes all MvM engineer bots (regardless of how they were spawned; i.e. even if they don't have an Objective) ignore the flag completely from an AI perspective. So, they won't be compelled to go fetch the flag if it's been on the ground for more than 10 seconds; and if they do happen to pick up the flag for any reason, they will refuse to do any of the flag-delivery-related AI behaviors. This is bad for things like Action FetchFlag, because it means that battle-engineer bots would spawn and then just sit there and refuse to go get the flag or to run the flag in if they have it.
So, I've modified this aspect of the game code such that if an MvM engineer bot is spawned with any of these custom Action values, their AI will not ignore the flag, and will act like any other bot when it comes to flag-related matters. (But of course, if the bot is also manually given Attributes IgnoreFlag or SuppressTimedFetchFlag 1, then it will have partial or full flag ignorance, as you would expect.)
Block containing multiple sub-keys; see example below.
Allows the mission author to specify a render color override for any weapon/cosmetic a bot is given, in a manner essentially identical to how the Color entity input works.
Syntax is very similar to the ItemAttributes block.
Multiple ItemColor blocks (to specify colors for multiple different items) are allowed, just as multiple ItemAttributes blocks are allowed.
Example:
TFBot
{
// ...
// Equip the bots with KGB when spawned
Item "The Killing Gloves of Boxing"
// Make the KGB worn by these bots be black-colored
ItemColor [$SIGSEGV]
{
ItemName "The Killing Gloves of Boxing"
Red 0
Green 0
Blue 0
}
}
Block containing multiple sub-keys; see example below.
Allows the mission author to override the world model of a particular weapon held by the bot.
The Slot value determines the weapon slot that will have its model overridden. Weapon slots can be specified as a slot number or as a slot name, as follows:
- 0: "primary"
- 1: "secondary"
- 2: "melee"
- 3: "utility"
- 4: "building"
- 5: "pda"
- 6: "pda2"
For the more obscure items where you aren't exactly sure what its slot will be (i.e. anything that's not simply a
primary/secondary/melee), look up the item in items_game.txt and check its item_slot value (not its anim_slot value, which is something different).
The Model value is a path to a model file.
The custom model will be automatically precached for you by the mod.
Example:
TFBot
{
// ...
// Make the bot's primary weapon look like a steak, regardless of what it actually is
CustomWeaponModel [$SIGSEGV]
{
Slot 0 // (or: Slot "Primary")
Model "models/weapons/c_models/c_buffalo_steak/c_buffalo_steak.mdl"
}
// Make the bot's melee weapon look like a ham, regardless of what it actually is
CustomWeaponModel [$SIGSEGV]
{
Slot 2 // or: (Slot "Melee")
Model "models/weapons/c_models/c_ham/c_ham.mdl"
}
}
Block containing multiple sub-keys; see example below.
Allows the mission author to specify resistances to particular weapon IDs, in a manner not possible via regular attributes.
The WeaponResist block should contain one or more key-value pairs, where the key is the weapon ID name and the value is a floating-point value indicating the multiplier that should be applied to the damage.
Example:
TFBot
{
// ...
// Make this bot resist 75% of minigun damage just like the MvM tank does
WeaponResist [$SIGSEGV]
{
TF_WEAPON_MINIGUN 0.25
}
}
String specifying path to custom model file.
Allows the mission author to override the model file used for rockets fired by the bot. By default, the model file used (for the stock rocket launcher) is "models/weapons/w_models/w_rocket.mdl".
Only applies to weapons that fire rockets via CTFWeaponBaseGun::FireRocket; that is, weapons which fire TF_PROJECTILE_ROCKET projectiles (e.g. the soldier's rocket launchers, or other weapons with attribute override projectile type set to 2).
String specifying name of custom particle.
Allows the mission author to replace or augment the particle effect used for trails of rockets fired by the bot. By default, the particle called "rockettrail" is used; take a look at this GitHub repository to see ASCII versions of the TF2 particle files if you need assistance finding the name of a particle you want.
If the string given begins with a '~' character, then the default rocket trail particle will be removed first; otherwise, the given particle effect name will simply be added on without first removing the default particle.
As with RocketCustomModel, this only applies to weapons that fire rockets via CTFWeaponBaseGun::FireRocket (the same list of circumstances applies).
Example:
TFBot
{
// ...
// Make this bot's rockets always use the blue crit trail particle INSTEAD OF the regular trail
RocketCustomParticle "~critical_rocket_blue" [$SIGSEGV]
}
TFBot
{
// ...
// Make this bot's rockets use the Monoculus eyeball trail particle IN ADDITION TO the regular trail
RocketCustomParticle "eyeboss_projectile" [$SIGSEGV]
}
Floating-point value; default: 12.0
Causes a bot to emanate a ring-of-fire effect every 0.5 seconds, exactly as a spun-up heavy with the Huo-Long Heater would. Doesn't require the bot to be a heavy or have any minigun for that matter.
The numerical value has the same function as the value of the "ring of fire while aiming" attribute that the Huo-Long Heater uses: it determines the amount of immediate damage done by each burst of fire to the enemies that are within range.
The default value is set to be the same as the value that the Huo-Long Heater uses.
Negative values will disable the effect.
Example:
TFBot
{
// ...
// Give this bot a ring-of-fire effect basically identical to the Huo-Long Heater's
RingOfFire 12.0 [$SIGSEGV]
}
Block containing multiple sub-keys; see example below.
IgnoreDisguisedSpies: boolean (0 or 1); default: 1. Set to 0 to allow the rockets to seek out spies who are disguised.
IgnoreStealthedSpies: boolean (0 or 1); default: 1. Set to 0 to allow the rockets to seek out spies who are cloaked.
RocketSpeed: floating-point; default: 1.0. Determines the speed of the rockets, as a relative multiplier to the default rocket speed of 1100 HU/s. Overrides all other rocket-speed-influencing parameters, such as the "projectile speed increased" or "rocket specialist" attributes.
TurnPower: floating-point; default: 10.0. Set this to higher values to enable the rockets to turn more sharply; set it to negative values to make the rockets turn away from their targets instead of toward them.
MaxAimError: floating-point (between 0.0 and 180.0); default: 90.0. This factor determines how many degrees "off-target" the rocket's aim is allowed to go before it gives up on turning to correct its aim. Setting it to 0.0 will make the tolerance so tight that the rocket will never turn to correct its aim; setting it to 90.0 will allow the rocket to turn as long as it's pointing within 90 degrees of its target ("halfway"); setting it to 180.0 will allow the rocket to turn no matter which direction it's pointing; and values in between will have intermediate results.
Example:
TFBot
{
// ...
HomingRockets [$SIGSEGV]
{
IgnoreDisguisedSpies 1 // <-- don't home in on disguised spies
IgnoreStealthedSpies 1 // <-- don't home in on invisible spies
RocketSpeed 1.80 // <-- make the rockets travel at Direct Hit speed (1980 HU/s)
TurnPower 50.0 // <-- crank up the rockets' turning power to compensate for their high speed
MaxAimError 120.0 // <-- allow the rockets to home in on their target as long as they're pointed within 120 degrees
}
}
Boolean (0 or 1); default: 0
If set to 1, then the bot's AI will use the same threat prioritization logic that bots with WeaponRestrictions MeleeOnly would use, regardless of what WeaponRestrictions the bot was or was not given and what weapon(s) the bot does or does not have.
Ordinarily, bots will take a number of factors into consideration when they are aware of multiple threats and need to choose one of them to shoot at. But if the bot has WeaponRestrictions MeleeOnly (or if this parameter is enabled), then the bot will only take into account which threat is closer and will skip the rest of the criteria; that is, the bot will simply target the closest threat. (However, note that bots at Hard skill level will still have a 50% chance to actually target the healer of the selected threat, if any; and bots at Expert skill will have a 100% chance to do so. That extra set of logic is applied after all the other considerations and is not skipped when WeaponRestrictions MeleeOnly, or this parameter, is in effect.)
Some of the things that bots normally take into consideration when comparing threats include:
- Prioritizing closer threats
- Prioritizing sentries over players
- If both threats are an "immediate threat" (is visible with a clear line-of-sight; and is either closer than 500 HU to the bot, is firing at the bot, is a sniper and is aiming roughly toward the bot, or is a medic or engineer and the bot is at Hard or Expert skill):
- Prioritizing spies over non-spies
- Prioritizing threats that are firing at the bot
See the "Strategy: threat prioritization" section of my TFBot skill level guide for some additional information.
Note that spy bots have a special threat prioritization override that they use when going in for a backstab; and sniper bots have a special threat prioritization override that they use in MvM when tf_mvm_bot_sniper_target_by_dps is enabled (and it is enabled by default). These overrides usually take precedence over the default threat prioritization logic, and the overrides themselves are not affected by this parameter. However, there are some cases where the overrides will fall back to the default logic, and in those cases, the default prioritization is still affected by this parameter.
Boolean (0 or 1); default: 0
If set to 1, then the bot AI's typical desire to stop what it's doing and go pick up the flag if it's been on the ground for 10+ seconds will be suppressed, and the bot will instead simply continue doing whatever it's doing. (In slightly more technical terms, the CTFBotScenarioMonitor AI will be prevented from doing a SuspendFor transition to CTFBotFetchFlag, which is the behavior that makes the bot stop what it's currently doing and go chase down the dropped flag.)
Note that bots with Attributes IgnoreFlag, and bots with any Objective, are already exempt from the 10-second-automatic-switch-to-FetchFlag logic, and so those bots do not need this parameter and will be totally unaffected by it anyway.
Keep in mind that Attributes IgnoreFlag does all three of the following things:
- Suppresses the automatic AI switch to
FetchFlagbehavior after the flag has been on the ground for more than 10 seconds - Prevents the bot from being able to pick up the flag even if it unintentionally touches it
- Prevents the bot from switching to any flag-related AI behaviors if it does happen to pick up the flag (it will ignore the fact that it has the flag and will continue doing whatever it was previously doing)
SuppressTimedFetchFlag only does the first of the three things listed above. So in other words: a bot with SuppressTimedFetchFlag 1 won't be compelled to go get the flag if it's been on the ground for 10+ seconds; but it can pick up the flag by accident (by touching it); and if it does pick up the flag by accident, it will switch to the typical AI behaviors for delivering the flag to its destination.
Boolean (0 or 1); default: 0
If set to 1, then the bot will spawn a dropped weapon (Gun Mettle style) when killed, which may be picked up by other players. This feature undoubtably has various buggy implications, so use it with discretion.