<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="WebWriter/2 v1.2">
<TITLE>ASC documentation: Mapeditor</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>Mapeditor</H2>
<TT>EDHEX.EXE</TT>
</CENTER>
<P>
Originally the mapeditor was designed to be used by keyboard only (except the dialog boxes) and the mouse routines were added later. Keep that in mind when using the mouse and something does not seem to work. Just use the keyboard... The whole map editor is much less polished than the game.<P>
The <F1>-key in the mapeditor brings up help. Most keys should be
listed there.<P>
Selecting items is possible with the keys <F3... Fn>, one <F -
key> for each item category ( terrain, tanks, buildings, mines,
etc).<P>
Use <F2> to get the cursor back on the map. You can place items
with <Space>. <F> is used to fill rectangles with objects. Go to
the upper left corner, press <F> then to the lower right corner
and press <Space>.<P>
You can rotate some items with <D>.<P>
I recommend to save often and under different filenames to prevent
data loss.<P>
<H3>Events</H3>
The events are one of the most important functions of ASC. An event consists of:
<UL>
<LI>an <I>action</I> that describes what the event basically does. Most
actions need further information that will be automatically
prompted. The following actions are available:
<DL>
<DT><I>message</I></DT>
<DD>
A Textmessage is displayed. Parameter is the ID of the
message. The message itself must be saved in a textfile
with the same name as the map but with the ending .MSG
. <A HREF="example.msg">An example of a MSG-file</A>. For more information about the formatting capabilities of
text message refer to <A HREF="text.html">text.html</A>. You can also extract the file from the data files that came with ASC and take a look at the maps and message files included there.
</DD>
<DT><I>weather change</I></DT>
<DD>
The weather of the map changes. There are 2 modes:
either the weather on the whole map changes or just in
the area of one (implemented) or multiple (not
implemented yet) polygons. The sides of the polygons
are not allowed to cross each other. You can place the
polygon-edges by pressing <Space> and finish with the
<Esc> key. Afterwards you will be asked which weather
should be used. The following weather types are
available by now: "dry", "light rain", "heavy rain",
"little snow", "much snow". The weather will only be
used if the chosen weather is valid for the terrain-
type it is placed on.
The event "weather change completed" should always be
used after a "weather change".
</DD>
<DT><I>new technology discovered</I></DT>
<DD>
The player for whom the event is defined for can from
this time on use the selected technology. You have to
enter the tech-ID. This works with any technology
without further parameters.
</DD>
<DT><I>loose campaign</I></DT>
<DD>
(not implemented yet)
</DD>
<DT><I>run script + map</I></DT>
<DD>
(not implemented yet)
</DD>
<DT><I>new technology researchable</I></DT>
<DD>
The player for whom the event is defined for can
research the specified technology from that point of
time on. In the technology definition it has to be
specified that an event is necessary to research it.
All other conditions required for researching this
technology must be true too.
</DD>
<DT><I>map change</I></DT>
<DD>
Similar to weather change, only that the terrain
changes. The event "weather change completed" should
always be used after a "map change".
</DD>
<DT><I>erase event</I></DT>
<DD>
Has been removed !
</DD>
<DT><I>end campaign</I></DT>
<DD>
(not implemented yet)
</DD>
<DT><I>next map</I></DT>
<DD>
A new map will be started. It is used for the
connection of two maps in campaigns. You have to know
the ID of the map. If it is not possible to relate this
ID to a certain map (because there are several maps
with the same id) then the map will be used that has
the ID of the first map defined as PrevID.
</DD>
<DT><I>reinforcement</I></DT>
<DD>
(not implemented yet)
</DD>
<DT><I>weather change completed</I></DT>
<DD>
Checks if all units can exist on the terrain they are
standing on. This function is not directly implemented
in "map/weather change" to allow using several
"weather/map changes" directly after each other. For
example:
If a map should be flooded but one island should remain
it would be a lot of work to define the flooding area
precisely. So you can first flood the whole map with
water and then "rebuild" the island (if it is not too
complex). If there is no "weather change completed"
between these two events then it will seem like one map
change for the player and units on the island will not
be effected by the water.
</DD>
<DT><I>new vehicle developed</I></DT>
<DD>
The player for whom the event is defined for can
produce this unit from that point of time. You will
have to know the ID of the unit. This is possible with
any vehicle without further parameters.
</DD>
<DT><I>palette change</I></DT>
<DD>
(not implemented yet)
</DD>
<DT><I>alliance change</I></DT>
<DD>
(not implemented yet)
</DD>
<DT><I>wind change</I></DT>
<DD>
Changes wind speed. For different heights different
speeds can be defined but this feature should be used
only seldom.
</DD>
<DT><I>nothing</I></DT>
<DD>
Nothing happens. It can be used if further events
use this event as trigger. With this technique an event can effectively use any
number of triggers.
</DD>
<DT><I>change game parameter</I></DT>
<DD>
Some game parameters can be changed with this event.
Implemented by now are "lifetime of vehicle tracks" and
"lifetime of broken ice".
</DD>
</DL>
<LI><I>Player</I> : the player for whom the actual event is defined.
"Neutral" means that it can happen to every player, but of
course only once.
<LI><I>Description</I> : to describe the event more precise, maximum
are 20 characters
<LI><I>Trigger</I>: You can use one to four trigger. The triggers
describe when the event happens. The following are available:
<UL>
<LI><I>*NONE*</I>: trigger not used
<LI> <I>turn/move >=</I> :
if "turn" and "move" are reached or exceeded<BR>
the game starts at turn = 1 / move = 0
<LI> <I>building conquered</I> :
the building belongs to that player
<LI> <I>building lost</I> :
the building does not belong to that player
<LI> <I>building destroyed</I>
<LI> <I>unit lost</I>
<LI> <I>technology researched</I>
<LI> <I>event</I>
<LI> <I>unit conquered</I>
<LI> <I>unit destroyed</I>
<LI> <I>all enemy units destroyed</I>
<LI> <I>all units lost</I>
<LI> <I>all enemy buildings destroyed/captured</I>
<LI> <I>all buildings lost</I>
<LI> <I>energy tribute <</I>
<LI> <I>material tribute <</I>
<LI> <I>fuel tribute <</I>
<LI> <I>any unit enters polygon</I>: select the colors of the players that may trigger the event
<LI> <I>specific unit enters polygon</I>
<LI> <I>building is seen</I>
</UL>
<LI>all these triggers can be used together. The order of these
events should be displayed correct in the mapeditor. It is
possible to use multiple operators per trigger. Some examples
( I use numbers for the triggers ):
<DL>
<DD> NOT 1 AND ( 2 OR ( 3 AND NOT 4 ))</DD>
<DD> NOT (1 AND ( 2 OR ( 3 AND NOT 4 )))</DD>
</DL>
<LI><I>time-offset</I>: to delay an event. The triggers will NOT be
checked again after that time. If the countdown is started
the event can only be stopped by changing the level.
</UL>
<P>
Just some more remarks on the events :
<UL>
<LI>the order of the events presented in the mapeditor can be
important. The events will be evaluated from top to bottom.
<LI>Some trigger show some information about the item they are
referencing when right-clicking on the beginning of their name.
</UL>
<A name="BIMAPIMPORT"><H3>Importing Battle Isle maps</H3></A>
The game engine of ASC is quite different to that of Battle Isle, since when we designed it several years ago we never intended to make ASC Battle Isle compatible. A major difference are the buildings: In Battle Isle a shop is totally independent of the graphics that are used to show it on the map, while in ASC every shop type has its own graphics. When ASC finds a shop when importing a map, it determines the ASC-building-type by the graphics of the object on the shop's and its surrounding fields. This building type may have completely different settings than the shop in Battle Isle ! Or for many exotic shops ASC may find no matching building type at all. <P>
The first possibility to resolve this problem is creating more building types in ASC, which is much work especially if a map like Steffen Fröhlich's city map should be imported. <P>
But there is another possibility which requires some enhancements to the game engine: to make invisible buildings and combine them with any object. The ability to make invisible buildings is already implemented quite a long time in the game, but I must admit that we did not test it very intensively. Up to now nothing is allowed to stand on a building entry, neither a unit nor an object, but I think it should be possible to allow objects there without changing too much of the game engine. I will add this feature as soon as someone has made the necessary object types (that don't hinder or slow units entering them) and building types (which are just one field large).<P>
Note that if a map is not completely imported because some terrain, objects or buildings are missing it is usually easier to build the missing items and than import the map again then adding them later to an already existing ASC map.<P>
It is not possible yet to read the shop names form TPWM encoded files. Decode the files first if you want to keep the shop names.<P>
After importing a map make sure that the airports have a runway that is long enough to be used by airplanes !<P>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
7bfd2c15e8a2e6eb8f651311cc22e276
>
files
>
38
