Testing your mvm map using a testing popfile

UKCS-Alias

Mann vs Machine... or... Mapper vs Meta?
aa
Sep 8, 2008
1,264
816
A guide to test how you can optimaly test your mvm map for flaws before you are even going to deploy them. A few things that generaly is a problem is bots following the random paths correctly, or tanks spawning at the hatch. And this guide shows some easy tricks you can use for it. In some cases even being beneficial for popfile makers which can get new options with it.

But in short it comes down to:
Use a testing popfile with very basic tests! Even if that popfile would be 20 waves long. It can help you test your map, and help the popfile maker!

Multiple path testing
Where many maps can have up to 4 paths which are randomly selected, you want to be sure each of them works correctly. This is done by having 4 relay (where the default one is usualy named wave_prepare_relay these are for example wave_prepare_relay_left or wave_prepare_relay_3). These function to bypass the logic_case that randomly selects a wave (and it should be possible to even trigger the logic_case with a certain value). And when performed correctly they obviously become reachable to the popfile maker aswel. Mannhattan uses this system also to force a longer path for giant scouts allowing you to intercept them just before the hatch.

Now for older entity work there can be a problem since this logic is applied using a wave_finished_relay. But even for these there is still an option since you can move many of the behaviour that sets a path to the wave_prepare_relay. However, if someone is making your popfile, he must add the InitWaveOutput relay to the popfile each wave. Whenever moving such relay breaks it usualy is down to mistimings and you will probably have to delay the path selecting relay by 0.1 second. Dont worry about this being visible, 0.1 second is a very short margin and often unnoticed unless people know to look for it (which is not a problem).

To explain the existing relay triggers:
Code:
     StartWaveOutput
     {
       Target wave_start_relay
       Action Trigger
     }
This relay is activated upon the wave start. It for example turns off the arrows.
Code:
     InitWaveOutput
     {
       Target wave_prepare_relay
       Action Trigger
     }
This relay decides the pathing for bots and prepares entities on the map to correctly display the pathing. This is also the most important relay for a multipath map since here is where you should decide which path to take.
Code:
     DoneOutput
     {
       Target wave_finished_relay
       Action Trigger
     }
This resets the entities to the basic state. For example resetting the control points, and closing gates that open when a bot reached far enough.

By having 4 relays for 4 paths you can do 4 waves with each wave having 1 of these relays. all having only 10 scouts so you can quickly finish it. For the randomness testing you can do another 4 waves with just 1 scout (the arrows should show enough since the nav). And this can be tested in just a few minutes.

Testing the tanks
Now, for tanks the same problem can show up where a tank spawns at the hatch. Now in some cases this is due to the popfile maker taking a wrong starting point. but in some cases you can actualy break it in the map itself.
By adding a wave for each tank (which only has 5k hp), you can extend your testing popfile to also test the tanks.

Testing your popfile
Its very important to test your popfile every release, you can break things very fast and in mvm this can break the mission and cause it to deadlock (bots might get into a state where they keep walking a circle - and yes, this is realy possible as i had this before in skullcove where they dropped down from the bridge onto an avoid and then walked backward to take that same path again!).

Quickly jumping to a certain part of the popfile:
sv_cheats 1
tf_mvm_jump_to_wave #

And just write down the wave numbers for each set of tests. for example this could be:
1-4. pathing starting at the most left
5-8. testing the random paths
9-10. tanks
11. gatebot logic
12. testing bomb resets
13. testing custom bot template x
14. testing custom bot template y
15. testing custom bot template z
16. testing custom medic template a

This can allow you to skip to that specific wave. It has happened that the tf_mvm_jump_to_wave has broken in the past. So if it doesnt work, this could be the case. But do note that if your popfile is corrupted it might not work because of that (although most of the time you would get the wave 0 situation instead).

And always hand over this information to the popfile maker! Even if you dont want him to use the 4 specific waves in the final version. He can aim towards testing a specific region on the map where for example a giant heavy+giant medic combo appeared overpowered.

Anyway, have fun testing!
Also, if you are finding a problem at making something work in your map, do consider making a wave to specificly test wether that bug is fixed
 

Erk

erk
aa
Aug 6, 2016
433
1,098
Just a bit of a random tidbit I found useful while mvm-ing.

Using the command nb_blind 1 in-game will make it so that robots dont see you, and you can then observe them in their natural environment.