Game FAQ User interface Editor Linux problems Community documentation Knowledgebase Units Buildings

A unit has three events which play sounds: movement, firing weapon and destruction. ASC has two methods for specifying these unit sounds.

Individual Sounds

Here is an example of a unit having individual sounds:

vehicletype {

} vehicletype

Generic Sounds

It is possible to have define the sounds for whole groups of units. This is done in the file sounds.asctxt

A simple example is:

shoot.cruisemissile.files = weapon00.wav

This causes the file weapon00.wav to be played when a cruise missile is fired.

It is possible to define more than one sound file:

shoot.cannon.files = weapon07.wav weapon07b.wav shoot.cannon.labels = default very_big_cannon

If a cannon is fired, weapon07.wav will be played. But some units may specify that their cannon should play weapon07b.wav . This is done by adding Sound = very_big_cannon to the weapon definition. The Sound is the same entry as the one where a filename for an individual sound is specified. The distinction between fileName and soundLabels is done by looking for a dot (.) in the entry. If there is a dot, the entry is treated as filename; if there is no dot, it's a label.

These alternative sounds can also be specified for unit movement ( MovementSound = sound_label in vehicletype ) and the kill sounds ( KillSound = sound_label in vehicletype ).

Since ASC 2.0 it is possible to have a special beginning sound, which is useful for unit movement:

First the enginestart.wav will be played, once this is finished the sound move_jet.wav will be played and looped until the unit movement is finished.

Also new in ASC 2.0 is the usage of height specific sounds. The level of height on which the unit started its movement will be used for the whole movement operation. Just use these names as labels for unit sounds: "deep_submerged", "submerged", "floating", "ground_level", "low_level_flight", "medium_level_flight", "high_level_flight", "orbit" .

Sound Formats

In ASC2 the sound files can be in many different formats, with WAV, MP3, OGG and FLAC being the most common ones. The usage of OGG is strongly recommended, as it is as space efficient as MP3, but works on all systems, which MP3 does not (some Linux distributions don't come with an MP3 decoder by default to avoid its license fees).

Last change: Mon, 2006-08-14 3:38

how to decompress the data files

The ASC data containers (*.CON) are compressed archives which can be decompressed with a tool that comes with ASC. The Windows-Version is called DEMOUNT.EXE and is part of the editor package, the unix version is called asc_demount and is compiled and installed together with ASC itself.

If you are familiar working on the command line, you just need to know that when you run demount datafile.con it extracts all files to the current directory.

For Windows users who are not familiar with working on the command line, here's are the steps to extract a data file:

  1. create a new directory where the extracted files are going to be placed. In this example I'll use D:\ASC\DATA-FILES
  2. open a command prompt (sometimes called DOS prompt)
  3. type D: and hit enter to change your drive to D:
  4. type cd "asc\data-files" to enter the directory we just created (the quotation marks are used because the directory may have spaces in its name)
  5. open the Windows Explorer and locate the directory where you installed the ASC editor package. In a subdirectory called tools there is the file demount.exe
  6. use the mouse to drag this file into your command window
  7. enter a space in the command window
  8. now find the ASC data container that you want to extract and drag it into the command window too
  9. now hit enter in the command window.
  10. that was it. Now all files contained in the data container have been extracted to D:\ASC\ASC-FILES

If you get an error message that a DLL file (for example SDL.DLL) could not be found, you can either:

Last change: Thu, 2003-07-24 1:55

Objekttypen: Wertebereich für Feldmodifikatoren

Zur Veränderung der Werte Attackbonus, Defensebonus und Jamming gibt je zwei Variablen: *_abs und *_plus.

*_abs ersetzen den borhanden Wert, *_plus modifizeren ihn. Wenn *_plus verwendet wird muss *_abs = -1 sein.

Alle Werte werden zum Nenner 8 angegeben. Ein Defensebonus von 8 hat also die gleiche Wirkung wie eine Verdoppelung der Panzerung.

Bei *_plus sind negative uneingeschränkt möglich.

Jamming_abs darf (abgesehen vom Sonderfall -1) keine negativen Werte annehmen, was auch keinen Sinn machen würde.

Bei Attack/DefenseBonus sind negative Werte erlaubt, wobei -1 der bereits erwähnte Sonderfall ist. Sinnvolle negative Werte sind also -2 bis -7 . Kleinere Werte als -7 sind nicht erlaubt und machen auch keinen Sinn, da dadurch die Angriffs- bzw. Verteidigungswerte <= 0 würden.

Ein DefenseBonus von -6 hat die Gleichung Wirkung wie eine Reduzierung der Panzerung um 75%.

Last change: Sun, 2003-01-26 7:30

Richtlinien für die Campaign-Entwicklung

Die Karten der Campaign sollen zusammenhängend sein. Dies sei am Beispiel Karte2 + 3 beschrieben: In Karte zwei erobert man ein Hauptquartier am rechten Rand der Karte mit einigen Gebäuden drumherum. In Level 3 ist genau dieses HQ mit den gleichen Gebäuden, Objekten und Bodentypen am linken Rand wiederzufinden. Dies erreicht man am einfachsten dadurch, dass man sich die vorherige Karte in den Editor einläd, diese mit "Resize Map" entsprechend abschneidet und am anderen Ende erweitert.

Es gibt bis auf weiteres nur zwei Parteien: Der menschliche Spieler Rot sowie der Gegner Blau. Das Spiel sollte schließlich Amerikaner-Kompatibel sein: Es gibt nur Gut und Böse. Und der Spieler ist natürlich per Definitionem der Gute.

Die Hauptvorstoßrichtung ist am Anfang von Westen nach Osten. Natürlich kann davon in Grenzen abgewichen werden, mal einen Abstecher nach Süden oder so; aber eine Umkehrung der Vorstoßrichtung sollte gut begründet werden können. Natürlich kann sich diese Vorstoßrichtung im Laufe der Campaign ändern, insbesondere wenn man auf einer anderen Insel / Kontinent gelandet ist. Aber wichtig ist, dass der Spieler ein Gefühl für einen "Vorstoß" erhält und die Karten nicht kreuz und quer gehen.

Für die Wahrung eines einheitlichen Aussehens bitte für Grafik und Objekte soweit möglich die ASC2 Grafik nutzen, nicht die Grafiken aus der ASC.GFX. Letztere lassen sich durch Anwählen des "GFX graphic system" Filters ausblenden.

Die Entwicklung einer neuen Campaign-Karte sollte, solange ich die Planung mache, in mehreren Schritten erfolgen, nach denen eine Rückmeldung mit den anderen an der Campaign-Entwicklung beteiligten Personen stattfindet: # Entwurf der Landverteilung (also wo Land, Wasser und Berge und Wald sind). Noch keine Ausarbeitung wie Küsten oder Geröllobjekte. Missionswichtige Gebäude sollten positioniert, aber noch nicht parametrisiert sein # Ausarbeiten der Karte, Positionierung der Einheiten, Objekte, sonstigen Gebäude usw. # Feintuning der Karte insbesondere im Hinblick auf das Verhalten der KI. Dies ist eine Arbeit, die anfangs ich (Martin Bickel) machen werde, da noch Eingriffe in den KI-Code notwendig sein werden

Der jeweils aktuelle Stand der Karten ist HIER verzeichnet:

  1. first.map
  2. Paybacktime.map
  3. asc003.map
  4. asc004.map
  5. asc005.map
  6. asc006.map
  7. asc007.map
  8. asc008.map

Beim Erstellen neuer Karten bitte darauf achten, dass die aktuelle Version der vorhergehenden Karte als Anschluß-Karte genutzt wird!

Einzelne ASC-Funktionen und Elemente werden der Reihe nach in der Campaign eingeführt und anschließend verwendet. Jede Karte sollte irgendetwas neues gegenüber den vorhergehenden Karten bieten.

Noch nicht verwendete Features:

Zur Generierung von Namen, z.B. für Missions-Briefings oder Gebäude, kann der Fantasy Name Generator verwendet werden.

Last change: Sun, 2003-06-22 14:39

parametrise Resource capabilitiies of buildings in editors

For a introduction to resource management, see Article 22

BI Resource Mode

The amount of resources that is produced every turn has to be set in the map editor when designing the map and is not affected by anything else. Any building can produce any amount of resources. The maximum storage capacity is defined in the building type file and should usually be extremely high, to be practically infinite.

ASC Resource Mode

The ASC Resource Mode is much more complex. There is no global pool for any resource. Every transfer between buildings has to be done with pipelines.

There are several different building functions that are resource related, which are defined for the building type:

It is not possible to combine several of these functions in one building type.

Solar power plants produce resources without consuming any other, usually (but not necessarily) energy. The amount of produced resources is the maxplus setting of the building multiplied with a factor for the weather. This factor is 100% for clear weather, 50% for rain, 25% for heavy rain, 75% for snow and 37.5% for much snow.

Wind power plants produce resources without consuming any other, usually (but not necessarily) energy. The amount of produced resources is the maxplus setting of the building multiplied with the power of the wind. At the max wind power of 255 it produces 100% of energy.

Mining stations extract resources from the ground around their entrance, field-by-field. Since only material and fuel can be stored in the ground only these can be extracted. With increasing distance from the entrance the amount of extracted resources per turn gets less and less. The bars on the left side of the mineral resources page in the buildings window shows this. The maximum distance to extract resources from is 10 fields.

Mining stations sometimes consume other resources in order to operate. The resources they consume is set in the mapeditor in the plus field as negative values. If this resource is unavailable, the station cannot fulfill its task. If the resource is available, but you want to conserve it, you can adjust resource consumption in the mining dialog. Of course, setting lower rate of consumption results in reduced output.

The efficiency ( = resources_stored * 1024 / extracted_resources ) is specified there also. The higher the efficiency, the less resources are extracted from the ground to produce a given output. Default value for effeciency should be 1024. You can find some additional notes about mining stations at the end of this text.

Matter converters use one kind of resources to produce another. You can build quite a variety of different converters. Power plants consume fuel to produce energy, a fusion power plant could use material for this. A refinery could convert material to fuel. It is also possible to produce two resources out of one, or vice versa cosume two resources to produce one.

Like mining stations the resources that are beeing produced are defined by using positive values in the various plus fields, while resources that are consumed are identified by negative values. The maxplus field of the building type defines the upper limits. In the mapeditor the limits for the buildings may be decreased by settings the maxplus fields there. The plus field defines the initial production rate which can be changed in the game on the appropriate page of the building window.

Notes on mining

The relative amount of resources that is still in the ground is displayed in the right graph of the "mineral resources" page in the mining station. If every field of the ring that has a given distance contains the maximum possible resources, the bars have maximum height. Since there are more fields at a far distance, the absolute amount of resources in the greater distances is usually much greater. This is indicated by the single lines which display the absolute amount of resources. Note that the bars and the lines are differently scaled.

You can search mineral resources with some units, the radius for the search is specified in the vehicle type. There are two functions a unit can have: "drill for mineral resources manually" and "search for mineral resources automatically".

The mining stations can see the mineral resources to and at their current mining position too.

In the mapeditor the pull-down menu Global / Toggle Resource View toggles the way in which resources are displayed on the map:

ASC internals The following variables exist to describe the resource system. Unless otherwise noted they all contain fields for each of the three resources: energy, material and fuel.

Building type(defined in .asctxt file) : - ASC tank: the maximum storage capacity in ASC mode - BI tank: the maximum storage capacity in BI mode - maxplus: see above explanation - efficiency material: only for mining stations, see above explanation - efficiency fuel: only for mining stations, see above explanation

Building instance (set by mapeditor): - plus: only used in ASC mode - maxplus: only used in ASC mode - current storage - BI plus: only used in BI mode

Each field on the map: - material - fuel - resources visible: the amount of resources that is displayed is not necessarily the amount of resources in the ground, it is the amount that was there when you checked the field the last time.

The map itself - energy and fuel for each player in BI resource mode

Last change: Mon, 2003-01-27 13:04

terrain properties

The following terrain properties are sorted by their carrying capacity:

  1. water
  2. swamp
  3. morass
  4. mud
  5. lowland
  6. road

If a terrain should be inaccessible to all units (except airplanes), just don't set any bit.

Last change: Wed, 2003-04-02 9:52

syntax of .ASCTXT files

Many of the data ASC uses is stored in .ASCTXT files. These are simple text files which you edit with any decent text editor. Since some of the existing files may have unix line ending convention, the standard Windows editor Notepad is not a good choice (you can try it, but if you see garbage you know what's wrong...). UltraEdit is a nice editor, but it is shareware.

Related links:

All ASCTXT have the following syntax:

TypeName {

} TypeName

Typename is for example VehicleType, BuildingType, ObjectType or others.

In the TypeName block can be assignments and comments:

VehicleType {

} VechicleType

An Assignment can cover more than one line, this is useful for long texts:

VehicleType {

} VechicleType

The assignments are often grouped in blocks:

VehicleType {

} VechicleType

You could also write:

VehicleType {

} VechicleType

which is exactly the same, but the first variant is usually easier to read.

Last change: Wed, 2003-04-02 9:41

creating building graphics

The following template can be used for designing buildings:

(URL: building-coordinates )

This is the maximum size that a building can have in ASC.

The coordinates of the fields have to be entered in the building definition file.

If the building is constructed in several stages, you have to specify one image for each construction stage. These images have to be in the same file, but at different coordinates. The first image is at coordinates x=0/y=0 (just like above image), the second image starts at x=500/y=0 ; the third one at x=1000/y=0 and so on.

If a building is destroyed, it can leave rubble objects behind. This is done by adding:

RubbleObjects = true Rubble {

}

to the building definition file. For each field of the building specify its coordinate and the ID of the object that will appear when the building is destroyed. These objects are just ordinary objects.

The image file must have 8 bit color depth. Depending on the owner of the building, the colors 16 - 23 (red colortone) will be shifted. For the second player these colors will be shifted to 24 - 31 (blue) and so on. The color #255 is transparent.

Last change: Wed, 2003-04-02 10:44

creating item selection filters for the mapeditor

Items like VehicleTypes, ObjectTypes, BuildingTypes and TerrainTypes can be selected through lists in the mapeditor. To make selection easier, you can restrict the displaying of these items through filters, for example to display only VehicleTypes that belong to a certain UnitSet.

These filters are defined by .ASCTXT files and have the following form:

itemfilter {

} itemfilter

An activated filter will inhibit the selectability of the items it covers. The activated variable specifies the status of the filter after the editor has been started.

Last change: Sat, 2003-02-01 7:46

Definition des Vernetzungsverhaltens von Objekten

Border

Für Objekttypen gibt es einen neuen Eintrag namens "NetBehaviour". Dieser kann keine, eine oder mehrerer der folgenden Schlüsselworte beinhalten:

Bedeutung sollte bei den meisten Fällen klar sein. AutoBorder ist z.B. für Straßen und Schienen, die in möglichst grader Linie in den Kartenrand laufen sollen. NetToBorder ist für Wald, der sich flächig mit dem Rand verbinden soll.

Der alte Eintrag "NoSelfChaining" wird zwar nachwievor ausgewertet, wenn er vorhanden ist. Aber beim Neuerstellen oder editieren existierender Objekte sollte wenn möglich auf das neue System umgestellt werden..

Nets of objects Some objects like roads or pipelines connect automatically to each other to form a net instead of staying as independent graphics. Such an object must have 64 different graphics. If it is symetrically the number can be reduced by flipping the picture to 24 different images.

But the object must contain all 64 images. The position of each is determined by the sides that connect to another object. Each side has a number:

These number are than added. This picture for example

has to be used on position 1 + 4 + 16 = 21 . Note that the first picture is #0 and the last #63 .

Last change: Sat, 2004-05-29 13:03

Tricks zum Erstellen von Gebäude- und Fahrzeuggrafiken

ASC verwendet die Palette. die im Bild ascpalette.gif dargestellt ist. Wie mat sieht, existieren dort zwei rote Farbverläufe sowie noch ein weiterer, einzelner Rotton. Für die Eigentümer-Markierung der Gebäude werden die Farben des ersten Farbverlaufs entsprechend verschoben, also durch die Farben des blauen verlaufs für den zweiten Spieler, dem gelben Verlauf für den 3. Spieler usw. ersetzt. Die Spielermarkierung muß ausschließlich diese Farben des ersten rot-Verlaufs verwenden.

Wenn mat nun ein Truecolor-Gebäude hat und das auf diese Palette konvertierst, schert sich das Bildbearbeitungsprogramm einen Dreck darum, von welcher Position es jetzt die Rottöne nimmt. Es nimmt ein paar aus dem ersten Verlauf, ein paar aus dem zweiten Verlauf, mit dem Ergebnis, daß beim blauen Spieler immer noch rote Pixel drin sind (nämlich die, die eine Farbe aus dem zweiten Rotverlauf haben).

Um nun ein Gebäude erfolgreich so zu konvertieren, daß es mit den Rottönen passt, muß man die Palette modifizieren, wie im Bild asc-building-palette.gif dargestellt. Alle Rottöne außer dem ersten Verlauf wurden eliminiert. Jetzt bleibt dem Bildbearbeitungsprogramm nichts anderes übrig, als diese und nur diese Rottöne zu verwenden.

Die beiden GIF-Bilder dienen ausschließlich der Demonstration, welche Palette die im detail enthalten weiß ich nicht, auf jeden Fall nicht die ASC-Palette (sind schließlich Screenshots). Hier ist auch noch ein Gebäude, das nun diese modifizierte Palette auch tatsächlich verwendet.

ASC ist es folkommen egal, welche Palette jetzt genau in der PCX-Datei vorhanden ist. Es nimmt bei 8-Bit Bilder prinzipiell seine eigene an, es ist also kein Problem, PCX-Bilder mit der modifizierten Palette einzubinden.

Last change: Sat, 2003-02-01 8:20

Using map transformation

The mapeditor has the abilitiy to run map transformations. These can be used to exchange objects and terrain. Map transformation tables have the syntax of normal .ASCTXT files, but have a different name: .ASCMAPXLAT . All .ASCTXT files are loaded at program start so it is not possible to alter the data while the program is running. But the map transformation files are reloaded each time you run a transformation.

The syntax of a map transformation file is:

maptranslation {

TerrainTranslation = [ 1 5 2 116 ]

; This causes all terrain files with TerrainType ID 1 to be replaced by TerrainType 5 ; and all fields of TerrainType ID 2 by TerrainType 116

TerrainObjTranslation = [ 10 100 101 11 234 102 ]

; This is a special translation for the fields that must be translated to ; a terrain AND an additional object. First number is Terrain ID to be replaced, ; second number is ID of new terrain, third number is ID of object that is added to field

ObjectTranslation = [ 181 81 ] ; This transforms one object into another, in this example object 181 into object 81

BuildingTranslation = [ 51 21 ] ; This transforms one building into another. ; The building entry is moved up to one field into each direction to enable a placement of the building } maptranslation

Last change: Fri, 2006-07-07 13:24

Bedeutung der AI-Parameter im Karteneditor

Diese AI-Parameter sind noch nicht so 100% ausgereift. Das sind die Variablen, mit denen die KI intern die Einheiten verwaltet. In welchem Maße die KI auf manuelle Vorgaben dieser Werte reagiert muss ich selbst noch ausprobieren.... Da können also möglicherweise noch Bugs sein. Aber in dem Maße, in dem die Campaign Fortschritte macht, werde ich diesen Bereich auch testen, auftretende Fehler beheben und evt. ein paar Funktionen erweitern.

Task sind kurzfristige Aufgaben, Jobs sind Lebensaufgaben. Wenn die KI einen Panzer auf mit einem Algol auftanken will und dafür mit dem Algol 3 Felder zum Panzer fahren muss, dann ist "Supply" der Job und "move" der Task.

Move ist eigentlich der einzige sinnvolle Task, den man im Karteneditor vorgeben kann. Zielkoordinaten werden für task move ausgewertet. X/Y ist klar, Z ist die Höhe ( 0 .. 7 ), NWID ist die interne Einheitenidentifikation. Damit kann man erreichen, dass die eine Einheit immer in Richtung einer anderen Einheit fährt, auch wenn letztere sich bewegt. Die NWID lässt sich im Karteneditor bei Info/TerrainInformation unter "Vehicle Information / Internal Identification" anzeigen.

Jobs: Build wird noch nicht benutzt Recon: Die Einheit wird ausschließlich zum Spähen / Stören eingesetzt Guard: Bewachen. Ob das jetzt schon funktioniert weiß ich nicht, ich werde es aber demnächst zum laufen bringen, weil für die Campaign benötigt. Details dann.

Value / Added Value. Jede Einheit wird von der KI hinsichtlich ihrer Gefährlichkeit bewertet. Mit Value kann man diese Bewertung überschreiben. Eigentlich nie notwendig. AddedValue schon eher: Stell Dir vor, in einer Mission gehts darum, den Oberkommandieren in einem Auto spazierenzufahren. Die Einheit darf nicht abgeschossen werden. Wird nun bei Added Value bei dieser ein hoher Werte eingetragen , wird nun aber die KI versuchen, genau diese Einheit anzugreifen. In ASC kann man mit F8 die KI-Informationen anzeigen lassen (eine Funktion, die für die Allgemeinheit eher uninteressant ist, deshalb undokumentiert). Dort kann man den Value sehen. Added-Value sollte mit dieser Größenordnung korrespondieren.

Die KI Parameter beziehen sich immer auf einen Spieler. Falls auf einer Karte mehrere KI-Spieler sind arbeiten die vollkommen unabhängig voneinander. Falls nur eine KI auf der Karte ist und die blau ist, müssen die AI-Parameter für Spieler 1 ( = blau) eingestellt werden. Im Beispiel mit dem Oberkommandieren: Wenn der in einem roten Auto sitzt, aber von der blauen KI angegriffen werden soll, muss auch hier der AddedValue bei den Ai-Parametern für Spieler 1 stehen.

So, ich hoffe mal, einen ersten Überblick vermitteln zu können...

Last change: Sun, 2003-02-09 14:12

Specifying the transportation/storage abilities of buildings and units

The term 'container' refers to both buildings and units and will be used throughout this article, which both behave absolutely identical. The term 'unit' always refers to the unit that is going to be transfered into or out of a container.

This is an example of the Transportation Variables:

If there is no transportation group, the container can not carry any units.

MaxLoableUnits

MaxLoadableUnitSize

MaxLoadableMass

CategoriesNOT

EntranceSystemNum

Mode

ContatinerHeight

CategoriesNOT

UnitHeightAbs

UnitHeightRel

dockingHeight_abs

dockingHeight_rel

RequireUnitFunction

DisableAttack

MoveCost

Last change: Thu, 2004-10-28 10:50

Setting up music

To change the music that ASC plays, place a file music1.asctxt in your primary ASC directory and specifiy the files there. ASC can play MP3, OGG, Midi and various tracker formats like MOD, S3M and others.

The default file looks like this:

playlist {

} playlist

If you also want to play MOD files for example (located in the music directory), change the file into

playlist {

} playlist

ASC uses the SMPEG library for playing MP3 files, which apparently can not decode MP3 files with variable bitrate.

Last change: Thu, 2003-05-08 10:56

specifying height change methods for units

This is an example how to specify the way in which a unit may change its height:

This example shows a unit that can take off from ground to low_level_flight traveling 2 fields, then ascend further to medium_level_flight by raising on the field that it is standing on. From medium_level_flight it can land directly to ground_level.

HeightChangeMethodNum defaults to 0, so if you don't specify it, a unit will not be able to change its height.

One HeightChangeMethod can work from different levels of height:

It must not happen that there are several methods to change a units height in the same direction. The following example is NOT valid:

because the unit would have two HeightChangeMethods for ascending from medium_level_flight.

It is of course perfectly legal to have one method for ascending from medium_level_flight and another one for descending from medium_level_flight.

You should avoid giving a height change method a lower movecost than dist*10. If the unit could travel two fields by changing its height and use only 15 movement points, the path finding algorithm would travel by constantly changing the unit's height because that is the shortest way (shorter even than bee-line) to move from one field to another. There is one exception: if the unit is changing from one height where it is really slow to another where it is significantly faster, it can be ok. Just check out if the movement algorithm makes unnecessary height changes. If it does, increase the movement cost of the height change operation.

Last change: Wed, 2003-02-19 6:29

Parent IDs für Grafik Objects/Terrain

Objects:

ID 1200 Installation (nur für Trooper begehbar) 1201 small things -> definiert als small_rocks MM +7 1202 Wald -> +forest MM+15 1203 hillside 1204 mountains 1205 high_mountains 1206 small_rocks 1207 hafen/wasser 1208 hafen/beton 1209 little forest 1210

Objects:

ID 1200 Beton MM10 1201 hard_sand MM11 1202 swamp MM20/25 1203 lowland MM12 1204 morass MM 15/18 1205 mud MM 13/14 1206 lowland MM13 1207 Hafen (wasser) 1208 water 1209 Coast-very_shallow_water 1210 Coast-shallow_water 1211 Installation 1212 hard_sand MM13/14 1213 hard_sand + small_rocks 1214 mountains 1215 hillside 1216 hard_sand + large_rocks 1217 fest installierte Pipeline (gebäudeartig) 1218 fest installierte Pipeline

baubare und andere besondere Objekte:

2 Railroad 3 Pipeline 7 Track 9 Path 10 ditch (Schützengraben) 30 buried_pipeline 44 Turret Foundation (ASC1) 45 Runway 81 Wald (gfx-Type) 181 Wald (ASC2) 998 Tankblocker (ASC1) 999 Railraod-Bridge 1000 Bridge (road)

Last change: Tue, 2003-02-25 11:00

Defining Unit Sets

You can group several vehicles together to form a unitset. In the mapeditor, you can enable and disable unitsets to make the selection of units easier. You can also define transformations that replace all units on a map by others. This is useful if you want to play a map with a different unit set than the one that is originally used by the map.

To define a unit set, you must create a unitset definition file, which is a plain text file with the extension .set . I suggest that you put all vehicles together with this unitset definition file into a single data container.

Here is an example for a unitset definition file:

#V2# NAME=Standard Unitset ID=0-800,900,920-930,950 BUILDINGID=0-400,507 MAINTAINER=Martin Bickel ( martin@asc-hq.org ) INFORMATION=This unitset is part of the standard ASC data package which can be obtained from http://www.asc-hq.org IDENTIFICATION=2 TRANSFORMATION=Example transformation;24,1840;25,1872;26,1805;27,1839;28,1878;29,1845;30,1834;31,1859;32,1821;33,1862;34,1810 TRANSFORMATION=Another transformation;77,1877;78,1878;79,1879;1000,1822;1001,1829;1002,1806

The first line must always be #V2#. This is to tell ASC that this is the second revision of the unitset definition file format. It is still possible to use the files with the old format, but if you create a new one use this new format.

Each of the following lines starts with a keyword, which must be UPPERCASE, an equals sign and some data. The order in which the properties are defined is not relevant.

NAME

ID

BUILDINGID

MAINTAINER

INFORMATION

IDENTIFICATION

TRANSFORMATION

Last change: Mon, 2004-08-02 12:46

Semantics of ASCTXT files

The syntax of ASCTXT files is documented in Article 33.

ASCTXT files support inheritance:

vehicletype {

} vehicletype

vehicletype { name = heavy tank ID = 11 parent = 10 armor = 650 } vehicletype

This defines two units, a "tank" (which must have all definitions that are required for a vehicletype, indicated by the dots), and a "heavy tank" which is derived from "tank". The "heavy tank" inherits all properties of its parent unit except Name, ID, and Armor.

Modifying properties

Properties can not only be replaced, they can be modified too:

vehicletype {

} vehicletype

The "super heavy tank" will have an armor of 720. Another operator is *= which multiplies a variable:

vehicletype {

} vehicletype

The "mega tank" inherits from "super heavy tank" and has 1.2 times the armor, which is 864.

Abstract parents

vehicletype {

} vehicletype

vehicletype { name = aircraft carrier ID = 21 parent = 20 view *= 3 ... } vehicletype

vehicletype { name = battleship ID = 22 parent = 20 view *= 4 ... } vehicletype

You will never find the unit A1 in ASC nor the mapeditor, because A1 is NOT a unit. It is an abstract base class which only provides data to derived units. If you derive all ships from A1, you can easily modify the view of all ships just by modifying A1. If you decide after some testing that your ships should have a 10% increase in view, just modify A1 to have a view of 11.

Multiple inheritance

vehicletype {

} vehicletype

vehicletype { name = binocular package ID = 31 abstract = true view = 100 } vehicletype

vehicletype { name = reconnaissance trooper ID = 32 parent = 31 30 } vehicletype

The "reconnaissance trooper" inherits from two base classes. The first one has precedence over the second one. This results in the "reconnaissance trooper" having all properties of the basic trooper except view, which is defined in the "binocular package".

Defining alias

TerrainType {

} TerrainType

This terrain will use the same picture for snow_and_ice as for much_snow. It is necessary that you specify the fully qualified property name, include the TerrainType. prefix !

The alias can reference ANY property:

TerrainType {

} TerrainType

TerrainType { parent = 100 dry { Picture -> TerrainType.grass_image ... } dry much_snow { Picture -> TerrainType.snow_image ... } much_snow snow_and_ice { Picture -> TerrainType.snow_image ... } ... } TerrainType

The alias-all operator While the alias operator -> operates only on a single property, the alias-all operator ->* operates on a group of properties:

TerrainType {

} TerrainType

This all properties of the much_snow group will be copied into the snow_and_ice group.

Existing properties will not be replaced, as is shown in this example:

vehicletype {

} vehicletype

vehicletype { parent = 100 Weapons { Number = 2 Weapon0 ->* VehicleType.big_ground_to_ground_missile Weapon1 ->* VehicleType.small_ground_to_ground_missile Weapon1.MaxRange = 20 } Weapons ... } vehicletype

This unit has two weapon systems. The first one has all properties of the big_ground_to_ground_missile defined in the abstract weapon definition. The second one is based on the small_ground_to_ground_missile , but uses a different MaxRange: 20 instead of 10.

Last change: Tue, 2003-04-01 7:37

Specifying which terrain can be accessed by units, objects and buildings

A field has a number of terrain properties. See the source for a list of all properties. The terrain properties of a field are the properties of the terraintype and all objects on that field.

A unit / building / object has 4 variables for specifying when the field is accessible and when not:

terrain_any

terrain_all

terrain_not

terrain_kill

Last change: Wed, 2003-04-02 10:45

Importieren von Battle-Isle-Karten (Linux)

Importieren von Battle-Isle-Karten über Karteneditor

Voraussetzungen: Zuerst sollte gesichert sein, daß folgende Dateien in einem durch die ascrc (zu finden in ~/.asc) vorgegebenen Suchverzeichnis stehen. Im Folgenden wird davon ausgegangen, daß alle diese Dateien direkt in ~/.asc vorhanden sind.

Natürlich sollte auch darauf geachtet werden, daß sowohl ASC wie auch der Karteneditor in der neuesten Version gehalten sind, ggf. können einzelne Dateien hier aktualisiert werden.

Weiterhin sollte darauf geachtet werden, daß der Karteneditor tatsächlich aus diesem Verzeichnis (~/.asc) heraus gestartet wird, da sonst in manchen Fällen die zum Import nötigen Verzeichnisse/Dateien nicht gefunden werden. Typische Fehlermeldung in diesem Fall: "A fatal error occured while accessing the file bla/blubbxyz.dat", gefolgt von einem | Fatal signal: Segmentation Fault (SDL Parachute Deployed) | Speicherzugriffsfehler

Natürlich sollte, da die Karten gezippt geliefert werden, auch unzip (>=5.41), ark oä. vorhanden sein.

Weiterhin sind noch folgende Dateien vonnöten (Erhältlich bei Battle Planet: aktuelle ASC-Dateien): bi_set.con (Hauptcontainer), bi-gfx (normale BI-Grafiken), bi-alternate.gfx (alternative BI-Grafiken - sind auch nicht schlecht).

Diese Dateien nach ~/.asc kopieren. Anschließend soviele BI-Karten besorgen, wie man will; die Zip-Archive ebenfalls nach ~/.asc kopieren und dort entpacken. Anschließend sollten folgende Verzeichnisse entstehen: .asc/eng, .asc/ger, .asc/mis und .asc/meta. Es können durchaus mehrere Archive nacheinander entpackt werden; die Inhalte dieser Verzeichnisse bleiben erhalten und kommen sich nicht gegenseitig in's Gehege.

Sodann den Karteneditor starten, Menü erscheint bei Druck auf [Alt] oder durch Berühren des oberen Randes mit der Maus - eine gewisse Wartezeit, bis eine Leerkarte erscheint, ist normal. [File] sowie [Import BI-Map] auswählen. Anschließend sollten eine oder mehrere BI-Karten zur Auswahl stehen; [missxyz.dat] wählen. Es sollten dann Übersetzungstabellen angezeigt werden; eine davon (mehrere Versuche können nicht schaden!) auswählen. Möglicherweise wird dann eine Warnmeldung a la "The buildings/following objects on position... could not be found" kommen; diese ist dadurch verursacht, daß nicht immer alle BI-Objekte automatisch übersetzt werden können. Erstmal ignorieren. Sicherlich wird die dann angezeigte Karte mit schwarzen 'Löchern' verunziert sein, diese lassen sich gewöhnlich durch Anwahl der Menüpunkte [Options][select graphics set] automatisch einflicken. Je nach Geschmack sollte dann [bi-gfx] oder [bi-alternate.gfx] gewählt werden. Karte dann mit [File][Save map as] abspeichern; ASC sollte sie dann im Kartenladedialog anzeigen und öffnen.

Im Extremfall müssen/können fehlende Objekte (siehe 'objects... could not be found') hinterher von Hand eingepflegt werden. Die Karten sind aber gewöhnlich auch so sehr gut spielbar, da meistens nur sehr exotische Objekte a la Superspezialgeheimdepots nicht gefunden werden. Außerdem ist es ratsam, die Produktion der Fabriken/Häfen/etc zu überprüfen, ob alle Einheiten richtig erkannt wurden. Sollte eine der Einheiten schwarz dargestellt werden, einfach löschen und erneut setzen ([F1] für Tastenkürzel bzw. Rechtstipp mit der Maus). Einer Kontrolle bedürfen jedenfalls sämtliche Flughäfen, da Landebahnen in BattleIsle reine Dekoration sind, in ASC hingegen zwingend notwendig zum Starten und Landen der Flugzeuge. Deshalb an jedem Flughafen kontrollieren, ob eine ausreichend lange Landebahn vorhanden ist. Die meisten Flieger kommen mit 4 Feldern aus, schwere Bomber brauchen 5 Felder Landebahn. Die genaue Zahl für jeden Flugzeugtyp findet sich in der Einheitendokumentation unter Movement / Height Change Method / Distance , zu diesem Wert muss 1 Feld als Startfeld hinzugefügt werden.

Viel Spaß!

Bemerkungen: 1. Wenn man die BI-Ausgangskarten nicht hinter ~/.asc haben will, kann man sie auch woandershin entpacken; allerdings müssen dann die oben angegebenen Verzeichnisse durch symbolische Links auf den tatsächlichen Ort ersetzt werden. 2. Im Prinzip sollte, von der anderen Verzeichnisstruktur abgesehen, diese Anleitung auch für Windoze brauchbar sein. 3. Die installierten Versionen können mit 'asc --version' bzw. 'asc-mapedit --version' ermittelt werden. Wenn man wissen will, wo ASC und der Karteneditor liegen: 'which asc' bzw. 'which asc_mapedit' ausführen. 4. Der Editor asc_mapedit sollte nach gelungener Installation eigentlich im Pfad liegen. Wenn dem nicht so ist (außer: $PATH wurde absichtlich geändert), deutet das gewöhnlich auf ein fehlgegangenes 'make/make install' hin. Es kann bei ./configure auch die Option --prefix=/hier/dort/sonstwo eingesetzt werden, um auf nicht standardisierten Systemen einen Installationsort zu erzwingen (Default für Binaries: /usr/local/bin). Sollte der Karteneditor gesucht werden müssen: 'locate asc_mapedit' benutzen; wenn das locate-Paket nicht installiert ist, findet ihn auch 'find / -name "asc_mapedit" 2>/dev/null' (find wird fleißig auf der Platte schrubben - nicht wundern). Sollte die locate-Datenbank nichts finden (bei frischer Installation), kann sie mit 'updatedb' aktualisiert weden (verlangt root/sudo-Rechte) 5. Bei Bedarf können dem Karteneditor auch Optionen per Kommanozeile übergeben werden. 'asc_mapedit --help' liefert weitere Angaben. 6. Nicht alle BI-Objekttypen sind nach ASC übertragen; es kann durchaus sein, daß manche Objekt-IDs nicht zu finden sind (speziell bei BI3-Karten). In diesem Fall möglichst ähnliche mit bekannter ID einsetzen. Wenn jemand solche fehlenden Objekte erstellen will, wäre das willkommen:). 7. Ein Tutorial, wie Objekte ermittelt und eingesetzt werden, wird bald folgen. Bis dahin bitten wir um Geduld - der Tugend der Weisen. 8. Viele Funktionen des Editors können nur per Tastatur angesprochen werden.

Last change: Fri, 2003-09-19 3:38

Building functions

The following building functions are available:

HeadQuarters

Training_Facility

Vehicle_Production

Ammo_Production

Repair_Facility

Recycling

Research

Sonar

Wind_Power_Plant

Solar_Power_Plant

Matter_Converter

Mining_Station

External_loading

Produce_Units_that_cannot_leave

ResourceSink

ExternalResourceTransfer

ExternalAmmoTransfer

NoObjectChaining

Selfdestruct_at_conquer

satelliteview

Last change: Sun, 2004-12-05 12:57

Defining the user interface

The graphical user interface (GUI) of ASC consists of two kinds of objects: windows and panels.

A window has exclusive control over the input devices, while a Panel can be open while the player plays on the map.

Panels

The panels are composed of widgets, which are defined in .ascgui files. These files have the syntax of .asctxt files, but don't support the kind of inheritance used for example for vehicle types. Their content is also not cached, but parsed every time a panel is opened, which allows to edit the .ascgui files in a running ASC session and see the results by closing and reopening the panel.

ascgui { height = 550 width = 170

ChildWidgets = MyDisplay TheOutput ; you can give any names heres, important is only that they are detailed below

MyDisplay { x = 10 y = 10 width = 20 height = 40 x2 = 30 y2 = 50 type = SomeType name = PARENT ChildWidgets = SubWidget SubWidget { x = 10 y = 10 type = TYPE name = CHILD } SubWidget } MyDisplay TheOutput { x = 10 y = 10 width = 20 height = 40 x2 = 30 y2 = 50 type = TYPE name = FooBar ToolTipHelp = HelpMessage } TheOutput

} ascgui

As you can see, Widgets can be nested arbitrarily. The widget CHILD inherits its properties from PARENT. A child can not be larger than the parent on the screen, it's not possible to make a widget that overlaps the border of its parent.

General Widget Properties

type

x, y, width, height, x2, y2

ToolTipHelp

The following properties are inherited through all widgets. If a property is not specified, the property's value of the widget's parent is used. Because of this inheritance, you often don't need to specify properties at all for a widget.

BackgroundImage

BackgroundMode

TextAlign

FontColor

FontName

FontAlpha

FontSize

BackgroundColor

Transparency

Widget Types

Image

FileName

Mode

StaticText Displays text which is defined right in the .ascgui file.

Text

Style

TextOutput Displays text which will be provided by ASC. This widget is only useful together with appropriate program code inside ASC.

Name

Style

BarGraph Similar to an Area, but its fill ranges from 0% to 100% from left to right. This widget is only useful together with appropriate program code inside ASC.

Name

Direction

You can define different colors for different ranges:

SpecialDisplay This widget is only useful together with appropriate program code inside ASC. It is used to display non-standard things like the small map or the wind direction arrow.

Name

SpecialInput

This widget is only useful together with appropriate program code inside ASC. A SpecialInput widget is used to start actions when the user clicks on it. Since this widget itself is invisible, it must be used together with some visible widget.

Name

Dummy

This widget does nothing and is used to structure other widgets. Example (also demonstrates unnamed widgets by specifying "widgetNum = 3" instead of "childWidgets = Name1 Name2 Name3"):

FontColor = 0xffffff textalign = CENTER FontSize = 7

widgetNum = 3 widget0 { x = 0 y = 0 height = 15 type = TextOutput name = WeaponPunch0 } widget0 widget1 { x = 0 y = 15 height = 15 type = TextOutput name = WeaponPunch1 } widget1 widget2 { x = 0 y = 30 height = 15 type = TextOutput name = WeaponPunch2 } widget2 } widget0

By using the Dummy widget, you can group the 3 TextOutput widgets. You can now change their font settings with a single entry. And since the coordinate are relative, you can move the whole column around and change their width by just changing the coordinates of the dummy widget.

MultiLineText Displays a bigger amount of text. If the text doesn't fit into the widgets, a vertical scrollbar will be displayed for scrolling the text.

Name

Style

ScrollArea Represents a area in which other widgets can be placed. If the widget coordinates don't fit into ScrollArea, ScrollBars are displayed for scrolling in ScrollArea.

Button A simple button which can be pushed

Text

RadioButton A RadioButton which can be selected or not. All RadioButtons of a parent widget act as a RadioButton group, so that only one of the RadioButtons can be selected at one. If you want more than one RadioButton group, put them into different dummy widgets.

Text