Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Local variations to crossfire.



First, I'm sorry Geoff, for giving such a suggestion without reviewing
its feasibility first.

Second, I much prefer Petri's approach. Looks good, Petri!

[From the README]
> naming conventions in archetypes:
>     An archetype is defined in two different file. An in *.arch-
>     file, which defines characteristics as in "archetypes"-file.
>     And *.DD.AA-files, in which are the images of archetypes.
>     Formats are following:
>
>             NAME.PP.arch    - characteristic
>             NAME.PP.DD.AA   - images
>     where,
>             NAME    is a name of archetype like "troll"
>             PP      is a part of archetype, like in troll 01,02,03,04
>             DD      is a direction, coding is following in monsters:
> 
>                     07  04  06
>                       \  | /
>                     02 -09- 01
>                       /  | \
>                     05  03  08
>
>             AA      is a animation phase, like 01,02,03
> 
>     In characteristic file face & animation indexces are substituded
>     corresponding image-file names, eg "face troll.01.01.01"

This will break horrendously on SysV machines with 14-character
filenames... Yes, I know that there problems with non-unique long file
names already, 31 files, actually, and nearly all are in the
bitmaps-directory.

The .PP.DD.AA will use 9 characters, leaving only 5 for the
archetype-name. How about:

NAME-AADPP

   NAME    is a name of archetype like "orc"
   AA      is a animation phase, like 00, 01, 02, 03
   D       is a direction, coded as:
             y  k  u
              \ | /
             h -.- l     (looks familiar, I hope :-)
              / | \
             b  j  n
   XY      is a part of archetype, like in troll 00, 01, 10, 11

Also, we can have names on the form:

NAME       => NAME-00.00 (orc, one bitmap, no animation)
NAME-AA    => NAME-AA.00 (orc-01, means 2nd animation frame)
NAME-AAD   => NAME-AAD00 (orc-01l, as above facing right)
NAME-AADXY => NAME-AADXY (orc-01l01, as above, leftmost bottommost bitmap)
NAME-DXY   => NAME-00DXY (orc-l01, facing right, leftmost bottommost bitmap)
NAME-D     => NAME-00D00 (orc-l, facing right, no animation, one bitmap)

It would be nice, but not required, that the utility program
considered e.g. NAME-0D equivalent to NAME-D and NAME-00D00.

In perl: (yay, my first try at Perl-programming :-)
sub normalize {
  local($NAME, $AA, $D, $XY);

  ($NAME, $AA, $D, $XY) = (@_[0] =~ /^([^-]+)-?([0-9]*)([.kulnjbhy]?)([0-9]*)/);
  return sprintf("%s-%02d%s%02d", $NAME, $AA, $D ? $D : ".", $XY);
}

&normalize("orc-l") returns "orc-00l00"

Run normalize on both the specification in the *.arch and the file
lists (hey, that's what associative arrays are for :-)

Doing the reverse process, ie. making the filenames minimally short,
while keeping the names "giant-0l00" and "giant-1l10" (not "giant-l"
and "giant-1l10"), is a bit more tricky. I'll give it some thought and
perhaps try a little more perl-hacking.

Even if this proposal is shouted down (it does make writing utilities
parsing the filenames a little more difficult), please at least
consider using the XY for PP.


Kjetil T.