# Advanced Strategic Command

documentation

## Building new Items with Battle Isle Graphics

Update October '99:

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.

If you want to help us by creating more "replacement graphics", please contact us!

The rest of this document has not been updated to reflect the new graphics system.

### Index

Creating terrain
Creating vehicles
Creating buildings
Creating objects

### Motivation

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.

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.

Suppose you want to import a map from Battle Isle and get the following message:

  The following terrain fields could not be found: 130
  The following objects could not be found: 237, 42, 239, 236, 1331, ...

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.

To correct the problems, you have to manually create these objects and terrain. If you have not done so already run the program `BI2PCX.EXE`. It generates a huge image called `BI_GRAPH.PCX` that contains all graphics of Battle Isle and some information if they are used in ASC or not. Running `BI2PCX /INDEX` will generate additionally an image that explains how to read the parameters given with the images.

If you intend to import more then one or two graphics it is probably a good idea to print the image `BI_GRAPH.PCX`. 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 `BI2PCX /WIDE` to generate an image with 10 columns instead of 5.

### Creating a new terrain

I will now describe how to create a new terrain. This will be a step to step walk through.

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 editors.htm for more information about IDs. For this example we will use 360 as the id.

To make a terrain type you have to start `MAKETRR.EXE`. 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 SWMP0360 would be an appropriate name. After that you have to enter the id (400) and a description for the terrain, for example Dense Swamp or Mangrove 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 dry (standard), heavy rain, few snow and lot of snow and press enter. Do never use fog because fog is not completely implemented yet and does not work like rain and snow at all.

The following block will be repeated for each weather:

> Since we are making hexagonal fields the next question can be ignored: the program does not use rotated hex fields at all. Just mark 0 ( up ) and continue. The next question should be clear: we want to use pictures of Battle Isle. Select your picture and confirm your selection.

> 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 swamp thick.

> Most terrain don't have a Defense bonus and Attack bonus 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 :-)

> Basic jamming 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.

> The number of movemali 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.
> 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:

> - number of movemali : 8
> - default : 24
> - light tracked vehicle : 20
> - medium tracked vehicle : 16
> - large tracked vehicle : 18
> - light wheeled vehicle : 24
> - medium wheeled vehicle : 20
> - large wheeled vehicle : 22
> - trooper : 14

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 forest for the lot of snow weather) and the movemali should also be better when its frozen:

- number of movemali : 8
- default : 20
- light tracked vehicle : 16
- medium tracked vehicle : 14
- large tracked vehicle : 14
- light wheeled vehicle : 20
- medium wheeled vehicle : 16
- large wheeled vehicle : 16
- trooper : 13

That was all ! Now there should be a file named `SWMP0360.TRR` on your hard disk that can immediately be used in the mapeditor.

If you intend to make quite a lot of terrain and use generic parameters for them you should not use the program `maketrr.exe` 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 `makebdt?.cpp` files in the `source\tools\` 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.

### Creating vehicles

This is a walk through on creating a ditching machine.

To make a vehicle type you have to use `MAKEVEH.EXE`. After choosing to create a new vehicle we have to enter the filename, `G_DITCH` is a good name. I recommend to start all filenames for ships with `S`, all Aircraft with `A` and all ground based vehicles with `G`. 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 `CONVTANK`, which is in the source distribution since it is useless to non-programmers).

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.

Having confirmed that we chose the correct picture we have to enter the ID for the vehicle. See id.htm 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".

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 here.

For the production cost (and some other parameters later too) we have to take a look at the vehicles we already have. Use `printtank` to generate lists containing all important vehicle parameters. The file `tanks5.txt` 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.

The regio is of course a land based vehicle so the only height to select is ground level. 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 wing in groundeffect vehicle) 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!

For each height we have to enter the speed of the unit. The way distances are measured in ASC is described in the readme. Out regio should move 5 fields per turn on road so 50 is the value we have to enter here.

The regio is a tracked vehicle that is neither very large nor very small so we select medium tracked vehicle 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 default.

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 (Terrain the unit can drive on). Our ditching machine should be able to drive across normal lowland, road, railroad, runway, hard sand, soft sand, small rocks, mud, snow, deep snow, small trench, ditches of course and swamp thin. Note that we do not select pipeline 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.

The next variable is described as ALL these selected terrain-bits are necessary for the unit to drive there. 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.... :-)

The variable described as NONE of these bits must be set is explained by all ships (except icebreaker) must have the ice/snow bits set here). 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.

The last terrain question is called the unit dies on ... ( only if it cannot enter, see entries above) with the example of most land based units should have the water-bits set here. 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.

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.

To choose the weight of 56 I checked the file `tank9.txt`.

Since our ditching machine cannot load anything we enter 0 for max load.

Fuel consumption: 14

Since the digging of ditches is not free of charge lets set the fuel tank to 1200. Only one unit has an energy tank, the generator vehicle, for all other vehicles including our regio a 0 must be entered for energy tank. Since the construction of ditches requires some material (the amount is specified in the ditch object `ditch.obl` ) our ditching machine get a material transportation capacity of 450.

A ditching machine should not get any weapons so we skip the weapon questions. But I explain them anyway:

For each weapon the following parameters have to be set:

> One weapon type out of 9 available types must be set. Cruise missile, mine, bomb, air - missile, ground - missile, torpedo, machine gun, cannon and service are available. Never use more than one of these types for a single weapon! Additionally the weapon can have the shootable and the ammunition refuel attribute. If the weapon should be able to be fired the shootable bit must be set. An ammunition transport does not have this attribute. Instead it has the ammunition refuel bit set so it is able to equip other vehicles with ammunition. It is possible to have both the shootable and the ammunition refuel. The service 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 ammunition transport must have one service weapon with a distance of 8 - 15 and ground level as destination and usable on heights (see next paragraphs). An aircraft carrier must NOT have a service 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 ammunition refuel bit to equip the loaded units with ammo. A weapon with ammunition refuel capabilities on a vehicle that does neither have a service weapon nor is a transport is completely useless. The repair and refuel functions use the service weapon too. A service weapon should always have a range of one field (not because it would screw up the program but because it would severely spoil gameplay).

> Note that you must also specify a strength for mines since the power of mines is determined by the vehicle that employed them.

> The aims field specifies on which levels of height a vehicle can be attacked.

> The weapon can be shot from 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.

> The next two variables specify the max distance and the min distance the weapon can be fired. Check out the readme for more information on the distance measurement.

> Strength at min distance and strength at max distance set the strength of the weapon. Strength at min distance must always be equal or greater than strength at max distance. 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 min and max distances must be 8 and 12 for such a weapon). Originally we did not specify a strength at max distance 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 min and max distance is not linear interpolated but each weapon type has its own distance->strength function that is now scaled to match the min strength value.

> The number of shots the vehicles can do with each weapon is set by the ammo variable.

> A recently added feature is the modification of the weapon strength by the height difference. In ASC there are eight levels of height:

> - deep submerged
> - submerged
> - floating
> - ground based
> - low level flight
> - medium level flight
> - high level flight
> - orbit
> For the height-difference-calculation ground based and floating are set to be the same. The reason for them beeing two different heights are others that I won't discuss here.
> So for an attack their may be 13 possible difference of height, from -6 ( attacker orbiting and target deep submerged) to 0 ( both have the same height, regardless where ) to 6 ( attacker deep submerged and target orbiting ). For each of these 13 height difference you can specify a percantage of strength.

> 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.

Initiative is only needed for vehicles having weapons. The regio gets a 0 here. Refer to the chapter about the attack formula in the readme for more information how this values is used. 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.

The functions define what the unit is able to do. At the time of writing we have the following functions available:

sonar
  The vehicle is able to see submerged submarines
paratrooper
  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!
mine layer
  The vehicle is able to put mine. It needs also a correct weapon of type mine !
conquer buildings
  The vehicle is able to conquer buildings. Refer to the chapter in the readme for more details about conquering.
trooper
  Troopers may enter any building and any transport. They should usually also be able to conquer buildings so they should get the conquer buildings attribute too.
repair vehicle
  The vehicle can repair other units. There are two possibilities to use this features:
  - if the repair vehicle can load other units it can repair the loaded units. The aircraft carrier can do this for example.
  - if the repair vehicle has a service "weapon" it can repair vehicles that are standing next to it, like the repair ship.
  It is no problem build a unit that can do both! Note that a repair vehicle must have sufficient material and fuel tanks!
view satellites
  Like sonar but for seeing vehicles that are in orbit.
construct buildings
  The vehicle can construct buildings. Make sure it has enough material and fuel capacity !
view mines
  The vehicle can see enemy mines. All mine layer should have this bit set.
refuel units, refuels material
  These two functions work like the repair vehicle function.
icebreaker
  A unit that has this feature does build a special object broken ice if it moves across snow or pack ice. The unit must have the appropriate bits set at the terrain 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 broken water 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.
makes tracks
  Although it seems that these functions have nothing in common the makes tracks features works nearly identically to the icebreaker function. The difference is that it puts the track object on the fields the unit drives through instead of the broken ice object. The track have no other purpose then the optic one. They are put only on fields that have the tracks possible bit set. At the time of writing we do not have a track object for the hexagonal version too. Most land based vehicles should have this bit set.
drill for mineral resources manually, search for mineral resources automatically
  The vehicle is able to spot resources in the earth. Check out the chapter about resources in the readme for more information about the resource system in ASC.
sailing
  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!
auto repair
  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 chapter about repairing in the readme for more information about this. Automatic repair should be preferably used in later classes that have to be researched first.
generator
  is only used by one particular unit, the generator vehicle. 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.
kamikaze only
  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.
Entries marked with an exclamation mark ( ! )
  are not used any more and reserved for future expansion. Do not use them.

If a unit has the ability to search for resources (which our regio has not) you have to enter the digrange. 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.

The view 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 view and jamming works take a look at the chapter about view in the readme. Our regio does not have make any jamming so we confirm the values of 0.

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 number of classes and use the standard research values 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 here. 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 functions variable for the vehicle we have to enable autorepair! The values for the first class will be the standard values and the autorepair 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 autorepair bit in the functions for this class must be enabled.

Max windspeed on water is only available for units that have ground based or floating 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 harbor attribute. This functions works for ground base too so that some vehicles may be blown off a bridge. But this should be more a gag for one or two ground based 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.

The last variable we have to define before our regio is finished is the definition of the objects it can build: the unit can build the following items of the object layer. 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 ditch.obl. 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.

That was it! Now we have a file called `G_DITCH.VEH` on the hard disk that can be used in the mapeditor.

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: http://users.aol.com/mikegalope/engineer2.htm#MDK (the main page for this site is Military Equipment of the Former USSR & Russia ).

### Creating buildings

In this walk through I describe how I made the depot - building.

First I checked which graphics the depot should use: The Battle Isle pictures #44, #46, #47 and #49. The editor buildings is`makebld.exe`.

After choosing to create a new building we have to enter the filename for our building: `DEPOT`.

The editor now asks how many construction steps the building should have. Since we have only one set of graphics for the building we have to confirm the 1.

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.

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 dry (standard) and select for the next question the use of Battle Isle graphics.

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 more pictures with 'N'. The program now asks us to click on the entry for the building , the powerline connector and the pipeline connector. Check out the readme for more information about the resource system with its pipelines and powerlines.

As ID for the building I choose 54 and "depot" as name.

The production costs are 2000 material and 1500 fuel. That is quite cheap for a building but on the other hand a depot cannot do very except storing and repairing vehicles.

It gets an armor of 1800

The maximum size of units that may enter the building is not restricted so we enter the maximum value of 65535. Loadable units specifies on which heights a unit must be to enter. The airport has ground level selected here since the planes do not fly into the hangar. And our depot gets this setting too.

The next question asks the unitheightreq (a unit must be able to reach in order to enter). The airport for example has low level flight 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 ground level too.

Units that may NOT enter 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 orbit.

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 submerged, floating and orbiting buildings are ok. The depot we are designing is just ground level based again.

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 (Terrain the building can be build on). Our depot should be able to stand on normal lowland, hard sand, soft sand, small rocks, small rocks and snow.

The next variable is described as ALL these selected terrain-bits are necessary for the unit to drive there. 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.... :-)

The variable described as NONE of these bits must be set is explained by all ships (except icebreaker) must have the ice/snow bits set here). 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.

The last terrain question is called the building dies on ... ( only if it cannot enter, see entries above) with the example of most land based units should have the water-bits set here. 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 water and deep water can do any harm to it, so we mark these two bits. This means that shallow water does no harm to the building.

The maximum amount of resources the building can store has to be specified for both the ASC resource mode and the BI resource mode (see the readme for more info). In the ASC mode 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 BI resource mode 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.

The depot should not be able to produce energy, material or fuel so fuel maxplus, material maxplus and energy maxplus should be set to 0. The efficiencies for material and fuel 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 fuel efficiency to 1024 and material efficiency to 0 the power plant would burn as much fuel as it produces energy. If you set fuel efficiency to 2048 it would burn only half the fuel to produce the same energy output. If you set fuel efficiency and material efficiency to 1024 it would burn fuel AND material to produce energy.

We set technology level to 0 so that the depot is available just from the start of the game. See the documentation for `maketech.exe` for an explanation of the research system.

The depot should not be able to research anything so max research points should also be set to 0.

The last variable we have to set determines what the building is able to do. The following functions are available:

HQ
  is not used at the moment. Perhaps some victory conditions will be sometimes defined using it.
training
  A building with the training attribute is able to increase the experience of units that are loaded at the cost of ammunition.
refineries
  Are not used at the moment too. The idea was to convert resources with it.
vehicle production
  The building is able to produce vehicles. The vehicles that can be produced have to be set in the map editor for each factory.
ammunition production
  Does not need any explanation, does it ?
energy production, material production, fuel production
  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.
repair facility
  The building is able to repair vehicles.
recycling
  is an efficient way to gain the resources of a vehicle. See the readme for more details about recycling.
research
  should be clear.
sonar
  enables a building to spot submerged submarines. See the readme for more details.
wind power plant
  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 energy production bit set in order to function properly.
solar power plant
  The energy the building produces is generated by solar cells. The amount of energy production depends on the weather. The building must have the energy production bit set in order to function properly.
conventional power plant
  The energy the building produces is by burning other resources. The building must have the energy production bit set in order to function properly. It must also have a value for fuel efficiency and / or material efficiency.
mining station
  The resources the building produces are taken from the ground. The building must have the fuel production bit or the material production bit set in order to function properly. It must also have a value for fuel efficiency or material efficiency.
external loading
  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.

The only function our depot should have is the repair facility.

It should not have any jamming 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).

Now the depot is finished and ready to be used!

### Creating objects

In this walk through I describe how I made the wreckage object which uses the picture #38, the wreckage of the "Liandea" in the BI2 scenery campaign.

After checking with `HEXIDS.EXE` I choose 76 as the ID for it. So after starting `MAKEOBL.EXE` and selecting create a new objects I enter wreck076 as the filename for it.

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 direction list.

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.

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.

The ID will, as already mentioned, be 76.

As name of the object I choose obviosly "wreckage".

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 terrain AND determines which terrain bits are passed "through" the objects and which not. The next variable called terrain OR sets new bits. A road for example does have all bits set in terrain AND and the road bit in terrain or. This means that all characteristics of the terrain (like lowland or swamp) 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 terrain AND bits set except pipeline or powerline (if I remember correctly...) but have the high mountain bit set in terrain OR. 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 high mountains are explicitly set in the vehicle definition).

Since out wreckage should be quite difficult to be entered (like mountains) it does not pass any bits through (I unmark all terrain AND bits) but it adds the installation bit (that I set in terrain OR) which enables a trooper to enter it.

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:

- Each field has one set of bits which are calculated from the terrain type and all objects
- Units ONLY evaluate this single set of the field
- The object's AND and OR sets are only used to construct the set of the field.
- Each bit (road for example) is independent of all other bits, as well in the construction as in the later evaluation
- 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 )
  OR is used to add bits ( 0 OR 0 = 0 ; 0 OR 1 = 1 )

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 name_plus and name_abs. If name_abs is specified then name_plus will be ignored. If name_abs should be ignored it must have a value of -1 . Having said that the usage of the next variables should be clear.

Since units may seek cover in the wreckage and can sneak attack other vehicles I assign an attackbonus_plus of 8 (which means a unit attacking from there has twice the normal strength) and a defensebonus_plus of 12 to the object.

Units may hide in the wreckage so I set basicjamming_plus to 16.

To make destroying it quite difficult it gets an armor of 1400.

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:

1. objects with height 0 - 29
2. deep submerged vehicles
3. objects with height 30 - 59
4. submerged vehicles
5. objects with height 60 - 89
6. floating vehicles
7. objects with height 90 - 119
8. ground based vehicles
9. objects with height 120 - 149
10. vehicles on low level flight
11. objects with height 150 - 179
12. vehicles on medium level flight
13. objects with height 180 - 209
14. vehicles on high level flight
15. objects with height 210 - 239
16. orbiting units
17. objects with height 240 - 255

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.

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 the object can be build on and none in the following 3 variables.

Since it is a single-picture object the variable link automatically with neighboring fields must be set to NO. There are some graphic errors here so be careful that NO is really the field that is bright white text on blue background.

Because most vehicles will not be able to enter the wreckage it is quite useless to enter complex movemalus values here. Just one movemalus_plus value of 12 will be enough and no movemalus_abs values.

This object is finished now. But there are two other graphic sets (with dry 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 `wreck076.OBL` I just created to `wreck077.OBL`, start `MAKEOBL.EXE` and edit the file `wreck077.OBL`. Of course I select now change picture 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.

The object `wreck078.OBL` can be made exactly the same, just with ID 78 and pictures #40, #987 and #1026.