Test spawns for Waypoint tests
From Bots-United Wiki
Using a new spawn for testing of paths etc.
Contents[hide] |
Non-test-spawn methods of waypoint testing
The first 3 methods are only briefly described here and all involve changes to the FritzBot nav and possibly aiscript files (Don't forget to backup all the files you modify)
Testing using Roam Actions
(Method 1) add a roam action (#12) to increase the likelihood of bots passing that way. Just use the built in waypoint editor which by now you should have learned. Save the nav file (\node_save) and restart ET.
Testing using Altroam Actions
(Method 2) Add an Altroam action instead of a roam and add/edit a route at the spawn such that the bot is directed here (similar to route testing). Read the wiki for more on The_Route_System.
Testing using radical waypoint surgery
(Method 3) OK so method 1 and 2 didn't seem to work and you suspect other things in the map are interfering. Well you can delete all the actions in the map nav file using \action_reset (you had better backup your files first!). Then place just one roam action near what path you want to test. The action must be goalnum 0, active 1 and should be action_group 0. Then node_save, restart, kill all the bots, add the bot you want to test with and spectate. If the bot complains about no goal it may mean it can't find a path to the action or you didn't set the action correctly. You may also have to add a roam in-between if the distance is too great.
Now the problem with the first 3 methods is all that backing up and extracting and deleting and modifications to the navs. You end up testing on something that you may lose faith as representing a test of the original waypoints. So that leaves...
Using the test spawn method
(Method 4) This method uses the fact that you can script in new spawn points anywhere in the map inside the mapname.script file. You place one spawn (possibly more) for a given team near a node of a path etc that you are evaluating/tweaking. This can be especially useful when testing death-defying jumps and you need to count the likelihood of sucess over multiple jumps. This is the only method of the four that may have application with some other ET bot mods.
Finding and extracting the script file
Now the waypointer may or may not have modified this file so you have to check for it in both the FritzBot waypoint files as well as the original map file in \etmain. If FritzBot finds a mapname.script inside \fritzbot\maps then it uses that one. So first check \fritzbot\maps and check the same path inside any pk3 files under \fritzbot. If no script file is found there that means fritzbot is using the original ET file directories \etmain\maps. In the former case if you find the file in a \fritzbot pk3 file, extract it to \fritzbot\maps and delete it from the pk3 so fritzbot won't use the old one. If the file only exists in the pk3 under \etmain then just extract a copy to \fritzbot\maps.
For the purposes of this document it is assumed that you can find your way around inside a script file. You should associate the .script file type with a text editor like notepad or better.
Placing the new test spawn
You need to add the some of following code snippets (in the boxes). Start with one of the first two (or both), adding them at the top of the spawn section in the game_manager. (i.e. after the 4 lines of " game_manger { spawn { " ) or;
game_manger //at the top of the file after any "//" prefixed comments { spawn {
To add an axis spawn location, add this code:
// BEGIN TEST SPAWN create { scriptName "axis_test_obj" classname "team_WOLF_objective" targetname "axis_test_obj" origin "LOCATION2 5" // z = CC_FILTER_AXIS(1) | CC_FILTER_SPAWNS(4) // spawnflags 1 // not TEAM_AXIS(1) spawnflags 1 // (1=DEFAULT_AXIS, 2=DEFAULT_ALLIES) // DEFAULT_AXIS - This spawn region belongs to the Axis at the start of the map // DEFAULT_ALLIES - This spawn region belongs to the Allies at the start of the map } create { scriptName "axis_test_spawn1" classname "team_CTF_redspawn" targetname "axis_test_spawn" origin "LOCATION3" //angle "360" //optional // spawnflags 1 // not TEAM_AXIS(1) spawnflags 2 // bit1=INVULNERABLE bit2=STARTACTIVE // INVULNERABE player always spawn invulnerable, so the usage of this flag // is unknown. The official ET maps seem to always set it. // STARTACTIVE this spawn is active at map start } // END TEST SPAWN
OR Add the following code after " game_manger{ spawn{ " to add an allies spawn
// BEGIN TEST SPAWN create { scriptName "allies_test_obj" classname "team_WOLF_objective" targetname "allies_test_obj" origin "LOCATION2 6" // z = CC_FILTER_ALLIES(2) | CC_FILTER_SPAWNS(4) spawnflags 2 //(1=DEFAULT_AXIS, 2=DEFAULT_ALLIES) } create { scriptName "allies_test_spawn1" classname "team_CTF_bluespawn" targetname "allies_test_spawn" origin "LOCATION3" //angle "360" spawnflags 2 // bit1=INVULNERABLE bit2=STARTACTIVE } // END TEST SPAWN
NOTE: YOU MUST REPLACE LOCATION2 and LOCATION3 with real location co-ordinates!!! To find your current co-ordinates use /viewpos in the console. It returns the values of (x y z) and the angle in the x-y plane. The angle parameter is optional (default 0). The "origin" of the team_WOLF_objective(s) in the code above (LOCATION2) should be set to be near the x and y position of the test spawn pad (team_CTF_redspawn for Axis or team_CTF_bluespawn for Allies). This origin does not use the third parameter for position since it does not really need a z-axis parameter. Accordingly for the team_WOLF_objective the third parameter is used instead for bitflags. However in the case of the spawn pads' team_CTF_redspawn/team_CTF_bluespawn origin (LOCATION3), all 3 co-ordinates (x y z) are needed to uniquely identify the individual spawn locations and must be used. (the z value being equal or a little greater than that seen with /viewpos so that you don't spawn inside the floor!)
Supporting the new test spawn
Next you need to add a script_block outside the game_manager script block. A good place is to put it immediately after the closing brace of the game_manger script block. (if you can't figure out what is the closing brace then you can also put the script at the end of the file.)
After the End of game_manager section
Add these scripts for the axis...
//BEGIN TEST SPAWN axis_test_obj { spawn { set { //these have to be set inside the spawn{} function, not create{} //The description will be used by setautospawn description "Axis test spawn" message "Axis test spawn" } wait 50 setstate axis_test_obj invisible setstate axis_test_spawn invisible } trigger on { setstate axis_test_obj default setstate axis_test_spawn default } trigger off { setstate axis_test_obj invisible setstate axis_test_spawn invisible } } // END TEST SPAWN
And for Allies...
// BEGIN TEST SPAWN allies_test_obj { spawn { set { //these have to be set inside the spawn{} function, not create{} //The description will be used by setautospawn description "Allies test spawn" message "Allies test spawn" } wait 50 setstate allies_test_obj invisible setstate allies_test_spawn invisible } trigger on { setstate allies_test_obj default setstate allies_test_spawn default } trigger off { setstate allies_test_obj invisible setstate allies_test_spawn invisible } } // END TEST SPAWN
Triggering the new test spawn
NOW THE THE DIFFICULT PART... To invoke the test spawn find in the script file all instances of setautospawn. The command setautospawn uses the form:
setautospawn "DESC" team_number
where "DESC" is the team_WOLF_objective description field (quotes needed). And where team_number is 0 for axis and 1 for allies. The easiest place to put the test spawn setautospawn enable code is in the game_manger spawn function after any existing setautospawn commands (typically coming below the list of wm_objective_status presets and the script accum variable pre-sets and a wait instruction). If no setautospawn commands exist in the file (say a map that never changes the spawns), then putting the enable code in the game_manager spawn function as just described is correct.
//setautospawn "Forward Spawn" 1 //Uses name from description field of team_WOLF_objective // BEGIN TEST SPAWN //bani, TomTom trigger allies_test_obj on setautospawn "Allies test spawn" 1 //allied bots should spawn here when built -crapshoot, TomTom trigger axis_test_obj on setautospawn "Axis test spawn" 0 // END TEST SPAWN
And should you need to spawn someplace else as a matter of the normal course in the map play then...
// BEGIN TEST SPAWN trigger allies_test_obj off setautospawn "WHATEVER" 1 //WHATEVER being the new spawn description as discussed above. // END TEST SPAWN //... // BEGIN TEST SPAWN trigger axis_test_obj off setautospawn "WHATEVER" 0 //WHATEVER being the new spawn description as discussed above. // END TEST SPAWN
NOTE: the location of the setautospawn may not be the point in the script code that the described spawn is invoked. Some coding techniques set the next spawn with the setautospawn instruction but complete the transfer much later with a script_block. For an example look at this dm_hillb2.script file.
WARNING!: One of the side effects is that trigger_objective_info numbers of other entities in the map will likely be shifted. The amount that the toi's will shift is related to (but not necessarily equal to) the number of entities added to the spawn section of the script file. So you should re-check the entities tied to actions and correct the action_ents (flag nodes too). Now for the purpose of just a narrow bit of testing that may not be necessary if you are only interested in path tests. But you may notice engineers re-dynamite-ing blown targets etc. Worst case if ET crashes when you un-pause the bots then you MUST correct the entnums in the map. And obviously if in releasing waypoints, you choose to leave the spawn objects in the script file (even if not activated), THEN PLEASE REMEMBER TO CORRECT THE ENTNUMS.
CAVEATS
- Since you pre-set the bot to spawn away from its normal start point, it did not receive any instructions from any spawn routes. So route testing is something else you should do separately.
- Since you started the bot near to the point of interest this test does not prove that the node connections leading to the test spawn are correct only that those leading away from the test spawn are.
- Actions in the script file that normally move the spawn may be affected by the new test spawn depending on how you code the triggers.
- FritzBot ET may exhibit a class bias when doing a split spawn, i.e. test/regular spawns (uncertain, but empirical observations suggest a bias).
- The position of the team_WOLF_objective may also influence which spawns of the previous regular spawn area get used for the other bots (uncertain).
- You may or may not be able to perform testing without correcting the entnums in the nav file. So it is best to have backed up the nav file just in case.
- And Don't forget to revert the script file and any other changes (nav file if changed) when you are done.