<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META NAME="Author" CONTENT="Martin Bickel">
<META NAME="GENERATOR" CONTENT="WebWriter/2 v1.2">
<TITLE>ASC documentation: Importing graphics from Battle Isle</TITLE>
<LINK REL="stylesheet" TYPE="text/css" HREF="asc.css">
</HEAD>
<BODY text="#000000" bgcolor="#ffffff">
<CENTER>
<H1>Advanced Strategic Command</H1>
<P>documentation<P>
<H2>Building new Items with Battle Isle Graphics</H2>
</CENTER>
<I>
<HR>
Update October '99:<P>
ASC no longer uses the Battle Isle graphics since that would be a copyright violation, so we have created our own graphics. But to enable us importing Battle Isle maps these new pictures are arranged just like the pictures that we read out of Battle Isle, although we have only a small number compared to the 1300 terrain graphics of Battle Isle.<P>
If you want to help us by creating more "replacement graphics", check out the file <A HREF="graphics.html">map graphics</A>.<P>
The rest of this document has not been updated to reflect the new graphics system.<P>
<HR>
</I>
<H3>Index</H3>
<A HREF="#terrain">Creating terrain</A><BR>
<A HREF="#vehicles">Creating vehicles</A><BR>
<A HREF="#buildings">Creating buildings</A><BR>
<A HREF="#objects">Creating objects</A><BR>
<H3>Motivation</H3>
Since it is quite much work to make Terrain, Buildings and Objects for
all graphic tiles from Battle Isle, I did import only the most important
tiles and even these terrain and objects have usually quite generic parameters.<P>
This is a step by step walk through on how to make your own terrain fields, vehicles, and objects using
graphics of Battle Isle. To write this text I created the items myself and will
include them in the release version of ASC. It would be not very effective to create
these items a second time so you should create other items with graphics
that are not yet implemented in ASC and use this text as a general guide
instead of "executing" it word by word.<P>
Suppose you want to import a map from Battle Isle and get the following
message:
<DL>
<DD>The following terrain fields could not be found: 130</DD>
<DD>The following objects could not be found: 237, 42, 239, 236, 1331, ...</DD>
</DL>
This means, that some fields where there should be a terrain with graphic
tile number 130 now contain the currently selected terrain. And several objects are
simply missing.
<P>To correct the problems, you have to manually create these objects
and terrain. If you have not done so already run the program <TT>BI2PCX.EXE</TT>.
It generates a huge image called <TT>BI_GRAPH.PCX</TT> that contains all graphics
of Battle Isle and some information if they are used in ASC or not. Running <TT>BI2PCX
/INDEX</TT> will generate additionally an image that explains how to read the
parameters given with the images.
<P>If you intend to import more then one or two graphics it is probably
a good idea to print the image <TT>BI_GRAPH.PCX</TT>. Color printers are quite common
these days so it should be no problem to find someone who owns such a printer.
Depending on how large you are going to print it you may try running <TT>BI2PCX
/WIDE</TT> to generate an image with 10 columns instead of 5.
<P>
<H3><A NAME="terrain">Creating a new terrain</A></H3>
I will now describe how to create a new terrain. This will be a step to
step walk through.
<P>Now lets look what the image #130 is. Before we start we have to check
which ID we can use for our items since each item must have a unique ID. See <A HREF="editors.htm#ID">editors.htm</A> for more information about IDs.
For this example we will use 360 as the id.
<P>To make a terrain type you have to start <TT>MAKETRR.EXE</TT>. First you
are asked whether you want to create a new type or edit an already existent
one. Choose Create. Now the programs asks you to enter a filename. It is
recommended to include a description of the terrain and the ID in the name.
We are going to create a swamp with an id of 360, so <I>SWMP0360</I> would be
an appropriate name. After that you have to enter the id (400) and a description
for the terrain, for example <I>Dense Swamp</I> or <I>Mangrove</I> or whatever
you imagine this picture to be. The next step is to define the different
weathers the terrain will be available for. You have to browse the BI graphics
index picture to decide which graphics will match: Picture #590 is obviously
this swamp with some snow on it, image #702 is it with much snow and image
#815 after much rain. So mark <I>dry (standard)</I>, <I>heavy rain</I>, <I>few snow</I>
and <I>lot of snow</I> and press enter. Do never use fog because fog is not completely
implemented yet and does not work like rain and snow at all.
<P>The following block will be repeated for each weather:
<BLOCKQUOTE>Since we are making hexagonal fields the next question can
be ignored: the program does not use rotated hex fields at all. Just mark
<I>0 ( up )</I> and continue. The next question should be clear: we want to use
pictures of Battle Isle. Select your picture and confirm your selection.
<P>The selection of the terrain type is not so obvious. You should read
the documentation for the vehicle editor to find out how these fields are
used. For this particular terrain I use <I>swamp thick</I>.
<P>Most terrain don't have a <I>Defense bonus</I> and <I>Attack bonus</I> yet although
it would useful. Anybody who wants to set them up is welcomed,
but I have other work to do (like writing these docs :-)
<P><I>Basic jamming</I> is similar, but it does not disturb the playing of a map
with some fields having jamming themselves and other that don't. So I use,
well, 10 as the jamming value. Check out the paragraph about how ASC measures
distances if you don't know yet. The value entered here for jamming reduces
the view of any unit that has to look across these fields by 10.
<P>The <I>number of movemali</I> does not affect which vehicles can enter
the field. It just say how many different values for the unit categories
exist. If you use one then you have to enter only the default value which
all vehicles will use. When specifying 3 movemali you have to enter the
values for default, light tracked vehicle and medium tracked vehicle. All
other units will use the default value. You should never enter a value smaller
then the smallest distance between two fields as a movemalus! It would
screw all path finding algorithms completely up resulting most probably in a game
crash sooner or later. <BR>In this terrain tracked vehicles should generally
perform better then wheeled vehicles and the medium sized ones better then
the others. So I suggest the following values:
<UL>
<LI>
number of movemali : 8</LI>
<LI>
default : 24</LI>
<LI>
light tracked vehicle : 20</LI>
<LI>
medium tracked vehicle : 16</LI>
<LI>
large tracked vehicle : 18</LI>
<LI>
light wheeled vehicle : 24</LI>
<LI>
medium wheeled vehicle : 20</LI>
<LI>
large wheeled vehicle : 22</LI>
<LI>
trooper : 14</LI>
</UL>
</BLOCKQUOTE>
Well that was it for the dry weather. I don't think that these parameters
should vary much with the other weathers except that more vehicles should
be able to drive onto this field when it's frozen ( so I choose <I>forest</I>
for the <I>lot of snow</I> weather) and the movemali should also be better
when its frozen:
<UL>
<LI>
number of movemali : 8</LI>
<LI>
default : 20</LI>
<LI>
light tracked vehicle : 16</LI>
<LI>
medium tracked vehicle : 14</LI>
<LI>
large tracked vehicle : 14</LI>
<LI>
light wheeled vehicle : 20</LI>
<LI>
medium wheeled vehicle : 16</LI>
<LI>
large wheeled vehicle : 16</LI>
<LI>
trooper : 13</LI>
</UL>
That was all ! Now there should be a file named <TT>SWMP0360.TRR</TT> on your
hard disk that can immediately be used in the mapeditor.
<P>If you intend to make quite a lot of terrain and use generic parameters for them you should not use the program <TT>maketrr.exe</TT> as described above. At the time of writing I have made 357 terrain types using graphics of Battle Isle. You can probably imagine that I would have gone nuts if I went through the above procedure for each of the 357 terrain types. Especially since many of them are quite the same, there are for example 93 different fields that are just impassible for any unit, varying only in the picture used. To create such rows of identical terrain types I have written special programs. If you are a programmer, check out the other <TT>makebdt?.cpp</TT> files in the <TT>source\tools\</TT> directory. If you don't know how to modify and compile these programs for the purpose needed you should contact us on the mailing list so that we can give you ready-to-use programs.<P>
<H3><A NAME="vehicles">Creating vehicles</A></H3>
This is a walk through on creating a ditching machine.<P>
To make a vehicle type you have to use <TT>MAKEVEH.EXE</TT>. After choosing to create a new vehicle we have to enter the filename, <TT>G_DITCH</TT> is a good name. I recommend to start all filenames for ships with <TT>S</TT>, all Aircraft with <TT>A</TT> and all ground based vehicles with <TT>G</TT>. This enables us to specify the group of vehicles just be using the wildcards when changing the parameters of a whole group of vehicles (with the program <TT>CONVTANK</TT>, which is in the source distribution since it is useless to non-programmers).<P>
The next question is obvious: we want to use BI graphics. The ditching machine is picture number 1342. Since ASC is able to rotate a picture by any angle we need only one picture for each vehicle, the one with the unit facing up.<P>
Having confirmed that we chose the correct picture we have to enter the ID for the vehicle. See <A HREF"id.html">id.htm</A> for a discussion about how to choose an ID. For the ditching machine I use 60. The description of the unit is "ditching machine" and the name "regio".<P>
Since I do not have an infotext about ditching machines (and I don't want to write one too) I have to negate the question about the infotext. The format of text files for ASC is discussed <A HREF="text.html">here</A>.<P>
For the production cost (and some other parameters later too) we have to take a look at the vehicles we already have. Use <A HREF="prnttank.html"><TT>printtank</TT></A> to generate lists containing all important vehicle parameters. The file <TT>tanks5.txt</TT> is sorted by the production cost material. The construction vehicle for example costs 2592 energy and 3240 material, so I use 2210 energy and 3040 material. And since I imagine a ditching machine to be more robust than a construction vehicle I use 285 as armor.<P>
The regio is of course a land based vehicle so the only height to select is <I>ground level</I>. Some notes about aircraft: Any aircraft has to be able to reach the ground level else it would be unable to land and enter an airport / aircraft factory. And there must not be any gaps in the reachable heights! A flying vehicle that can only land on water (for example a <A HREF="http://www.io.tudelft.nl/~twaio/edwin/html30/index.html">wing in groundeffect vehicle</A>) must have ground level as an height. You can then specify water as the only terrain the unit can land on. Ground based units can go across the water if they have the water bits set in the terrain field. The air cushion vehicle is an example for such a unit. Such a unit can not be attacked by torpedoes!<P>
For each height we have to enter the speed of the unit. The way distances are measured in ASC is described in the <A HREF="asc.html#distances">documentation</A>. Out regio should move 5 fields per turn on road so 50 is the value we have to enter here.<P>
The regio is a tracked vehicle that is neither very large nor very small so we select <I>medium tracked vehicle</I> as category. The terrain may have different movemali for the different categories of vehicles. This field is only interesting for ground based units, all other should use <I>default</I>.<P>
To specify the terrain the unit can enter we have to setup several variables. The terrain must have at least one of the bits set that are entered in the first variable (<I>Terrain the unit can drive on</I>). Our ditching machine should be able to drive across normal <I>lowland</I>, <I>road</I>, <I>railroad</I>, <I>runway</I>, <I>hard sand</I>, <I>soft sand</I>, <I>small rocks</I>, <I>mud</I>, <I>snow</I>, <I>deep snow</I>, <I>small trench</I>, <I>ditches</I> of course and <I>swamp thin</I>. Note that we do not select <I>pipeline</I> for example since if we selected it the unit would be able to enter any field that has a pipeline, even deep water if there was a only a pipeline.<P>
The next variable is described as <I>ALL these selected terrain-bits are necessary for the unit to drive there</I>. Most units do not have any bit set here. If I remembered any unit that makes use of this variable I would use it as an example.... :-)<P>
The variable described as <I>NONE of these bits must be set</I> is explained by <I>all ships (except icebreaker) must have the ice/snow bits set here)</I>. I think I don't have to say more about it. The regio does not need any of these fields to be set. I just had an idea about a tank that is too heavy to cross any bridges. This could be realized be setting the water bits here.<P>
The last terrain question is called <I>the unit dies on ... ( only if it cannot enter, see entries above)</I> with the example of <I>most land based units should have the water-bits set here</I>. This variable is only evaluated when a field changes while the unit is standing on it. Examples are melting ice or a bridge that is destroyed. For our ditching machine we set the four water bits.<P>
The next question is quite self explaining. As an example I use some Battle Isle units: the zenit (battleship) and the pulsar (artillery) cannot attack if they have already moved this turn. Principally this variable can be used not only attacking but for repairing, building and refueling too, but there may be some limitations (perhaps they could only repair, build or refuel only once per term but I have to look at the code to be sure...). But our regio does should not wait anyway.<P>
To choose the weight of 56 I checked the file <TT>tank9.txt</TT>.<P>
Since our ditching machine cannot load anything we enter 0 for <I>max load</I>.<P>
<I>Fuel consumption</I>: 14<P>
Since the digging of ditches is not free of charge lets set the <I>fuel tank</I> to 1200. Only one unit has an <I>energy tank</I>, the generator vehicle, for all other vehicles including our regio a 0 must be entered for <I>energy tank</I>. Since the construction of ditches requires some <I>material</I> (the amount is specified in the ditch object <TT>ditch.obl</TT> ) our ditching machine get a material transportation capacity of 450.<P>
A ditching machine should not get any weapons so we skip the weapon questions. But I explain them anyway:<P>
For each weapon the following parameters have to be set:
<BLOCKQUOTE>
One weapon type out of 9 available types must be set. <I>Cruise missile</I>, <I>mine</I>, <I>bomb</I>, <I>air - missile</I>, <I>ground - missile</I>, <I>torpedo</I>, <I>machine gun</I>, <I>cannon</I> and <I>service</I> are available. Never use more than one of these types for a single weapon! Additionally the weapon can have the <I>shootable</I> and the <I>ammunition refuel</I> attribute. If the weapon should be able to be fired the <I>shootable</I> bit must be set. An ammunition transport does not have this attribute. Instead it has the <I>ammunition refuel</I> bit set so it is able to equip other vehicles with ammunition. It is possible to have both the <I>shootable</I> and the <I>ammunition refuel</I>. The <I>service</I> weapon type is quite different since it is not weapon. It allows a unit to do service to other units standing next to it. By introducing this weapon type we had a system that prevented the tanker plane for example to refuel submerged submarines. The <I>ammunition transport</I> must have one <I>service</I> weapon with a distance of 8 - 15 and ground level as <I>destination</I> and <I>usable on</I> heights (see next paragraphs). An <I>aircraft carrier</I> must NOT have a <I>service</I> weapon since it should not be able to repair or refuel vehicles standing next to it since they have to be loaded to be serviced. But it has the <I>ammunition refuel</I> bit to equip the loaded units with ammo. A weapon with <I>ammunition refuel</I> capabilities on a vehicle that does neither have a service weapon nor is a transport is completely useless. The <I>repair</I> and <I>refuel</I> functions use the <I>service weapon</I> too. A <I>service weapon</I> should always have a range of one field (not because it would screw up the program but because it would severely spoil gameplay).<P>
Note that you must also specify a strength for mines since the power of mines is determined by the vehicle that employed them.<P>
The <I>aims</I> field specifies on which levels of height a vehicle can be attacked.<P>
<I>The weapon can be shot from</I> is quite self explaining too. Airplanes for example should not be able to fire when they are landed. And a submarine can not use its machine gun when submerged.<P>
The next two variables specify the <I>max distance</I> and the <I>min distance</I> the weapon can be fired. Check out the <A HREF="asc.html#distances">documentation</A> for more information on the distance measurement.<P>
<I>Strength at min distance</I> and <I>strength at max distance</I> set the strength of the weapon. <I>Strength at min distance</I> must always be equal or greater than <I>strength at max distance</I>. Be careful not to use different strength for a weapon that has only a range of one field (for the octagon version of ASC the <I>min</I> and <I>max distances</I> must be 8 and 12 for such a weapon). Originally we did not specify a <I>strength at max distance</I> but calculated it from the strength, type (!) and distance of a weapon. But this proved to work not as good as we expected. Because of this old system the strength between <I>min</I> and <I>max distance</I> is not linear interpolated but each weapon type has its own distance->strength function that is now scaled to match the <I>min strength</I> value.<P>
The number of shots the vehicles can do with each weapon is set by the <I>ammo</I> variable.<P>
A recently added feature is the modification of the weapon strength by the height difference. In ASC there are eight levels of height: <BR>
<UL>
<LI>deep submerged
<LI>submerged
<LI>floating
<LI>ground based
<LI>low level flight
<LI>medium level flight
<LI>high level flight
<LI>orbit
</UL>
For the height-difference-calculation <I>ground based</I> and <I>floating</I> are set to be the same. The reason for them beeing two different heights are others that I won't discuss here.<BR>
So for an attack their may be 13 possible difference of height, from -6 ( attacker <I>orbiting</I> and target <I>deep submerged</I>) to 0 ( both have the same height, regardless where ) to 6 ( attacker <I>deep submerged</I> and target <I>orbiting</I> ). For each of these 13 height difference you can specify a percantage of strength.<P>
Lets make an example: We use an aircraft with a weapon that targets ground based vehicles and floating units. The plane can fly on low and medium level and can shoot from both levels of height. But from medium level flight it should have a very bad hit accuracy, let it be 15%. So we specify 100% as accuracy for shooting over a distance of -1 and 15% for a distance of -2 . All other values may still be 100%, they will not be evaulated since there are not other height differences possible with the "can be shot from" and "targets" variables.<P>
</BLOCKQUOTE>
<P>
<I>Initiative</I> is only needed for vehicles having weapons. The regio gets a 0 here. Refer to the <A HREF="asc.html#attack">chapter about the attack formula in the documentation</A> for more information how this values is used. <B>Note that we do not use this value at all yet so it may be possible that is does not work as expected and the attack formula must be modified to make it work as it should work.</B><P>
The <I>functions</I> define what the unit is able to do. At the time of writing we have the following functions available:
<DL>
<DT><I>sonar</I>
<DD>The vehicle is able to see submerged submarines
<DT><I>paratrooper</I>
<DD>The vehicle is able to exit flying aircraft. A paratrooper is never flying! As soon as it leaves the plane he immediately touches the ground. It should not have any flying as reachable heights!
<DT><I>mine layer</I>
<DD>The vehicle is able to put mine. It needs also a correct weapon of type <I>mine</I> !
<DT><I>conquer buildings</I>
<DD>The vehicle is able to conquer buildings. Refer to the <A HREF="asc.html#conquer">chapter in the documentation</A> for more details about conquering.
<DT><I>trooper</I>
<DD>Troopers may enter any building and any transport. They should usually also be able to conquer buildings so they should get the <I>conquer buildings</I> attribute too.
<DT><I>repair vehicle</I>
<DD>The vehicle can repair other units. There are two possibilities to use this features:
<UL>
<LI>if the repair vehicle can load other units it can repair the loaded units. The aircraft carrier can do this for example.
<LI>if the repair vehicle has a <I>service</I> "weapon" it can repair vehicles that are standing next to it, like the repair ship.
</UL>
It is no problem build a unit that can do both! Note that a repair vehicle must have sufficient material and fuel tanks!
<DT><I>view satellites</I>
<DD>Like <I>sonar</I> but for seeing vehicles that are in orbit.
<DT><I>construct buildings</I>
<DD>The vehicle can construct buildings. Make sure it has enough material and fuel capacity !
<DT><I>view mines</I>
<DD>The vehicle can see enemy mines. All <I>mine layer</I> should have this bit set.
<DT><I>refuel units</I>, <I>refuels material</I>
<DD>These two functions work like the <I>repair vehicle</I> function.
<DT><I>icebreaker</I>
<DD>A unit that has this feature does build a special object <I>broken ice</I> if it moves across <I>snow</I> or <I>pack ice</I>. The unit must have the appropriate bits set at the <I>terrain</I> variables since this function is independent of the routine that determines if a unit can enter a field or not. At the time of writing we do not have the <I>broken water</I> object for the hexagonal version and the icebreaker is totally untested there. Check out the tutorial of the octagonal version of ASC to see how to use an icebreaker.
<DT><I>makes tracks</I>
<DD>Although it seems that these functions have nothing in common the <I>makes tracks</I> features works nearly identically to the <I>icebreaker</I> function. The difference is that it puts the <I>track</I> object on the fields the unit drives through instead of the <I>broken ice</I> object. The track have no other purpose then the optic one. They are put only on fields that have the <I>tracks possible</I> bit set. At the time of writing we do not have a <I>track</I> object for the hexagonal version too. Most land based vehicles should have this bit set.
<DT><I>drill for mineral resources manually</I>, <I>search for mineral resources automatically</I>
<DD>The vehicle is able to spot resources in the earth. Check out the <A HREF="asc.html#resources">chapter about resources in the readme</A> for more information about the resource system in ASC.
<DT><I>sailing</I>
<DD>is an feature we have not implemented yet. The idea was to allow ships to travel only by wind power, depending on the wind of the map. Such maps would only be interesting in a campaign and since we don't have a campaign nor special units we did not have any reason to program that yet. But if you are designing a campaign and want to use this features (and have graphics for sailing ships) contact us!
<DT><I>auto repair</I>
<DD>is a function only very large and expensive vehicles should have. Our Aircraft carrier is an example for a unit that is able to repair itself. Check out the <A HREF="asc.html#repairing">chapter about repairing in the readme</A> for more information about this. <I>Automatic repair</I> should be preferably used in later classes that have to be researched first.
<DT><I>generator</I>
<DD>is only used by one particular unit, the <I>generator vehicle</I>. This function was not designed to be commonly used in the gameplay of maps for ASC. We are planning to implement a Laser as an additional weapon which uses energy as ammo. Such a unit must have the generator attribute.
<DT><I>kamikaze only</I>
<DD>is not implemented yet, but it should be clear what it should do: Making a unit attack only once. Intercontinental missiles could be realized with it for example.
<DT>Entries marked with an exclamation mark ( <I>!</I> )
<DD>are not used any more and reserved for future expansion. Do not use them.
</DL>
<P>
If a unit has the ability to search for resources (which our regio has not) you have to enter the <I>digrange</I>. This is the radius of the circle where the resources will be known after having drilled for them or, if the unit has the automatic resource searching feature, having entered a field. This is NOT a distance but the number of fields. Useful values are 2 to 5 for example.<P>
The <I>view</I> specifies how many fields a unit can see. It is a distance. Simple vehicles like our ditching machine should look just one field far, so I use 15. All units have at least a view of one field regardless of the enemy jamming around them. For an explanation how the calculation of <I>view</I> and <I>jamming</I> works take a look at the <A HREF="asc.html#view">chapter about view in the readme</A>. Our regio does not have make any <I>jamming</I> so we confirm the values of 0.<P>
A vehicle can have several classes that can be researched and improve the vehicle. The ditching machine is much to simple to have different classes so we enter a 0 for <I>number of classes</I> and use the <I>standard research values</I> for it. So it is available just form the start and does not need any research to take place until it can be produced. An explanation of the research can be found <A HREF="maketech.html">here</A>. But I explain the functions field here with an example: Suppose we want to create a unit that has two classes. The first one does not have the autorepair feature, and when a technology (that we do not have yet) "auto repair" with ID 100 is researched the class number two will be available that has the autorepair function. In the basic <I>functions</I> variable for the vehicle we have to enable autorepair! The values for the first class will be the standard values and the <I>autorepair</I> bit must not be set for the functions of the first class . The second class should have 1024 for all weapon and armor improvement since no improvement in that are should be required, but it must have 100 as a required technology. And the <I>autorepair</I> bit in the functions for this class must be enabled.
<P>
<I>Max windspeed on water</I> is only available for units that have <I>ground based</I> or <I>floating</I> as available heights. The idea for this function was to make some small ships vulnerable to heavy sea. They sink if the wind is faster than this value and the ship is not standing on a field that has the <I>harbor</I> attribute. This functions works for <I>ground base</I> too so that some vehicles may be blown off a bridge. But this should be more a gag for one or two <I>ground based</I> vehicles than a common danger for them. Our ditching machine should not be vulnerable in this area so we enter the largest available value of 255 which is also the fastest speed of wind.<P>
The last variable we have to define before our regio is finished is the definition of the objects it can build: <I>the unit can build the following items of the object layer</I>. All available objects are listed with their ID. But note that the value you enter is totally independent from the things displayed above. You may enter any ID. The ditching machine should be able to build just on object: ditches. The file that contains the ditches is called <I>ditch.obl</I>. So we enter the 10 that is display in front of the filename. Then we enter a 0 to finish the definition of the objects. <P>
That was it! Now we have a file called <TT>G_DITCH.VEH</TT> on the hard disk that can be used in the mapeditor.<P>
We have been talking about ditching machines for quite some time now. If you want to know how they look like in reality and what they can do you should follow this link: <A HREF="http://users.aol.com/mikegalope/engineer2.html"> http://users.aol.com/mikegalope/engineer2.htm#MDK</A> (the main page for this site is <A HREF="http://users.aol.com/threatmstr/ptwserg.html">Military Equipment of the Former USSR & Russia</A> ).<P>
<H3><A NAME="buildings">Creating buildings</A></H3>
In this walk through I describe how I made the <I>depot</I> - building.<P>
First I checked which graphics the depot should use: The Battle Isle pictures #44, #46, #47 and #49. The editor buildings is<TT>makebld.exe</TT>.<P>
After choosing to create a new building we have to enter the filename for our building: <TT>DEPOT</TT>. <P>
The editor now asks how many <I>construction steps</I> the building should have. Since we have only one set of graphics for the building we have to confirm the 1.<P>
There are only very few buildings that have more than one different picture. The only one up to now was the octagonal wind power plant that had one picture for each direction of the wind. Note that the usage of the different pictures is hard coded in the program so it would be useless to specify more than one picture for a building that is not a wind power plant without enhancing the game itself. So we confirm the 1 again.<P>
Some buildings in Battle Isle have different pictures for different weather. The "Villa Deng" for example is available with some snow on it ( picture #984 ), but there are no picture for out depot. So just use <I>dry (standard)</I> and select for the next question the use of <I>Battle Isle graphics</I>.<P>
Now a picture is displayed that shows all fields that a building may cover. For each field that should belong to our building we have to click on it an select the graphics. So we first click on the field in the first column and second row and select the Battle Isle picture #44 for it. Column 2 and row 1 (of this column) will be associated with picture #46, c3 and r2 with #49 and c2 r2 with #47. Now we can answer the question <I>more pictures</I> with 'N'. The program now asks us to click on the <I>entry</I> for the building , the <I>powerline connector</I> and the <I>pipeline connector</I>. Check out the <A HREF="asc.html#resources">readme</A> for more information about the resource system with its pipelines and powerlines.<P>
As <I>ID</I> for the building I choose 54 and "depot" as <I>name</I>. <P>
The <I>production costs</I> are 2000 <I>material</I> and 1500 <I>fuel</I>. That is quite cheap for a building but on the other hand a depot cannot do very except storing and repairing vehicles.<P>
It gets an <I>armor</I> of 1800<P>
The <I>maximum size of units</I> that may enter the building is not restricted so we enter the maximum value of 65535.
<I>Loadable units</I> specifies on which heights a unit must be to enter. The airport has <I>ground level</I> selected here since the planes do not fly into the hangar. And our depot gets this setting too.<P>
The next question asks the <I>unitheightreq (a unit must be able to reach in order to enter)</I>. The airport for example has <I>low level flight</I> selected here. That does neither mean that the airport is a flying building nor the vehicles enter it on this level of height. It sets that only vehicles that are able to reach this height may enter. So tanks may not enter an airport. And our depot gets <I>ground level</I> too.<P>
<I>Units that may NOT enter</I> set one or more heights that units must not be able to reach to enter the building. Airplanes for example must not enter the depot: we set the three levels of flight here and <I>orbit</I>.<P>
The level of height the building is actually build on is defined by the next variable. Please be careful designing flying buildings. This has not been tested yet and my result in strange effects. But <I>submerged</I>, <I>floating</I> and <I>orbiting</I> buildings are ok. The depot we are designing is just <I>ground level</I> based again.<P>
To specify the terrain the building can be build on we have to setup several variables. It's the same system that is used for vehicles and objects too. The terrain must have at least one of the bits set that are entered in the first variable (<I>Terrain the building can be build on</I>). Our depot should be able to stand on <I>normal lowland</I>, <I>hard sand</I>, <I>soft sand</I>, <I>small rocks</I>, <I>small rocks</I> and <I>snow</I>.<P>
The next variable is described as <I>ALL these selected terrain-bits are necessary for the unit to drive there</I>. Most units do not have any bit set here. If I remembered any unit that makes use of this variable I would use it as an example.... :-)<P>
The variable described as <I>NONE of these bits must be set</I> is explained by <I>all ships (except icebreaker) must have the ice/snow bits set here)</I>. I think I don't have to say more about it. The depot does not need any of these fields to be set. I just had an idea about a tank that is too heavy to cross any bridges. This could be realized be setting the water bits here.<P>
The last terrain question is called <I>the building dies on ... ( only if it cannot enter, see entries above)</I> with the example of <I>most land based units should have the water-bits set here</I>. This variable is only evaluated when a field the building stands on changes. For example when there is a flood (perhaps because a dam broke.... that was a cool Battle Isle mission!). Because the depot is quite simple and is not "high tech" building let's make it water resistant to some degree. Only <I>water</I> and <I>deep water</I> can do any harm to it, so we mark these two bits. This means that shallow water does no harm to the building.<P>
The maximum amount of resources the building can store has to be specified for both the <I>ASC resource mode</I> and the <I>BI resource mode</I> (see <A HREF="asc.html#resources">the readme</A> for more info). In the <I>ASC mode</I> the depot can store quite an amount: 10000 fuel and 30000 material, but no energy. Only power plants should be able to store energy, and not much more than they are able to produce in a single turn to make energy a "volatile" resource that has to be produced "just in time". The maximum storage capability in the <I>BI resource mode</I> should not be limited so we enter 1000000000 for each resource. That is actually a limit but I don't think that it will ever be reached in a serious game.<P>
The depot should not be able to produce energy, material or fuel so <I>fuel maxplus</I>, <I>material maxplus</I> and <I>energy maxplus</I> should be set to 0. The <I>efficiencies</I> for <I>material</I> and <I>fuel</I> are used by mining stations and power plants. Since the depot is neither we set them to 0 too. The base for the efficiency is 1024. Suppose you want to design a conventional power plant that burns resources to produce energy. If you set <I>fuel efficiency</I> to 1024 and <I>material efficiency</I> to 0 the power plant would burn as much fuel as it produces energy. If you set <I>fuel efficiency</I> to 2048 it would burn only half the fuel to produce the same energy output. If you set <I>fuel efficiency</I> and <I>material efficiency</I> to 1024 it would burn fuel AND material to produce energy.<P>
We set <I>technology level</I> to 0 so that the depot is available just from the start of the game. See <A HREF="maketech.html">the documentation for <TT>maketech.exe</TT></A> for an explanation of the research system.<P>
The depot should not be able to research anything so <I>max research points</I> should also be set to 0.<P>
The last variable we have to set determines what the building is able to do. The following <I>functions</I> are available:
<DL>
<DT><I>HQ</I>
<DD>is not used at the moment. Perhaps some victory conditions will be sometimes defined using it.
<DT><I>training</I>
<DD>A building with the <I>training</I> attribute is able to increase the experience of units that are loaded at the cost of ammunition.
<DT><I>refineries</I>
<DD>Are not used at the moment too. The idea was to convert resources with it.
<DT><I>vehicle production</I>
<DD>The building is able to produce vehicles. The vehicles that can be produced have to be set in the map editor for each factory.
<DT><I>ammunition production</I>
<DD>Does not need any explanation, does it ?
<DT><I>energy production</I>, <I>material production</I>, <I>fuel production</I>
<DD>The building produces the specific resource. If no way is defined (see the following bits) how it is produced it just materializes (or energizes...) out of nothing.
<DT><I>repair facility</I>
<DD>The building is able to repair vehicles.
<DT><I>recycling</I>
<DD>is an efficient way to gain the resources of a vehicle. See the <A HREF="asc.html#recycling">readme</A> for more details about recycling.
<DT><I>research</I>
<DD>should be clear.
<DT><I>sonar</I>
<DD>enables a building to spot submerged submarines. See the <A HREF="asc.html#view">readme</A> for more details.
<DT><I>wind power plant</I>
<DD>The energy the building produces is generated by wind power. The amount of energy production depends on the speed of the wind. The building must have the <I>energy production</I> bit set in order to function properly.
<DT><I>solar power plant</I>
<DD>The energy the building produces is generated by solar cells. The amount of energy production depends on the weather. The building must have the <I>energy production</I> bit set in order to function properly.
<DT><I>conventional power plant</I>
<DD>The energy the building produces is by burning other resources. The building must have the <I>energy production</I> bit set in order to function properly. It must also have a value for <I>fuel efficiency</I> and / or <I>material efficiency</I>.
<DT><I>mining station</I>
<DD>The resources the building produces are taken from the ground. The building must have the <I>fuel production</I> bit or the <I>material production</I> bit set in order to function properly. It must also have a value for <I>fuel efficiency</I> or <I>material efficiency</I>.
<DT><I>external loading</I>
<DD>A normal building can only transfer resources into vehicles when the vehicles are inside the building. But it would be stupid to build an oil rig that is able to hold a complete oil tanker. So the oil rig should be able to transfer the resources to a vehicle standing next to it.
</DL>
The only function our depot should have is the <I>repair facility</I>.<P>
It should not have any <I>jamming</I> capabilities and the view does not need to be very large too, so we use 15. By the way, the view is calculated around the entry field so this depot can view only the 3 fields left to its entry since the other 3 fields right to it are covered by the building itself (that are seen too of course, but they are uninteresting since no unit except airplanes may pass over them and even airplanes may not stand on them).<P>
Now the depot is finished and ready to be used!<P>
<H3><A NAME="objects">Creating objects</A></H3>
In this walk through I describe how I made the <I>wreckage</I> object which uses the picture #38, the wreckage of the "Liandea" in the BI2 scenery campaign.<P>
After checking with <TT>HEXIDS.EXE</TT> I choose 76 as the ID for it. So after starting <TT>MAKEOBL.EXE</TT> and selecting <I>create a new objects</I> I enter <I>wreck076</I> as the filename for it.<P>
The next question asks if you want to use a "dirlist". Creating objects that have several pictures like streets or woods where the game aligns the pictures automatically is not trivial and may even involve some enhancements to the game code itself. Because It's to difficult to describe it here I will just focus on single-picture objects and they do not need a <I>direction list</I>.<P>
This object is one of the few that has different graphics for different weather. The picture #985 has few snow on it and picture #1024 has much snow on it. So I mark these weathers at the next question of MAKEOBL. <P>
Now I can select the picture #38 and after choosing to include no more pictures I have to specify the pictures for the other weathers.<P>
The ID will, as already mentioned, be 76.<P>
As name of the object I choose obviosly "wreckage".<P>
The variables that describe how the object affects the terrain it is build on are easier than they seem to be at first sight. The variable called <I>terrain AND</I> determines which terrain bits are passed "through" the objects and which not. The next variable called <I>terrain OR</I> sets new bits. A road for example does have all bits set in <I>terrain AND</I> and the road bit in <I>terrain or</I>. This means that all characteristics of the terrain (like <I>lowland</I> or <I>swamp</I>) will be set and the field will additionally have the road attribute. All vehicles that could enter the field before there was a road can enter it now and additionally all vehicles that could not enter it before but may drive on roads can enter it now too. Another example: mountains. They do not have any of the <I>terrain AND</I> bits set except <I>pipeline</I> or <I>powerline</I> (if I remember correctly...) but have the <I>high mountain</I> bit set in <I>terrain OR</I>. If the basic terrain has the lowland or swamp or whatever bit set this bits will not be passed through the mountains. A unit that may drive across normal lowland may not drive over mountains (except when <I>high mountains</I> are explicitly set in the vehicle definition). <P>
Since out wreckage should be quite difficult to be entered (like mountains) it does not pass any bits through (I unmark all <I>terrain AND</I> bits) but it adds the <I>installation</I> bit (that I set in <I>terrain OR</I>) which enables a trooper to enter it.<P>
Some more notes about these terrain bits (since it seems quite difficult to understand for non-programmers), I hope to add a really good explanation of the system sometime:
<UL>
<LI>Each field has one set of bits which are calculated from the terrain type and all objects
<LI>Units ONLY evaluate this single set of the field
<LI>The object's AND and OR sets are only used to construct the set of the field.
<LI>Each bit (<I>road</I> for example) is independent of all other bits, as well in the construction as in the later evaluation
<LI>For objects: AND is used to remove bits from the terrain or underlying objects (default for AND is "all bits are set", all bits that are not set there will be filtered out ( 1[terrain] AND 1[object_and] = 1 ; 1 AND 0 = 0 )<BR>
OR is used to add bits ( 0 OR 0 = 0 ; 0 OR 1 = 1 )
</UL>
Numerical values describing a terrain can be modified by a object in two ways: A value (which can be negative) may be added to them or they are replaced by a new value. The values of the object are called <I>name_plus</I> and <I>name_abs</I>. If <I>name_abs</I> is specified then <I>name_plus</I> will be ignored. If <I>name_abs</I> should be ignored it must have a value of -1 . Having said that the usage of the next variables should be clear.<P>
Since units may seek cover in the wreckage and can sneak attack other vehicles I assign an <I>attackbonus_plus</I> of 8 (which means a unit attacking from there has twice the normal strength) and a <I>defensebonus_plus</I> of 12 to the object.<P>
Units may hide in the wreckage so I set <I>basicjamming_plus</I> to 16.<P>
To make destroying it quite difficult it gets an armor of 1400.<P>
The height determines the order in which objects, vehicles and buildings are painted on the map. The objects with the lowest height are painted first and the ones with the largest height are painted last. The order is:
<OL>
<LI>objects with height 0 - 29
<LI>deep submerged vehicles
<LI>objects with height 30 - 59
<LI>submerged vehicles
<LI>objects with height 60 - 89
<LI>floating vehicles
<LI>objects with height 90 - 119
<LI>ground based vehicles
<LI>objects with height 120 - 149
<LI>vehicles on low level flight
<LI>objects with height 150 - 179
<LI>vehicles on medium level flight
<LI>objects with height 180 - 209
<LI>vehicles on high level flight
<LI>objects with height 210 - 239
<LI>orbiting units
<LI>objects with height 240 - 255
</OL>
<P>
The wreckage should not be built by construction vehicles so the production and removal costs will not be evaluated which means I can leave them to 0.<P>
Now the fields the object can be put on must be set. It is the same system that is already used by buildings and vehicles so I don't describe it again. The the wreckage can only be build in the mapeditor I can leave it up to the map designer to decide where it is useful and where not. I set all the bits in <I>the object can be build on</I> and none in the following 3 variables.<P>
Since it is a single-picture object the variable <I>link automatically with neighboring fields</I> must be set to <I>NO</I>. There are some graphic errors here so be careful that <I>NO</I> is really the field that is bright white text on blue background.<P>
Because most vehicles will not be able to enter the wreckage it is quite useless to enter complex <I>movemalus</I> values here. Just one <I>movemalus_plus</I> value of 12 will be enough and no <I>movemalus_abs</I> values.<P>
This object is finished now. But there are two other graphic sets (with <I>dry</I> graphic #39 and #40) that are quite similar. They should get the same parameters, only a different picture. The one with graphic #39 will get the ID of 77. I now copy the file <TT>wreck076.OBL</TT> I just created to <TT>wreck077.OBL</TT>, start <TT>MAKEOBL.EXE</TT> and edit the file <TT>wreck077.OBL</TT>. Of course I select now <I>change picture</I> and select the new pictures #39, #986 and #1025. I change the ID to 77 and than I just hold <enter> until the program finishes to confirm all other parameters. <P>
The object <TT>wreck078.OBL</TT> can be made exactly the same, just with ID 78 and pictures #40, #987 and #1026.
</BODY>
</HTML>
