Zero Angel 's site Battlezone Realm http://zeroangel.overminddl1.com/index.php
PACK EXPLORER LINK WITH EXPLANATIONS http://www.leinensoft.com/bz2/pakexplorer.htm
THE AIP EDITOR TUTORIAL http://www.starfleetplatoon.com/walkthroughs/aipeditor/overview.htm
UPGRADING G66 TUTORIAL http://www.starfleetplatoon.com/walkthroughs/g66v2/upgrading_g66v2.htm
TGDB SITE GOOD TURORIAL http://www.tgdb.net/pc/faq/5132/Battlezone_2-page1.html
FISHDOT XSI http://www.bz2md.com/fishdotxsi/
Battlezone II Map editor and Console commands comming soon
Battlezone Command Community http://www.bzcommand.com/forum/index.php?page=Bz2_Information
CREATE A BZN FILE FOR YOUR DLL
1. run 'bzone /win /noscript /edit isdf01.bzn'
2. press ctrl-e to enter the editor
3. set the dll name to btest.dll under the 'Path' tab
4. press ctrl-e to return to the sim
5. press ctrl-s and save into addon\btest.bzn
- Brad Pickering
MAKING TRN FILE
The .TRN File
Lizard's BZ2 Mapmaking Tutorials
Tutorial 7 : A very useful little file
The .TRN file is a handy file that allows you to change a vast array of the parameters for your map, most of these settings are also available through the console, so I will only be covering a few of the uses of the .TRN in this particular tutorial.Editing BZ II .TRN files is incredibly easy because they are text based, they can be edited by using a normal text editor such as notepad. This also means that you can copy sections from one .TRN file and paste them into another.
Note:
Some .TRN files can be incredibly complex, such as the one pictured on the left, taken from my IA map "Cornered". The truth is that most map makers only tend to edit a couple of sections of this file.
The .TRN file for the map featured in this set of tutorials is shown to the left, as you can see this one is far simpler than the one above. The two main aspects of the .TRN file that you'll need to change are :
1) The width and depth settings in the [Size] section of the .TRN, these settings control the size of the play area of your map. The values increase in increments of 1024, from 1024 x 1024 (small), to 7168 x 7168 (huge). If you edit these values you will have to delete the .TER and .WAT files for the map in order for the changes to take place, DON'T attempt this on maps where you've already started modelling the terrain as all terrain data will be lost, this should be done before work on the map has started.
2) The [Texture] section of the .TRN is where you can specify which textures you wish to use on your map, you can use a maximum of 15 different textures. Simply replace the texture names in the quotes with the names of the textures you wish to use.
AIP - Artificial Intelligence Plan v1.4
INTRO
This document details the AIP files and their possible use. Brad Pickering has been generous in answering my questions concerning the AIP files. You will see a few things that were "ify" before, now clarified. Brad is willing to help more, so keep an eye on the document version.
AIP stands for Artifical Intelligence Plan. These plan files tell the AI what to do during Instant Action and MPI missions. They can be found by looking in the Battlezone II\Data\Missions\Instant directory, or by extracting *.AIP from the DATA.PAK file. The AIP's in DATA.PAK are for the SP missions.
There are 18 stock AIP files include with the game. 9 files are for the ISDF, 8 are for the Scions, and one is called Iceberg.aip. The contents of these files go from simple to complex.
examples:
scioninst0.aip = get started
scioninst1-3.aip = taking pools, holding them, building defenses and the base
scioninsta.aip = assault on your holdings, utilizes rush tactics
scioninstl.aip = late in the game, utilizes rush tactics
scioninsts.aip = when AI is under seige
To use the files as they are indicated above, you can create the AIP for each stage of your mission, and then just include them with the mission. They are placed in the directory BattlzoneII\Data\Missions\Instant. They should be named the same as your map, with the given pointer (0-4, a, l, or s) for each phase. The stock DLL's will utilize them automatically based on the pointers.
AIP FORMAT
-------------
My purpose in the first part of this document is to familiarize you with the format of an AIP file and some of the possibilities available with them. There will be as complete a list of these operations as I can compile with the canned AIP files, including the SP files, towards the end of this document.
HEADERS
Each file contains several headers, including [Start], [Match], and [Plan #] (# = integer, beginning at one and going up). Each is listed below with information regarding it's use.
[Cheat] - Optional header used for IA and MPI strat games that gives the AI a scrap boost.
This is similar to "scrapCount" used in [Start] header, but runs in a loop!
examples -
[Cheat]
moneyAmount = 400 // Give AI 400 units of scrap.
moneyDelay = 300 // moneyAmount is added to AI every 300 seconds.
NOTE: There are no more "cheats" :-(
[Start] - Normally the first header of each AIP file; used to set scrap count and declare unit classes for scavs and constructors appropriate to the AI race.
examples -
[Start] // Sets scrap to 40 units and declares Scion scav and constructor class
scrapCount = 40
scavClass = "fvscav"
consClass = "fvcons"
[Match] - The second header used in AIP files is used to match friendly units to
enemy target units.
examples -
[Match]
targetType1= "ivscout" // Scion Scout matched to ISDF Scout
attackType1_1 = "fvscout"
targetType2 = "ivtank" // Scion Warrior matched to ISDF Sabre
attackType2_1 = "fvtank"
targetType3 = "ivtank" // 2 Scion Sentries matched to ISDF Sabre
attackType3_1 = "fvsent"
attackType3_2 = "fvsent"
[PlanX] - The third header type used in AIP files is used to initiate unit build
orders, scav deployment, base building orders, attacks, etc.
There can be around 50 [PlanX]'s per AIP.
examples -
[Plan1] // Initiates order for scav to find scrap pool and deploy
planType = "CollectPool"
planPriority = 500
buildIfNoIdle = 1
[Plan2] // Initiates order for scavs to collect scrap lying around
planType = "CollectField"
planPriority = 490
buildIfNoIdle = 1
maxTries = 3
[Plan3] // Initiates order to build A Scion Kiln
planCondition="NotExists"
planConditionClass="fbforg"
planConditionCount=1
planType = "BaseBuildMinimums"
planPriority = 480
buildType1= "fbkiln"
buildCount1=1
[Plan4] // Initiates order to upgrade Scion Kiln
planCondition="NotExists"
planConditionClass="fbforg"
planConditionCount=1
planType = "Upgrade"
planPriority = 470
unitType = "fbkiln"
Additionally, you can name [PlanX]'s rather than number them. This is done by adding "plans" variables in the start section. This would make it easier to determine exactly what each plan was intended for, but may require more pre-planning to implement properly. There are reports that this method is not very effective, but I will leave the info here. (The info came from Brad P.)
examples -
[Start] // example of plan variables in start section
scrapCount = 40
scavClass = "fvscav"
consClass = "fvcons"
plans1 = "Basebuild"
plans2 = "Collect"
plans3 = "Attack1"
plans4 = "Unitbuild"
plans5 = "Attack2"
plans6 = "Upgrade"
[Match] // unit matches
Setup unit matches here
[Basebuild] // first [PlanX]; using variables from [Start] section instead of plan #'s
(A baseBuildMinimums Goal)
[Collect] // second [PlanX]
(A collect goal)
[Attack1] // third [PlanX]
(An attacker goal)
[Unitbuild] // fourth [PlanX]
(A buildMinimums goal)
[Upgrade] // fifth [PlanX]
(An Upgrade goal)
[Attack2] // sixth [PlanX]
(An attacker goal)
Ok, those are some simple examples of the contents of an AIP file. Now we will try to dissect each header type and attempt to explain it's function.
[Start]
[Start]
scrapCount = 40 // Sets scrap for AI to 40 units
scavClass = "fvscav" // Declares Class Scion Scavanger
consClass = "fvcons" // Declares Class Scion Constructor
Almost all of the canned AIP files have this identical [Start] section, although the ODF's referenced will be different depending on which side you are building the AIP to control, Scions or ISDF. A few of the files do not include the ScrapCount line, only the two Class lines. I believe these files are intended for use at later stages of a mission, after a basic base is already built. In these cases, the AI would NOT be given extra scrap at AIP initialization!
[Match]
[Match]
targetType3 = "ivtank" // Target is designated using the Sabre ODF
attackType3_1 = "fvsent" // Attacker is designated using Sentry ODF
attackType3_2 = "fvsent" // Attacker is designated using Sentry ODF
From this example we can see that the AI will match two Sentries vs. one Sabre tank. There are other examples of the target/attack system used in this example. For instance, I have seen matchups for Scion units vs. ISDF Gun Towers, and ISDF units vs Scion Gun Spires. There are matchups listed for all the units and buildings available in the game and it appears that this system can be completely customized by substituting your chosen ODF's.
Also, we can see some syntax illistrated here. Look closely at the numbering system used.
targetType3 // The third MATCH section of the AIP, defining a target
attackType3_1 // The first unit matchup
attackType3_2// The second unit matchup
All three lines designated use "3" at the end of the operation. The two attack units have the additional "_1" or "_2". This numbering system allows you to use as many units for each matchup as you wish. Additionally, you can make more than one type of response group for each enemy unit. example:
[Match]
targetType1 = "ivatank"
attackType1_1 = "fvtank"
attackType1_2 = "fvtank"
attackType1_3 = "fvtank"
targetType2 = "ivatank"
attackType2_1 = "fvsent"
attackType2_2 = "fvsent"
attackType2_3 = "fvsent"
targetType3 = "ivatank"
attackType3_1 = "fvscout"
attackType3_2 = "fvscout"
attackType3_3 = "fvscout"
All of these matchup are for an ISDF Assault Tank. The AI will send three Warriors, three Sentries or three Scouts against EACH Assault Tank it detects. The composition chosen may be based on available units at the time.
[Plan#]
[Plan1]
planType = "CollectPool" // Scav will find and deploy on 1 scrap pool
planPriority = 500 // Used to set order of each part of the AIP exection
buildIfNoIdle = 1 // If idle, deploy on scrap pool
[Plan2]
planType = "CollectField" // Scav will find loose scrap and collect it
planPriority = 490 // Used to set order of each part of the AIP exection
buildIfNoIdle = 1 // If no scavs exist, build a new one to continue this plan
maxTries = 3 // Try 3 times and quit
Notice here we have [Plan1] and [Plan2]. I have seen plans go to [Plan33] in the canned AIP files. The [Plan] header is incremented by one for each new instance of the header. The most I have ever seen implemented during play testing has been 47 using a single, custom AIP. Keep in mind that the AI will switch to different AIP's depending on conditions in the game (if using instant.dll or mpinstant.dll and the stock AIP's). In my testing, I have only one AIP, but I have seen the AI reintialize this single AIP when conditions in the game changed. As near as I can tell, this occured when I was finally able to mount an attack on the AI base. Other instances might include when you destroy two or more of the AI's extractors, causing it to revert to a simpler AIP to get things going again.
In the two examples above we see several operations. They include planType, planPriority, buildIfNoIdle and maxTries. There are many more of these, and I will list them later. For now, let's look at the one's we have in the examples.
planType - This operation can be many things, from the "CollectPool" and "CollectField" commands to "Hold" and "Attacker". This is used to determine the function of each [Plan] section. The planType can be repeated, i.e. planType="Attacker" could be used multiple times to initiate several different attacks.
planPriority - This is an integer that controls the execution of each section that begins with a [Plan] header. The bigger the number the higher the priority. This number has been noted as high as 500 in the canned AIP files, but it is unknown if there is an upper limit to this starting number. After the first [Plan] header, each [Plan] header that follows will have this operation and the number will be decrimented by at least 5. I have seen it decrimented by 10 in smaller AIP files. This leads me to believe that you can arbitrarily choose your starting number, just assure that you have started with a big enough number to cover everything you want to do. You can see in the two examples above what I am referring to here.
buildIfNoIdle - If there is no "unit_odf", build another to continue that particular plan#
maxTries - The comment I saw with this particular operation was:
// Otherwise I am just killing myself
This means the AI will send a scav to a scrap pool and try to claim it. It will repeat this process 3 times and then quit, assuming that each scav has been destroyed, deeming the process a waste of time and resources. This would seem to make the AI "go to sleep", but keep in mind that game conditions can cause the AI to switch AIP's, which will start plan execution from the begining. In other words, the maxTries is reset to zero and, if implemented in the new AIP, will begin anew.
These are the general ideas behind the AIP files. This info is by no means guaranteed 100% accurate, but we have to start somewhere. :-)
LIST of ODF's and AIP Operations
Below you will find a list of all the basic unit and building ODF's, as well as all the [Path] operations that are found in the canned AIP files. There are allot more ODF's than I wil llist here, but again, this is only a basic list.
ODF List
------------------------------------------------------------------------------
Unit ODF Buildings ODF
----- ----- ---------- -----
ISDF
APC "ivapc" Armory "ibarmo"
Assault Tank "ivatank" Bomber Bay "ibbomb"
Bomber "ivbomb" Factory "ibfact"
Constructor "ivcons" Gun Tower "ibgtow"
Missle Scout "ivmisl" Power Generator "ibpgen"
Mortar Bike "ivmbike" Service Bay "ibsbay"
Recycler "ivrecy" Relay Bunker "ibcbun"
Rocket Tank "ivrckt" Technical Center "ibtcen"
Scavenger "ivscav" Training Center "ibtrain"
Scout "ivscout" Extractor "ibscav"
Service Truck "ivserv" Upgraded Extractor "ibscup"
Tank "ivtank"
Tug "ivtug"
Turret "ivturr"
SCION
Archer "fvartl" Antenna "fbantm"
Builder "fvcons" Dower "fbdowe"
Guardian "fvturr" Forge "fbforg"
Healer "fvserv Jammer "fbpjam"
Hauler "fvtug" Kiln "fbkiln"
Lancer "fvarch" Lung "fblung"
Matriarch "fvrecy" Overseer "fbover"
Mauler "fvwalk" Spire "fbspir"
Scavenger "fvscav" StrongHold "fbstro"
Scout Drone "fvscout" Extractor "fbscav"
Sentry "fvsent" Upgraded Extractor "fbscup"
Titan "fvatank"
Warrior "fvtank"
[Start] Operations // Make global declarations and set initial scrap level
---------------------------------------------
consClass
scavClass
scrapCount
[Match] Operations // Matches enemy units for appropriate friendly unit response
--------------------------------------
targetTypeX // (X=integer)
attackTypeX_X
attackTypeX_X
[Plan] Operations
----------------------------------------------
PlanType // Determines the operation of each seperate plan function
Attacker
BaseBuildMinimums
BuildLoop
BuildMinimums
ClearArea
CollectField
CollectPool
DefendArea
Defender
DistributeUnits
Hold
Recover
Service
Upgrade
For each PlanType, there are a number of different sub-operations that go with them. The next list covers each PlanType and associated sub-operations, presented as example [Plan]s.
Note: Some of the sub-operations are common to most/all [Plan]'s i.e. planPriority, planType
PlanType
----------
Attacker
[PlanX] // Assigns 3 ISDF Scouts to attack deployed Scion scavengers
planType = "Attacker"
planPriority = XXX
targetType = "fbscav"
attackType1 = "ivscout"
attackType2 = "ivscout"
attackType3 = "ivscout"
BaseBuildMinimums
[PlanX] // Builds one ISDF Power Generator, one ISDF Factory and one ISDF Service Bay
planType = "BaseBuildMinimums"
planPriority = XXX
buildType1 = "ibpgen"
buildType2 = "ibfact"
buildType3 = "ibsbay"
BuildLoop // A build loop to create four of "unit_odf", with a loop delay of 2.5min
[PlanX]
planType = "BuildLoop"
planPriority = XXX
buildType = "fvarch"
buildCount = 4
loopDelay = 150
BuildMinimums // Always maintain a minimum of "unit_odf"
[PlanX]
planType = "BuildMinimums"
planPriority = XXX
buildType1 = "fvtank"
buildCount1 = 3
buildType2 = "fvsent"
buildCount2 = 2
doNextonFail = 1
ClearArea
[PlanX] // Order to clear area around a Scion Matriarch
planType = "ClearArea"
planPriority = XXX
targetType = "fbrecy"
CollectField
[PlanX] // Send a scav to collect loose scrap
planType = "CollectField"
planPriority = XXX
buildIfNoIdle = 1
CollectPool
[PlanX] // Send a scav to a scrap pool and deploy it
planType = "CollectPool"
planPriority = XXX
buildIfNoIdle = 1
DefendArea
[PlanX] // Orders defense of an upgraded ISDF scavenger (usually with a turret)
planType = "DefendArea"
planPriority = XXX
targetType = "ibscup"
Defender
[PlanX] // Designates a Defender plan, found only in "strat02.aip" and "strat03.aip"
planType = "Defender"
planPriority = XXX
DistributeUnits
[PlanX] // Unit distribution control, usually last [Plan] in an AIP file
planType = "DistributeUnits"
planPriority = XX
Hold
[PlanX] // Orders a Scion Gaurdian to goto path "hold1", will replenish if destroyed
planType = "Hold"
planPriority = XXX
holdType1 = "fvturr"
holdCount1 = 1
holdPoint = "hold1"
buildIfNoIdle = 1
Recover
[PlanX] // Sets up ISDF Service Bay to service each ISDF "unit_odf" listed as a unitType
planType = "Recover"
planPriority = XXX
serviceUnit = "ibsbay"
unitType1 = "ivscout"
unitType2 = "ivmbike"
unitType3 = "ivtank"
unitType5 = "ivrckt"
Service
[PlanX] // Sets ISDF Service Truck to service each ISDF "unit_odf" listed as a unitType
planType = "Service"
planPriority = XXX
serviceUnit = "ivserv"
unitType1 = "ivscout"
unitType2 = "ivmbike"
unitType3 = "ivtank"
unitType4 = "ibscav"
unitType5 = "ivrckt
Upgrade
[PlanX] // Verify that 3 ISDF scavs are not upgraded, and then upgrade them
PlanCondition = "NotExists"
PlanConditionClass = "ibscup"
PlanConditionCount = 3
planType = "Upgrade"
planPriority = XXX
unitType = "ibscav"
The upgrade goal for extractors can also be simplified as follows:
Upgrade
[PlanX] // Upgrade an ISDF extractor
planType = "Upgrade"
planPriority = XXX
unitType = "ibscav"
What the exact significance of doing the check for pre-existing extractors, or even upgraded extractors, is not clear at this time. Either method shown here seems to work, although I have only been able to get one extractor upgraded in my testing so far. Waitng for more info.
NOTE: The second method does not seem to work for me, although I took this from a stock AIP.
A couple other items of interest are:
doNextonFail = 1 // This is a boolean operation with 1 = true. This is generally seen at the end // of buildMinimum plans. It allows the AIP to continue on to the next plan if // the current plan fails for any reason.
buildIfNoIdle = 1 // This is used to be sure that the plan in question always has a unit performing // that plan's goals. If the unit is destroyed, create another to continue with the // goal. Seen mostly in collectPool and collectField plans.
With all of these examples, most of what you can do in an AIP file has been at least demonstrated above somewhere. Looking at the stock AIP files can be very helpful as well. Most of the examples presented in this document are taken directly from the stock AIP's, including the ones extracted from the DATA.PAK file.
As for the how and why of actual plan file structure and what goes where, I will attempt to make a general explanation. However, I am still trying to figure out the best way to structure a single file to provide a complete challenge on it's own for use with a custom DLL. It would not be too difficult to place a routine or two in a scripted DLL that could check for the existence of certain units or buildings the player has produced. Based on these checks, the players advancement along the technology tree could be tracked, triggering another AIP when a certain unit type or structure has been produced. On the other hand, you could run checks against the AI that looked for the same kinds of things, allowing you to revert to a more simple AIP in the event that the AI base was assulted and some structures were destroyed.
This is the same way the stock DLL's operate. They start with a simple AIP (scioninst0.aip) and deploy the Matriarch and create three scavs, two for pools and one to roam. The DLL then switches gear and moves on to a more complex AIP (scioninst1.aip). After it runs this for awhile, it may switch to either scioninst2.aip or scioninst3.aip to continue harrassing the enemy and solidify resources and the base. Or it could shift to scioninsts.aip if the player(s) happen to be fairly aggressive and make some attacks on the Scion base. This file is for producing units when the AI is under siege by the player.
REMINDER:
50 [PlanX]'s is pretty much the maximum number you can have in a single AIP, and I have seen the AI run through as many as 37 [PlanX]'s in my test AIP. That is pretty good, although to get that far took it awhile. My test AIP contains a total of 43 [PlanX]'s in all. There are still ten operations that have not been activated. I hope to find the best structure for the AIP so it will execute all the [PlanX]'s. I can streamline it some, as described later in this document, too. I want to get the AI to run through all 43 [PlanX]'s if possible, but mission time may make it neccessary to keep the AIP at a smaller number of [PlanX]'s in order to accomplish everything.
EXPLANATION of AIP STRUCTURE
------------------------------------------
I am going to start here by pasting Brad Pickering's blurb from his website in here, and then take it from there. Here are Brad's comments:
"Many single player missions and all instant action missions use AIP files to control what goals the AI will try to persue. A mission script can load an AIP using 'SetPlan'.
AIP files are layed out as follows:
The [start] section is used to set some global values like the name of the construction rig class and the name of the scavenger class.
The [match] section is used to describe the possible force matches between each enemy vehicle type and an appropriate response force.
The other sections, usually called [Plan1] through [Plan<n>] describe various goals like resource collection, attacks, defends, etc.
Look at the AIPs that come with the game in the data\missions\instant directory for examples."
I want to point out a couple of shortcut techniques that I have come across. There is a way to add many operations to a single [PlanX] to get things done more elegantly. Setting each operation up in it's own [PlanX] can be usefull for trouble shooting, but once you get your AIP in order and running the way you want, use the following information to streamline your file.
To construct the AI base, you can make a single [PlanX] that will build all the base buildings, rather than having five or six [PlanX]'s to do so. The following example will demonstrate:
[PlanX] // Places four Gun Spires at buildLoc1-4, and then builds a Scion base at buildLoc5-8
planType = "BaseBuildMinimums"
planPriority = XX
buildType1 = "fbspir"
buildLoc1 = "base_spire1"
buildType2 = "fbspir"
buildLoc2 = "base_spire2"
buildType3 = "fbspir"
buildLoc3 = "base_spire3"
buildType4 = "fbspir"
buildLoc4 = "base_spire4"
buildType5 = "fbforg"
buildLoc5 = "kiln_spot"
buildType6 = "fbstro"
buildLoc6 = "stronghold_spot"
buildType7 = "fbover"
buildLoc7 = "antenna_spot"
buildType8 = "fbdowe"
buildLoc8 = "dower_spot"
buildIfNoIdle = 1
One thing to consider before implementing this idea, however. Since all of this occurs in a single [PlanX], everything at this priority will have to be completed before the AI will move on to lower priority [PlanX]'s. This could potentially hurt the AI in the long run. In the above example, you might consider putting the Spire builds in one or two seperate [PlanX]'s and split the base building into two or more [PlanX]'s, interspersed with the Spires and maybe some unit build and attack plans. However, the above example WILL work and may be exactly what you want to do.
NOTE:The [Cheat] header explained earlier could make this type of plan structure optimal in IA missions. Players will be tied up getting their own base built, scavs deployed/upgraded, etc. If the delay is set to 1 minute the AI would get a huge boost in production capital and could potentially construct an entire base in a short time, with a bank of 500 scrap. :-)
This same thinking on a smaller scale can be applied to unit build operations, attack operations, etc. A couple of different examples of different [PlanX]'s should serve to illustrate the method:
[PlanX] // Will build "unit_odf", producing a given number of each "unit_odf"
planType = "BuildMinimums"
planPriority = X
buildType1 = "fvwalk"
buildCount1 = 3
buildType2 = "fvatank"
buildCount2 = 2
buildType3 = "fvartl"
buildCount3 = 3
[PlanX]
planType = "Attacker"
planPriority = XXX
targetType = "ibrecy"
attackType1 = "fvwalk"
attackType2 = "fvwalk"
attackType3 = "fvwalk"
attackType4 = "fvatank"
attackType5 = "fvatank"
attackType6 = "fvartl"
attackType7 = "fvartl"
attackType8 = "fvartl"
The examples above demonstrate a couple of concepts. First, you can add several units to a single build or attack [PlanX]. Secondly, notice the two planType's. You have a BuildMinimums [PlanX] followed by an Attacker [PlanX]. This is the appropriate way to initiate Attacker plans. First build the units and then order the attack. They could follow one after the other, or be seperated by one or more other [PlanX]'s.
NOTE: Keep in mind that the example above is building eight "heavy" units, which are going to take allot of scrap and time to complete.
That should serve to demonstrate how to make multiple things happen in a single [PlanX]. And now, on to thoughts about each particular [Header] that you can use.
On the [Match] header
I can deduce from the structure of the stock AIP files that you can pretty much [Match] any unit_odf to any other unit_odf. As far as heavy units vs. light units, it is a good idea to add multiple light friendly units vs. one heavy enemy unit. This is obvious during game play as well. You can make any of the four combinations of opponents by deciding initially which race each side will be and creating units and buildings in your custom DLL appropriately.
NOTE: When you create a custom DLL, using spawn points is optional. A DLL gives you complete control over what happens in your mission, so spawning anything you want takes precedence over spawn points. You can create PATH points from the SHIFT+F9 screen in the map editor that can be referenced in your DLL, working for all intents and purposes like a spawn point placed through the editor. Besides, maybe your AI or MPI mission does not start each team with a Recy/Matri because the players have to accomplish some other goals before the base building begins.
On the [PLAN] header
Here is where things get tricky. The other headers are much simpler to use than the [Plan] header, simply due to all the possible things that can be set as goals for the AI. The sequence of AI events in the AI game is controlled here, and making a typo or some other error in syntax can cause the AIP to get hung. Any operations that were successfully implemented up to that point apparently continue to function, but the remainder of the plan file is never realized. My advice here is to proof-read.
When structuring the AIP, think about how you play the game in the Commander's role. How do you manage your scrap? What is your build order? How many units and what type do you need at what points in the game? What about the defence of your base and resources? All of these things are controllable through the AIP files and should be executed in much the same way you would in a game under your Command.
Pathing
You can create paths on a map in the shift+F9 screen of the map editor that can be referenced in the AIP file. There are some path types the AI will use automatically if they exist, other must be referenced in a [PlanX] routine. Following is a list of path points that the game will recognize (based on instant.dll and mpinstant.dll) and used for different purposes. Please remember that these are case sensitive and must be typed EXACTLY as they appear. You can always check a stock map if you are unsure.
"stage1" - "stage3"
"tankEnemy1"
"Recycler"
"RecyclerEnemy"
"Tank1" - "Tank3"
"Turret1" - "Turret3"
"turretEnemy1" - "turretEnemy2"
"gtow1" - "gtow5"
"tankEnemy1" - "tankEnemy3"
"tank1" - "tank3"
"TankEnemy1" - "TankEnemy3"
"SentryEnemy1" - "SentryEnemy3"
"Scout1" - "Scout3"
"Scavenger"
"ScavengerEnemy"
"ammo1" - "ammo3"
"repair1" - "repair3"
"power1" - "power4"
I don't have exact details on the use of all of these path points right now, but I hope to provide more details in later revisions of this document.
Offense - Staging
First, let's talk about staging paths. The AI looks for single-point paths labeled "stage1", "stage2" and "stage3". These can be placed anywhere on your map you choose, but preferrably near scrap pools or other strategic locations. During AIP execution, the AI will use these paths, one for each "Attacker" [PlanX] you have in the AIP file(s) you are using. Say you have three all staging paths placed, the AI uses them as follows:
stage1 - 1st Attacker [PlanX]
stage2 - 2nd Attacker [PlanX]
stage3 - 3rd Attacker [PlanX]
stage1 - 4th Attacker [PlanX]
stage2 - 5th Attacker [PlanX] and so on.
Each Attacker Plan will use the next highest stage# when it is activated, as indicated above. Each plan will continue to use the same staging point throughout the game.
With these single-point paths, the computer will order a group of units in an Attacker [PlanX] to stage at a given stage#. Once all the units in that Attacker [PlanX] reach the staging point, the order for the actual attack is given. This allows the AI to keep an attack group together before an assault begins. Otherwise, the attackers would come in piecemeal after having been spread out during the trip from the enemy base to yours. Easy pickings.
Defense
For defensive purposes, you can place up to four single-point paths labled "hold1", "hold2", hold3" and "hold4" on your map, preferably near scrap pools or some other strategic point. In the AIP you would add a [Plan] of planType = "Hold", and reference each path point you created, which sends a "unit_odf" to that path point as a defender. If the defender is destroyed, the AI will replace it. See the "HOLD" example above. The stock AIP's have examples, too.
Another defensive example is creating several path points labled "gtow1", "gtow2", "gtow3", etc. In the AIP file you would add a [PlanX] of type "baseBuildMinimums" similar to this:
[PlanX] // Creates one gunspire at each of two single-point paths, "gtow1" and "gtow2"
planType = "BaseBuildMinimums"
planPriority= XXX
buildType1 = "fbspir"
buildLoc1 = "gtow1"
buildCount1 = 1
buildType2 = "fbspir"
buildLoc2 = "gtow2"
buildCount2 = 1
This could be used by a devious map maker to create spots for GT/GS 's to allow the AI to mimic the "walking guntower" attack so many players are fond of. However, this could cost the AI dearly if the builder/constructor keeps getting destroyed on the way to each path point.
General Path Use with custom DLL's
You can create single-point paths that can be used to place Defenders, or as spawn points to be used by your custom DLL to place Guardians in pre-planned locations, say guarding a mountain pass. They can be used to reference the exact locations that base buildings will be placed when they are constructed, such as naming the paths "kiln_spot", "stronghold_spot", "antenna_spot", etc.
examples:
"guardian_spot" or "rattler_spot" or "turret_spot"
"ambush_site1" and "ambush_site2"
"fallback_line" and "defensive_line"
To use these properly, while in the Shift+F9 screen of the map editor, you will have to get the coordinates of each path point you place. This can be done simply by placing your mouse over the path and looking in the lower left corner of the window. The coordinates are shown here and as you move the mouse around you will see three numbers change. The numbers are given in this order:
1st# = x coordinate (left/right)
2nd# = y coordinate (top/bottom)
3rd# = z coordinate (altitude)
These references are based on your view of the map. You can see from left to right, from top to bottom, and depth (altitude). Write down the coordinates of each custom path you plan to use in your DLL. To use them, in the DLL Scriptor, under the [Positions] section you would declare each point, giving each of the three coordinates, in the order x, z, y. Seems weird to give the altitude before finishing the 2D positioning, but that is the way the game does it. If you get the coordinates out of order on a given position, then that position will most likely not work properly during the game.
NOTE: Coordinates can be positive or negative numbers. Even altitude can be negative.
You can also create multi-point paths on yourmap that can be used by your custom DLL to direct a single unit or group of units around the map, where ever you want them to go. In one of my missions, I have setup five seperate multi-point paths that lead from the AI base to the Player base in roundabout ways. I have a routine in my custom DLL that begins running about ten minutes into the game which spawns a group of three Scion Warriors and sends them along "path_1". Six minutes later, the second section of this routine spawns three more Warriors and sends them along "path_2". Six minutes later the third section of this routine spawns one Scout Drone, one Sentry, and two Warriors and sends them along "path_3", etc. The routine eventually loops back to the first section and starts over, running in a continous loop until the game ends. This is strictly DLL controlled, though.
NOTES and MORE:
It might interest the reader to know that the author is in the process of experimenting with a simple map and the AIP stuff, utilizing the DLL Scriptor tool to make a simple starting script. I am starting by creating a Recycler for the player and a Matriarch for the AI. Then I make a simple plan file and assign it to the AI through the DLL, telling the AI which plan file to use. In this fashion, I can test each [Plan] individually, for instance, and see exactly what the AI does with each operation. This is time consuming, but extremely informative. I will come back to this document from time to time and make changes as neccessary.
I started out using the stock AIP file SCIONINST0.AIP, which very simply deploys a Matriarch and proceeds to build two scavs for pool deployments and one for loose scrap gathering. That is all it does, but it does it pretty well. I might suggest interested parties start with this simple plan file as a lithium test. After seeing how it works, you can add one or two new [PlanX]'s to it and then go back, play the test mission and see what the AI has acomplished.
TIP: A handy commandline switch you can add to your BZ2 shortcut is /aipLogging. This will track the execution of the AIP file and log the results in the file schedLog[N].txt (N=numeral). This file is created in the root of the BZ2 directory. Please keep in mind that the game will not write the actual file until you exit the game. This means that if you play a game and record a log file, and then begin a new game without exiting BZ2, the older log information is discarded so the new info can be logged.
The shortcut command line looks like this: "C:\Games\Battlezone II\Bzone.exe" /aipLogging
In the future, I may add more information regarding the contents of the log files generated with the /aipLogging switch. There is a great deal of information there, and most of my conclusions come from the knowledge gleaned from the log files. It works best for me if I play through a test mission, and then immediately go into the log file. In this way, I can usually remember what happend at what time as I am going through each stage of the game. This is called post-mortem in the Chess world, practiced by tournament players to help them get better.
