crossfire
/
arch
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

- Major update of Naming.doc to improve description of existing content and 

add information on how to name related Objects in the .arc file.  Add a new
  naming convention that offers a standard way of naming diagonal items like
  walls and roads.


git-svn-id: svn+ssh://svn.code.sf.net/p/crossfire/code/arch/trunk@13375 282e977c-c81d-0410-88c4-b93c2d0d6712
master
kbulgrien 2010-06-08 03:24:14 +00:00
parent 678ddd9886
commit c7290780cf
2 changed files with 258 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
CHANGES
View File

@ -1,6 +1,19 @@
Changes for SVN top of tree: Changes for SVN top of tree:
============================================================================== ==============================================================================
Major update of Naming.doc to improve description of existing content and add
information on how to name related Objects in the .arc file. Add a new naming
convention that offers a standard way of naming diagonal items like walls and
roads. The diagonal naming merges well with the legacy naming and uses a
similar hex/bit-based notation and avoids use of compass points like NE, SW,
etc. in the file name (that do not merge for arches with many connecting
points). Add a note suggesting that the "river" naming be deprecated in favor
of the new "extended" wall naming scheme as it is more flexible than the
original river notation. Because the notation is based on the existing wall
format, it is also conceivable that an "auto-router" for diagonals could be
developed in the future.
Kevin Bulgrien 2010-06-07
Update several archetypes which had type of CLASS (37) but were not in Update several archetypes which had type of CLASS (37) but were not in
fact class archetypes and instead more often used as NPC or monsters. fact class archetypes and instead more often used as NPC or monsters.
Remove type so they default to monsters and give them some real stats. Remove type so they default to monsters and give them some real stats.

314
Naming.doc
View File

@ -1,86 +1,262 @@
archetype-file NAME.arc archetype-file NAME.arc
image-file NAME.PDA image-file
NAME.PDA
where
P - part number
D - coding, or any other instance
coding in
A - animation phase
where
P - part number
D - coding, or any other instance
coding in
A - animation phase
numbering, PDA numbering, PDA
- 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,...,Z
- alphanumerics - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, ..., Z
- can be thought as hexadecimals - Alphanumeric
- Can be thought as hexadecimals
name NAME: name NAME:
- maximum 10 characters long, so max file name is 14 characters,
that fit into portability requirements:
Part numbers - Maximum of 10 characters long, so max file name is 14 characters,
3x3 that fit into portability requirements
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 Part numbers:
\ | /
7- 0 -3
/ | \
6 5 4
- same as in crossfire
turnable (reflecting objects): 3x3 : 1 2 3
0 to left, vertical 4 5 6
1 to right, horizontal 7 8 9
- also in gates,signs, ...
walls: 2x2 : 1 2
1 3 4
|
8 -+- 2
|
4
- bit-combination; eg. 8 + 4 + 2 + 1 = F is cross, 3x2 : 1 2 3
4 + 1 = 5 is vertical wall. 4 5 6
river: 2x3 : 1 2
3 4
5 6
The non branched rivers are stored as river_XY.arc and river_XY.PDA Codings:
The XY use the direction scheme above (that is, river_15 runs
north/south). As of now, D and A are always 1. P will be up to
3, as rivers that run diagonally have wedges for the corners of the
adjacent spaces. These wedges are stored as 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.
Junctions are of the form branch_XYZ.[arc/111]. XYZ reperesent the Direction:
three directions the river exits. 367 would be east,southwest, and
west. Junctions may also have multiple parts - this happens when
the junction has a diagonal direction.
By convention, all directions for the river parts are in ascending 8 1 2
order. That is to say if the exit locations are 2,6,3, that would \ | /
be stored as branch_236. 7- 0 -3
/ | \
6 5 4
cave: Same as in Crossfire
-complex
modified: Turnable (reflecting objects):
93/08 hevi@lut.fi - created
94/05 master@rahul.net - updated river definitions. 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.
### end of README ###