Combine naming guide with README, convert to AsciiDoc.
git-svn-id: svn+ssh://svn.code.sf.net/p/crossfire/code/arch/trunk@19287 282e977c-c81d-0410-88c4-b93c2d0d6712master
partmedia
parent
0cc923b5e2
commit
798d7b0d38
262
Naming.doc
262
Naming.doc
|
|
@ -1,262 +0,0 @@
|
||||||
archetype-file NAME.arc
|
|
||||||
|
|
||||||
image-file
|
|
||||||
|
|
||||||
NAME.PDA
|
|
||||||
|
|
||||||
where
|
|
||||||
P - part number
|
|
||||||
D - coding, or any other instance
|
|
||||||
coding in
|
|
||||||
A - animation phase
|
|
||||||
|
|
||||||
numbering, PDA
|
|
||||||
|
|
||||||
- 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, ..., Z
|
|
||||||
- Alphanumeric
|
|
||||||
- Can be thought as hexadecimals
|
|
||||||
|
|
||||||
name NAME:
|
|
||||||
|
|
||||||
- Maximum of 10 characters long, so max file name is 14 characters,
|
|
||||||
that fit into portability requirements
|
|
||||||
|
|
||||||
Part numbers:
|
|
||||||
|
|
||||||
3x3 : 1 2 3
|
|
||||||
4 5 6
|
|
||||||
7 8 9
|
|
||||||
|
|
||||||
2x2 : 1 2
|
|
||||||
3 4
|
|
||||||
|
|
||||||
3x2 : 1 2 3
|
|
||||||
4 5 6
|
|
||||||
|
|
||||||
2x3 : 1 2
|
|
||||||
3 4
|
|
||||||
5 6
|
|
||||||
|
|
||||||
Codings:
|
|
||||||
|
|
||||||
Direction:
|
|
||||||
|
|
||||||
8 1 2
|
|
||||||
\ | /
|
|
||||||
7- 0 -3
|
|
||||||
/ | \
|
|
||||||
6 5 4
|
|
||||||
|
|
||||||
Same as in Crossfire
|
|
||||||
|
|
||||||
Turnable (reflecting objects):
|
|
||||||
|
|
||||||
0 to left, vertical
|
|
||||||
1 to right, horizontal
|
|
||||||
|
|
||||||
- also in gates, signs, ...
|
|
||||||
|
|
||||||
Walls:
|
|
||||||
|
|
||||||
Name format: name_X.arc, name_X.PDA.png
|
|
||||||
|
|
||||||
1
|
|
||||||
|
|
|
||||||
8 -+- 2
|
|
||||||
|
|
|
||||||
4
|
|
||||||
|
|
||||||
X is a bit-wise combination expressed in hexadecimal form. For example,
|
|
||||||
8 + 4 + 2 + 1 = F describes a vertical cross, and 4 + 1 = 5 identifies a
|
|
||||||
vertical wall.
|
|
||||||
|
|
||||||
P, D, and A are always 1.
|
|
||||||
|
|
||||||
f diagonal connecting points are not
|
|
||||||
offered by the arch. If d Object Names:
|
|
||||||
|
|
||||||
When creating .arc files, the object name is determined by a similar,
|
|
||||||
but distinctly different, scheme. See the server code in
|
|
||||||
server/build_map.c and random_maps/wall.c for the source of the
|
|
||||||
information that follows. The arch name (ie. awall) must not have any
|
|
||||||
underscores. A suffix in the form _U[_V[_W]] is appended to the arch
|
|
||||||
name.
|
|
||||||
|
|
||||||
U is the number of connection points (ie. for a pillar U == 0, and for
|
|
||||||
a cross U == 4).
|
|
||||||
|
|
||||||
At the time of this writing, the formulae for calculating V and W is
|
|
||||||
not known, but, U, V, and W can be determined as follows. Calculate a
|
|
||||||
value called "connect" by adding the values of the connecting points:
|
|
||||||
|
|
||||||
4
|
|
||||||
|
|
|
||||||
1 -0- 2
|
|
||||||
|
|
|
||||||
8
|
|
||||||
|
|
||||||
Then use "connect" to pick a suffix:
|
|
||||||
|
|
||||||
0: _0
|
|
||||||
1: _1_3
|
|
||||||
2: _1_4
|
|
||||||
3: if (has_window)
|
|
||||||
_win2
|
|
||||||
else
|
|
||||||
_2_1_2
|
|
||||||
4: _1_2
|
|
||||||
5: _2_2_4
|
|
||||||
6: _2_2_1
|
|
||||||
7: _3_1
|
|
||||||
8: _1_1
|
|
||||||
9: _2_2_3
|
|
||||||
10: _2_2_2
|
|
||||||
11: _3_3
|
|
||||||
12: if (has_window)
|
|
||||||
_win1
|
|
||||||
else
|
|
||||||
_2_1_1
|
|
||||||
13: _3_4
|
|
||||||
14: _3_2
|
|
||||||
15: _4
|
|
||||||
|
|
||||||
For a complete example, a vertical cross wall graphic in an awall arch set
|
|
||||||
is named awall_F.base.111.png. Face information is kept in awall_F.face,
|
|
||||||
and the archetype data is in awall.arc. Inside awall.arc, the Object name
|
|
||||||
is awall_4.
|
|
||||||
|
|
||||||
Diagonal (extended) walls, roads, etc.
|
|
||||||
|
|
||||||
The legacy wall-naming convention is used in conjunction with the
|
|
||||||
extension to the name format described here to provide a uniform naming
|
|
||||||
scheme that supports corner connections. Legacy names do not need to
|
|
||||||
change to simply add diagonal versions of the legacy graphics.
|
|
||||||
|
|
||||||
The name format is name_XY.arc, name_XY.PDA.png
|
|
||||||
|
|
||||||
X follows the same rules as used for the legacy wall format, except that
|
|
||||||
when there are no NSEW connecting points, X == 0.
|
|
||||||
|
|
||||||
Y may be omitted, or may be 0 if diagonal connecting points are not
|
|
||||||
offered by the arch. If diagonal connecting points are implemented, Y is
|
|
||||||
a bit-wise combination computed in the same manner as X, and is also
|
|
||||||
expressed as a hexadecimal digit. The difference is that it refers to
|
|
||||||
corner connections:
|
|
||||||
|
|
||||||
1 2
|
|
||||||
\ /
|
|
||||||
X
|
|
||||||
/ \
|
|
||||||
8 4
|
|
||||||
|
|
||||||
For example, name_0F refers to a diagonal cross, or connecting points in
|
|
||||||
all four corners. name_05 and name_0A refer to pure diagonals.
|
|
||||||
|
|
||||||
Since diagonal pieces require corner fills, P is used to differentiate the
|
|
||||||
component parts of the diagonal.
|
|
||||||
|
|
||||||
P (part number) ranges from 1 to 3.
|
|
||||||
|
|
||||||
1 : used for "normal" pieces that connect direction points.
|
|
||||||
|
|
||||||
2 : used for a top corner fill needed to complete diagonal
|
|
||||||
connections.
|
|
||||||
|
|
||||||
3 : used for a bottom corner fill needed to complete diagonal
|
|
||||||
connections.
|
|
||||||
|
|
||||||
Examples of diagonal files are dirtroad_05.211, dirtroad_05.311,
|
|
||||||
dirtroad_0A.211, and dirtroad_0A.311. The archetypes for these
|
|
||||||
are stored in dirtroad_05.arc and dirtroad_0A.arc. The corner
|
|
||||||
fill is a "part" of a diagonal, and is not really useful on its
|
|
||||||
own.
|
|
||||||
|
|
||||||
The .211 and .311 file names are based on the full diagonal, but
|
|
||||||
are used for all diagonal connecting points. Usually it is not
|
|
||||||
necessary to customize the corner piece to fit each and every
|
|
||||||
possible XY combinationi that incorporates a diagonal connecting
|
|
||||||
point.
|
|
||||||
|
|
||||||
Object Names:
|
|
||||||
|
|
||||||
When creating object names, use a different format (_U_XYP) unless
|
|
||||||
the legacy naming format can be figured out and adapted to the
|
|
||||||
diagonal set - in which case, it should be documented here. This
|
|
||||||
format allows consistent object naming in the event that renaming is
|
|
||||||
desirable in the future, and it does not collide with the legacy
|
|
||||||
object naming.
|
|
||||||
|
|
||||||
U = Number of connecting points.
|
|
||||||
XY = Where X and Y are re-used as described above.
|
|
||||||
P = Where P is the part number.
|
|
||||||
|
|
||||||
Cave:
|
|
||||||
|
|
||||||
Complex
|
|
||||||
|
|
||||||
River names:
|
|
||||||
|
|
||||||
NOTE: Consider deprecation of this format in favor of the extended wall
|
|
||||||
naming. It is more flexible than this format.
|
|
||||||
|
|
||||||
Simple diagonals, like non-branched rivers, are saved as name_XY.arc and
|
|
||||||
name_XY.PDA.png.
|
|
||||||
|
|
||||||
X and Y use the direction scheme shown above (and copied here for
|
|
||||||
ease of reference). For example, river_15 runs north/south; river_26
|
|
||||||
runs from the northeast to the southwest.
|
|
||||||
|
|
||||||
8 1 2
|
|
||||||
\ | /
|
|
||||||
7- 0 -3
|
|
||||||
/ | \
|
|
||||||
6 5 4
|
|
||||||
|
|
||||||
X and Y do not define direction of water flow. They are simply
|
|
||||||
connecting points to neighboring arches of the same set. X and Y are
|
|
||||||
ordered low to high, so it is not expected that a river_62 exist;
|
|
||||||
instead the piece is named river_26.
|
|
||||||
|
|
||||||
A cul-de-sac, or dead-end could have X == 0 and Y set to the connect
|
|
||||||
point. Conceptually, a pool could follow this same naming convention
|
|
||||||
and set X == Y == 0.
|
|
||||||
|
|
||||||
D and A are presently always set to 1.
|
|
||||||
|
|
||||||
P ranges from 1 to 3.
|
|
||||||
|
|
||||||
1 : used for "normal" pieces that connect direction points.
|
|
||||||
|
|
||||||
2 : used for a top corner wedge used to fill in diagonals (i.e. A
|
|
||||||
wedge in the top right or top left corner).
|
|
||||||
|
|
||||||
3 : used for a bottom corner wedge used to fill in diagonals (i.e.
|
|
||||||
A wedge in the bottom right or bottom left corner).
|
|
||||||
|
|
||||||
Examples of wedges are river_48.211, river_48.311, river_26.211,
|
|
||||||
and river_26.311. The archetypes for these are stored in
|
|
||||||
river_48.arc and river_26.arc. The wedge is a "part" of a
|
|
||||||
diagonal, and is not really useful on its own.
|
|
||||||
|
|
||||||
River junctions, add another digit to the format used by simple diagonals,
|
|
||||||
and are stored as name_XYZ.arc and name_XYZ.PDA.
|
|
||||||
|
|
||||||
X, Y, and Z represent the three directions the river exits. 367 would
|
|
||||||
be east,southwest, and west. Junctions, or branchesi, may also have
|
|
||||||
multiple parts - this happens when the junction has a diagonal
|
|
||||||
direction.
|
|
||||||
|
|
||||||
By convention, directions for the river parts are in ascending order.
|
|
||||||
That is, if the exit locations are 2, 6, 3, the name could be
|
|
||||||
branch_236 (not branch_326, or branch_623, etc).
|
|
||||||
|
|
||||||
Complex branching paths could be set by adding digits to allow four or
|
|
||||||
more connecting points, but use of the extended walls format is
|
|
||||||
recommended instead.
|
|
||||||
|
|
||||||
Modified:
|
|
||||||
|
|
||||||
93/08 hevi@lut.fi - created
|
|
||||||
94/05 master@rahul.net - updated river definitions.
|
|
||||||
10/06 kbulgrien - rewrite & add extended wall name format.
|
|
||||||
|
|
||||||
295
README
295
README
|
|
@ -1,41 +1,48 @@
|
||||||
This is a generic README file for the arch directory.
|
Crossfire Archetype Guide
|
||||||
You should also read the CHANGES for and Naming.doc file.
|
=========================
|
||||||
|
Crossfire Development Team <crossfire@metalforge.org>
|
||||||
|
1.70.0-dev, March 2014
|
||||||
|
:numbered:
|
||||||
|
:toc:
|
||||||
|
|
||||||
The color bitmap files use the XPM library (called xpm-3.4f on
|
Pixmaps
|
||||||
most ftp sites. A later version may be out now.)
|
-------
|
||||||
|
The color bitmap files use the XPM library (called xpm-3.4f on
|
||||||
|
most ftp sites. A later version may be out now.)
|
||||||
|
|
||||||
This library is needed in order to compile crossfire with the color
|
This library is needed in order to compile crossfire with the color
|
||||||
pixmap support.
|
pixmap support.
|
||||||
|
|
||||||
The pixmap files have the same name as the bitmap file with ".xpm"
|
The pixmap files have the same name as the bitmap file with ".xpm"
|
||||||
concatenated to the end. If your system has short filename length
|
concatenated to the end. If your system has short filename length
|
||||||
limits, this may cause a problem.
|
limits, this may cause a problem.
|
||||||
|
|
||||||
I use 'pixmap' to edit the xpm files. This should be available the
|
I use `pixmap` to edit the xpm files. This should be available the
|
||||||
same place the xpm library can be found. It does require the xpm
|
same place the xpm library can be found. It does require the xpm
|
||||||
library.
|
library.
|
||||||
|
|
||||||
All of the XPM files have been colored. However, only a small number
|
All of the XPM files have been colored. However, only a small number
|
||||||
have actually been done so properly - that is, by hand, and with the
|
have actually been done so properly - that is, by hand, and with the
|
||||||
proper outlines. Many people are working on fixing more of these up.
|
proper outlines. Many people are working on fixing more of these up.
|
||||||
|
|
||||||
If you do start to work on colorizing the other directories, please
|
If you do start to work on colorizing the other directories, please
|
||||||
let me know. Otherwise, you may start working on something that someone
|
let me know. Otherwise, you may start working on something that someone
|
||||||
else has already done.
|
else has already done.
|
||||||
|
|
||||||
The file xpm.template in the dev directory is a XPM file that has all of
|
The file xpm.template in the dev directory is a XPM file that has all of
|
||||||
the colors that are allowable for XPM files. This is to limit the total
|
the colors that are allowable for XPM files. This is to limit the total
|
||||||
number of colors used, in order not of overrun color spaces on systems.
|
number of colors used, in order not of overrun color spaces on systems.
|
||||||
If you really need a color not in that file, please send mail to Mark
|
If you really need a color not in that file, please send mail to Mark
|
||||||
Wedel (mwedel@pyramid.com), and it might be added to the list of
|
Wedel (mwedel@pyramid.com), and it might be added to the list of
|
||||||
acceptable colors.
|
acceptable colors.
|
||||||
|
|
||||||
For a list of colors to use, look at the dev/xpm.template file.
|
For a list of colors to use, look at the 'dev/xpm.template' file.
|
||||||
|
|
||||||
|
Mark Wedel
|
||||||
Mark Wedel
|
|
||||||
mwedel@pyramid.com
|
mwedel@pyramid.com
|
||||||
----
|
|
||||||
|
Perspective
|
||||||
|
~~~~~~~~~~~
|
||||||
Some coloring/perspective hints/clarifications from David Sundqvist:
|
Some coloring/perspective hints/clarifications from David Sundqvist:
|
||||||
|
|
||||||
Perspective in Crossfire is based on the XY coordinate system of possible
|
Perspective in Crossfire is based on the XY coordinate system of possible
|
||||||
|
|
@ -51,3 +58,255 @@ buildings should be darker or shaded, as needed.
|
||||||
|
|
||||||
Wind is generally coming from the left side, so smoke or other things
|
Wind is generally coming from the left side, so smoke or other things
|
||||||
affected by wind should be travelling towards the right side.
|
affected by wind should be travelling towards the right side.
|
||||||
|
|
||||||
|
Naming Conventions
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Archetype File Name
|
||||||
|
~~~~~~~~~~~~~~~~~~~
|
||||||
|
The name of an archetype file should be no more than 10 characters long, for
|
||||||
|
a total of 14 characters in the entire file name. This is to ensure maximum
|
||||||
|
portability across different systems.
|
||||||
|
|
||||||
|
NOTE: Is this still a limitation?
|
||||||
|
|
||||||
|
Archetype file names should end with an extension of '.arc'. Image files
|
||||||
|
have a 3-digit extension in the form of '.PDA', where:
|
||||||
|
|
||||||
|
P - part number
|
||||||
|
D - coding, or any other instance
|
||||||
|
coding in
|
||||||
|
A - animation phase
|
||||||
|
|
||||||
|
Numbering (PDA)
|
||||||
|
^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
- 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, ..., Z
|
||||||
|
- Alphanumeric
|
||||||
|
- Can be thought as hexadecimals
|
||||||
|
|
||||||
|
Part Numbers
|
||||||
|
^^^^^^^^^^^^
|
||||||
|
|
||||||
|
3x3 : 1 2 3
|
||||||
|
4 5 6
|
||||||
|
7 8 9
|
||||||
|
|
||||||
|
2x2 : 1 2
|
||||||
|
3 4
|
||||||
|
|
||||||
|
3x2 : 1 2 3
|
||||||
|
4 5 6
|
||||||
|
|
||||||
|
2x3 : 1 2
|
||||||
|
3 4
|
||||||
|
5 6
|
||||||
|
|
||||||
|
Codings
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
.Direction
|
||||||
|
|
||||||
|
8 1 2
|
||||||
|
\ | /
|
||||||
|
7- 0 -3
|
||||||
|
/ | \
|
||||||
|
6 5 4
|
||||||
|
|
||||||
|
Same as in Crossfire
|
||||||
|
|
||||||
|
.Turnable (reflecting objects)
|
||||||
|
|
||||||
|
- 0 to left, vertical
|
||||||
|
- 1 to right, horizontal
|
||||||
|
- also in gates, signs, ...
|
||||||
|
|
||||||
|
Walls
|
||||||
|
~~~~~
|
||||||
|
|
||||||
|
Name format: 'name_X.arc', 'name_X.PDA.png'
|
||||||
|
|
||||||
|
1
|
||||||
|
|
|
||||||
|
8 -+- 2
|
||||||
|
|
|
||||||
|
4
|
||||||
|
|
||||||
|
X is a bit-wise combination expressed in hexadecimal form. For example,
|
||||||
|
8 + 4 + 2 + 1 = F describes a vertical cross, and 4 + 1 = 5 identifies a
|
||||||
|
vertical wall.
|
||||||
|
|
||||||
|
P, D, and A are always 1.
|
||||||
|
|
||||||
|
.Object Names
|
||||||
|
|
||||||
|
When creating '.arc' files, the object name is determined by a similar,
|
||||||
|
but distinctly different, scheme. See the server code in
|
||||||
|
'server/build_map.c' and 'random_maps/wall.c' for the source of the
|
||||||
|
information that follows. The arch name (ie. awall) must not have any
|
||||||
|
underscores. A suffix in the form _U[_V[_W]] is appended to the arch
|
||||||
|
name.
|
||||||
|
|
||||||
|
U is the number of connection points (ie. for a pillar U == 0, and for
|
||||||
|
a cross U == 4).
|
||||||
|
|
||||||
|
At the time of this writing, the formulae for calculating V and W is
|
||||||
|
not known, but, U, V, and W can be determined as follows. Calculate a
|
||||||
|
value called "connect" by adding the values of the connecting points:
|
||||||
|
|
||||||
|
4
|
||||||
|
|
|
||||||
|
1 -0- 2
|
||||||
|
|
|
||||||
|
8
|
||||||
|
|
||||||
|
Then use "connect" to pick a suffix:
|
||||||
|
|
||||||
|
0: _0
|
||||||
|
1: _1_3
|
||||||
|
2: _1_4
|
||||||
|
3: if (has_window)
|
||||||
|
_win2
|
||||||
|
else
|
||||||
|
_2_1_2
|
||||||
|
4: _1_2
|
||||||
|
5: _2_2_4
|
||||||
|
6: _2_2_1
|
||||||
|
7: _3_1
|
||||||
|
8: _1_1
|
||||||
|
9: _2_2_3
|
||||||
|
10: _2_2_2
|
||||||
|
11: _3_3
|
||||||
|
12: if (has_window)
|
||||||
|
_win1
|
||||||
|
else
|
||||||
|
_2_1_1
|
||||||
|
13: _3_4
|
||||||
|
14: _3_2
|
||||||
|
15: _4
|
||||||
|
|
||||||
|
For a complete example, a vertical cross wall graphic in an awall arch set
|
||||||
|
is named awall_F.base.111.png. Face information is kept in awall_F.face,
|
||||||
|
and the archetype data is in awall.arc. Inside awall.arc, the Object name
|
||||||
|
is awall_4.
|
||||||
|
|
||||||
|
Diagonal Walls and Roads
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
The legacy wall-naming convention is used in conjunction with the extension
|
||||||
|
to the name format described here to provide a uniform naming scheme that
|
||||||
|
supports corner connections. Legacy names do not need to change to simply
|
||||||
|
add diagonal versions of the legacy graphics.
|
||||||
|
|
||||||
|
The name format is 'name_XY.arc', 'name_XY.PDA.png'
|
||||||
|
|
||||||
|
X follows the same rules as used for the legacy wall format, except that
|
||||||
|
when there are no NSEW connecting points, X == 0.
|
||||||
|
|
||||||
|
Y may be omitted, or may be 0 if diagonal connecting points are not offered
|
||||||
|
by the arch. If diagonal connecting points are implemented, Y is a bit-wise
|
||||||
|
combination computed in the same manner as X, and is also expressed as a
|
||||||
|
hexadecimal digit. The difference is that it refers to corner connections:
|
||||||
|
|
||||||
|
1 2
|
||||||
|
\ /
|
||||||
|
X
|
||||||
|
/ \
|
||||||
|
8 4
|
||||||
|
|
||||||
|
For example, name_0F refers to a diagonal cross, or connecting points in
|
||||||
|
all four corners. name_05 and name_0A refer to pure diagonals.
|
||||||
|
|
||||||
|
Since diagonal pieces require corner fills, P is used to differentiate the
|
||||||
|
component parts of the diagonal.
|
||||||
|
|
||||||
|
P (part number) ranges from 1 to 3:
|
||||||
|
|
||||||
|
1 : used for "normal" pieces that connect direction points.
|
||||||
|
|
||||||
|
2 : used for a top corner fill needed to complete diagonal
|
||||||
|
connections.
|
||||||
|
|
||||||
|
3 : used for a bottom corner fill needed to complete diagonal
|
||||||
|
connections.
|
||||||
|
|
||||||
|
Examples of diagonal files are 'dirtroad_05.211', 'dirtroad_05.311',
|
||||||
|
'dirtroad_0A.211', and 'dirtroad_0A.311'. The archetypes for these are stored
|
||||||
|
in 'dirtroad_05.arc' and 'dirtroad_0A.arc'. The corner fill is a "part" of a
|
||||||
|
diagonal, and is not really useful on its own.
|
||||||
|
|
||||||
|
The '.211' and '.311' file names are based on the full diagonal, but are used
|
||||||
|
for all diagonal connecting points. Usually it is not necessary to
|
||||||
|
customize the corner piece to fit each and every possible XY combinationi
|
||||||
|
that incorporates a diagonal connecting point.
|
||||||
|
|
||||||
|
.Object Names
|
||||||
|
|
||||||
|
When creating object names, use a different format (_U_XYP) unless
|
||||||
|
the legacy naming format can be figured out and adapted to the
|
||||||
|
diagonal set - in which case, it should be documented here. This
|
||||||
|
format allows consistent object naming in the event that renaming is
|
||||||
|
desirable in the future, and it does not collide with the legacy
|
||||||
|
object naming.
|
||||||
|
|
||||||
|
U = Number of connecting points.
|
||||||
|
XY = Where X and Y are re-used as described above.
|
||||||
|
P = Where P is the part number.
|
||||||
|
|
||||||
|
Rivers
|
||||||
|
~~~~~~
|
||||||
|
WARNING: Consider deprecation of this format in favor of the extended wall
|
||||||
|
naming. It is more flexible than this format.
|
||||||
|
|
||||||
|
Simple diagonals, like non-branched rivers, are saved as 'name_XY.arc' and
|
||||||
|
'name_XY.PDA.png'.
|
||||||
|
|
||||||
|
X and Y use the direction scheme shown above (and copied here for ease of
|
||||||
|
reference). For example, river_15 runs north/south; river_26 runs from the
|
||||||
|
northeast to the southwest.
|
||||||
|
|
||||||
|
8 1 2
|
||||||
|
\ | /
|
||||||
|
7- 0 -3
|
||||||
|
/ | \
|
||||||
|
6 5 4
|
||||||
|
|
||||||
|
X and Y do not define direction of water flow. They are simply connecting
|
||||||
|
points to neighboring arches of the same set. X and Y are ordered low to
|
||||||
|
high, so it is not expected that a river_62 exist; instead the piece is
|
||||||
|
named river_26.
|
||||||
|
|
||||||
|
A cul-de-sac, or dead-end could have X == 0 and Y set to the connect point.
|
||||||
|
Conceptually, a pool could follow this same naming convention and set
|
||||||
|
X == Y == 0.
|
||||||
|
|
||||||
|
D and A are presently always set to 1.
|
||||||
|
|
||||||
|
P ranges from 1 to 3.
|
||||||
|
|
||||||
|
1 : used for "normal" pieces that connect direction points.
|
||||||
|
|
||||||
|
2 : used for a top corner wedge used to fill in diagonals (i.e. A
|
||||||
|
wedge in the top right or top left corner).
|
||||||
|
|
||||||
|
3 : used for a bottom corner wedge used to fill in diagonals (i.e.
|
||||||
|
A wedge in the bottom right or bottom left corner).
|
||||||
|
|
||||||
|
Examples of wedges are river_48.211, river_48.311, river_26.211, and
|
||||||
|
river_26.311. The archetypes for these are stored in river_48.arc and
|
||||||
|
river_26.arc. The wedge is a "part" of a diagonal, and is not really useful
|
||||||
|
on its own.
|
||||||
|
|
||||||
|
River junctions, add another digit to the format used by simple diagonals,
|
||||||
|
and are stored as name_XYZ.arc and name_XYZ.PDA.
|
||||||
|
|
||||||
|
X, Y, and Z represent the three directions the river exits. 367 would be
|
||||||
|
east,southwest, and west. Junctions, or branchesi, may also have multiple
|
||||||
|
parts - this happens when the junction has a diagonal direction.
|
||||||
|
|
||||||
|
By convention, directions for the river parts are in ascending order. That
|
||||||
|
is, if the exit locations are 2, 6, 3, the name could be branch_236 (not
|
||||||
|
branch_326, or branch_623, etc).
|
||||||
|
|
||||||
|
Complex branching paths could be set by adding digits to allow four or more
|
||||||
|
connecting points, but use of the extended walls format is recommended
|
||||||
|
instead.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue