url:http://crossfire.freezope.org/docs/Developer%20Docs/images
meta_type:BackTalk Document
auth:Basic VG9kZDpyb2NrcG9ydHJvdmVy
cookie:tree-s="eJzTiFZ3BAOngNSIZFv1WB1NADFEBPk"; fzf_cookie="1"

Making Crossfire Images

 Rules for image sets:

  1. Image format for all images should 
be png.

  2. There must be an active maintainer of each of the image sets.  If a set
gets too out of date because of no maintainer, that particular set gets
removed.

  3. When new arch (and image) is introduced, only an image for the main set is
required.  It is up to the maintainers of the different sets to make an image
if the default one is not appropriate.

  4. There must be a reason for adding a new set.  This generally equates
to enough people expressing interest in the set, or the number of new images 
is substantial enough to warrant the addition.  The use of image sets
is not for making a set with 10 images because you prefer those over
some in another set.

  5. Naming works like this: If the image name is Bk.272, then the
actual file name would be Bk.*set*.272.png where *set* is a four letter
abbreviation that has some relevance to the set name.  An example would be 
Bk.*clsc*.272.png, where *clsc* is the classic image set.  The arch of course 
would only refer to BK.272

  6. Whenever adding a new image set, update the 
lib/image_info file

  7. Image sets only provide alternate images - 
the .arc files are remained unchanged by the addition of image sets.
An arch must have a graphic from the *base* set, graphic from additional 
image sets are optional, but if an arch has one image version -it has to be called base.



 Internal working of image sets:

  All images within crossfire are still known without the set or png
extension.  Thus, for archetypes, the image name is sword.111, not
sword.base.111.png.
 The collect script only collects the images for the set.  If the client
requests an image that is not in the set it is using, the server will
use the fallback logic to find an image to send to the client.  Collecting
only the images in the set results in smaller installed image files,
a smaller memory footprint for the server, and faster loading time.


 The server does not care about the image content.  As far as the server
is concerned, it is just a bunch of bits it serves to the client.
 The server uses the image number, the long name, and the fallback.
The long name can be used when the client requests the images it
gets sent.


 Combining individual small images into 1 big image:


  There are a great many objects in crossfire that are bigger than one square.
Prior to this writing (May 18, 2002), there was no way to combine these into
one big image.  The server and unix clients now support this.

   1. Evaluate if the archetype should be as many spaces as the image may extend
into.  For example, a tower is tall, and even though the image may represent
that, it should probably only be a single square object.  But there are other
objects, such as shops, which are short but large, and thus should be 2x2
square multipart objects.

   2. A combined image doesn't have parts anymore, so the first digit isn't
meaning.  Using an 'x' as the part number is a good notation to show that
this is in fact a big image (eg, store_alch.x11).

   3. It is not possible to have combined images in one image set and non combined
in another.  What this basically means is that the base set should always have
a combined image, with the other sets possibly having such images - since the
name of the combined image will be different, until any other sets are updated,
they will just use the image in the base set.

   4. the .arc file needs to be modified so that the face for all the different
parts of an image are the same.  The server makes this check based on name to
know if it should handle this object as a combined image or not. 

   5. Rebuild the archetypes, collect the images, and install.