How would I make a capture point on mvm?

[Printed Paper]

I'm making an mvm map where robots cap a point and an extra bomb spawns. I want that extra bomb to be removed after each round, same with the point. This is somewhat like mannhattan, but with a bomb instead of a gate. I have the func_nav_prerequisite stuff set up, so no worries on there.

 

[Da Spud Lord]

Capture points in MvM are set up the same way they are in a normal game. Set up a CP the same way you would for A/D and add logic to do whatever you want to happen when it is captured (in this case, enable a second item_teamflag). Remember to reset it between waves (unless you don't want it to reset between waves). Look at the logic for other maps if you're getting stuck somewhere. (Note that some maps, including mvm_mannhattan, use an entity called trigger_timer_door instead of trigger_capture_area; trigger_timer_door functions the exact same as trigger_capture_area, except its capture progress is linked to a door. If you don't need the cap progress to be tied to a door entity, the two trigger entities are effectively interchangeable.)

 

[Printed Paper]

I got it to work, but now I want the gatebots to stop staying on the point and go for the bomb after it is already captured like regular bots.

 

[Da Spud Lord]

Alright, this is where things get mildly complicated. I am going to assume you already know popfile syntax and how to create and define a robot within a population file.

Most robots only ever have one "state". They only have one set of attributes, one set of weapons/items, and one objective that never changes throughout that bot's lifetime. Gatebots are special, in that they actually have two sets of all of these that they can switch between. We define these "states" within an EventChangeAttributes block of a TFBot or template. See the following popfile code:

    T_TFGateBot_Scout_Melee   // Template taken from robot_gatebot.pop, a Valve-made robot template file, comments added by me.
     {
       Class Scout // "Name", "Class", "Health", "ClassIcon", and "Scale" all have to be defined outside of the EventChangeAttributes block; those attributes cannot be changed. Everything else, INCLUDING stuff you don't actually intend on changing, still needs to be included within EventChangeAttributes.

       EventChangeAttributes // Within here, we can define the different "states" that this bot can have. Only one of these can be active at a time.
       {
         Default // This set of attributes is used before any gate(s) have been captured, to tell the bot to go capture the gate. As the name specifies, it is also the default state.
         {
           Tag bot_gatebot           // This tag indicates that this bot is a gatebot. This is used by map entities to filter for gatebots, such as in func_nav_prerequisites. filter_tf_bot_has_tag can be used to filter by a bot's tag for any entity that does not natively support tag filtering.
           Tag nav_prefer_gate1_flank     // All Valve templates include this extra tag, which is referenced by func_nav_avoid entities to force gatebots towards the gate. I'm not sure why they didn't just reference the bot_gatebot tag; in my own map mvm_cargoship, which also has gatebots, I found this tag to be unnecessary.
           BehaviorModifiers push       // Tells the bot to make a beeline for its objective. Unless otherwise overridden by a func_nav_prerequisite entity, it will run towards and hang around the bomb hatch.
           Attributes IgnoreFlag       // Tells the bot to not chase after the flag.

           Item "MvM GateBot Light Scout"   // This is the glowy hat worn by gatebots to allow players to visually distinguish them from normal bomb-carrying robots.
           Skill Normal           // Although these attributes don't change, we still have to define them within each of the robot's "states".
           WeaponRestrictions MeleeOnly
           ItemAttributes
           {
             ItemName "TF_WEAPON_SCATTERGUN"
             "damage penalty" 0.5
           }
         }
         RevertGateBotsBehavior // This set of attributes is used after all gates are captured, to tell the bot to be a normal bot and try to deliver the bomb.
         {
           // Notice that the bot_gatebot tag, the BehaviorModifier, and IgnoreFlag are all gone. Those were the things causing the bot to attempt to capture gates; with those gone, the bot will now attempt to deliver the bomb. No extra stuff is necessary to make the bot go after the bomb, since that is the default objective for all bots.
           
           Item "MvM GateBot Light Scout"
           ItemAttributes // Gatebots keep their light hat, but the light turns off to indicate their reversion to normal behavior. The turned off light is simply another style of the hat; we override it with this.
           {
             ItemName "MvM GateBot Light Scout"
             "item style override" 1
           }
           ItemAttributes
           {
             ItemName "TF_WEAPON_SCATTERGUN"
             "damage penalty" 0.5
           }
           Skill Normal // Although these attributes don't change, we still have to define them within each of the robot's "states".
           WeaponRestrictions MeleeOnly
         }
       }
     }

However, the robots will not change state automatically. We need to tell them to switch states, which is accomplished via a point_populator_interface entity. point_populator_interface has two inputs for changing the attributes of bots: "ChangeBotAttributes" and "ChangeDefaultEventAttributes". (Usually we use these inputs together; I'm not sure what the exact difference is, although if I had to guess, ChangeBotAttributes sets the attributes of already spawned bots, while ChangeDefaultEventAttributes sets the attributes of bots spawned in the future.) Both of these inputs accept a parameter string, which is the name of the set of attributes to switch to. In our case, these are "Default" and "RevertGateBotsBehavior". Using these is simple: When all gates are captured, fire ChangeBotAttributes and ChangeDefaultEventAttributes with RevertGateBotsBehavior as the parameter. When a wave finishes, fire these inputs again with Default as the parameter to change the bots back to gatebots for the next wave. In the trigger_capture_area or trigger_timer_door for your control point (if you have multiple control points, this should be the last one), in your Outputs tab, you should have the following:

My Output >|Target Entity|Target Input|Parameter|Delay|Only Once
OnCapTeam2|point_populator_interface|ChangeBotAttributes|RevertGateBotsBehavior|0.00|No
OnCapTeam2|point_populator_interface|ChangeDefaultEventAttributes|RevertGateBotsBehavior|0.00|No

And then, in a logic_relay named wave_finished_relay (which, if your mission is set up correctly, will be given the Trigger input at the conclusion of every wave):

My Output >|Target Entity|Target Input|Parameter|Delay|Only Once
OnTrigger|point_populator_interface|ChangeBotAttributes|Default|0.00|No
OnTrigger|point_populator_interface|ChangeDefaultEventAttributes|Default|0.00|No

And that's it! Make sure you test the logic before you release your map. If you have any more questions, don't be afraid to ask.

 

[Printed Paper]

It was actually easier to do because of an online mission generator (mvm.tf), but now i just need to fix this thing.

 

[RevolutionTeam]

I believe the team_control_point_master allows you to change the location.

 

[dan the mann]

It was actually easier to do because of an online mission generator (mvm.tf), but now i just need to fix this thing.

Go to your team_control_point_master and set the custom cap position X to 0.4, it should move the control point icon to the left of the bomb icon.