| 1 |
root |
1.1 |
url:http://crossfire.freezope.org/docs/Developer%20Docs/images |
| 2 |
|
|
meta_type:BackTalk Document |
| 3 |
|
|
auth:Basic VG9kZDpyb2NrcG9ydHJvdmVy |
| 4 |
|
|
cookie:tree-s="eJzTiFZ3BAOngNSIZFv1WB1NADFEBPk"; fzf_cookie="1" |
| 5 |
|
|
|
| 6 |
|
|
Making Crossfire Images |
| 7 |
|
|
|
| 8 |
|
|
Rules for image sets: |
| 9 |
|
|
|
| 10 |
|
|
1. Image format for all images should |
| 11 |
|
|
be png. |
| 12 |
|
|
|
| 13 |
|
|
2. There must be an active maintainer of each of the image sets. If a set |
| 14 |
|
|
gets too out of date because of no maintainer, that particular set gets |
| 15 |
|
|
removed. |
| 16 |
|
|
|
| 17 |
|
|
3. When new arch (and image) is introduced, only an image for the main set is |
| 18 |
|
|
required. It is up to the maintainers of the different sets to make an image |
| 19 |
|
|
if the default one is not appropriate. |
| 20 |
|
|
|
| 21 |
|
|
4. There must be a reason for adding a new set. This generally equates |
| 22 |
|
|
to enough people expressing interest in the set, or the number of new images |
| 23 |
|
|
is substantial enough to warrant the addition. The use of image sets |
| 24 |
|
|
is not for making a set with 10 images because you prefer those over |
| 25 |
|
|
some in another set. |
| 26 |
|
|
|
| 27 |
|
|
5. Naming works like this: If the image name is Bk.272, then the |
| 28 |
|
|
actual file name would be Bk.*set*.272.png where *set* is a four letter |
| 29 |
|
|
abbreviation that has some relevance to the set name. An example would be |
| 30 |
|
|
Bk.*clsc*.272.png, where *clsc* is the classic image set. The arch of course |
| 31 |
|
|
would only refer to BK.272 |
| 32 |
|
|
|
| 33 |
|
|
6. Whenever adding a new image set, update the |
| 34 |
|
|
lib/image_info file |
| 35 |
|
|
|
| 36 |
|
|
7. Image sets only provide alternate images - |
| 37 |
|
|
the .arc files are remained unchanged by the addition of image sets. |
| 38 |
|
|
An arch must have a graphic from the *base* set, graphic from additional |
| 39 |
|
|
image sets are optional, but if an arch has one image version -it has to be called base. |
| 40 |
|
|
|
| 41 |
|
|
|
| 42 |
|
|
|
| 43 |
|
|
Internal working of image sets: |
| 44 |
|
|
|
| 45 |
|
|
All images within crossfire are still known without the set or png |
| 46 |
|
|
extension. Thus, for archetypes, the image name is sword.111, not |
| 47 |
|
|
sword.base.111.png. |
| 48 |
|
|
The collect script only collects the images for the set. If the client |
| 49 |
|
|
requests an image that is not in the set it is using, the server will |
| 50 |
|
|
use the fallback logic to find an image to send to the client. Collecting |
| 51 |
|
|
only the images in the set results in smaller installed image files, |
| 52 |
|
|
a smaller memory footprint for the server, and faster loading time. |
| 53 |
|
|
|
| 54 |
|
|
|
| 55 |
|
|
The server does not care about the image content. As far as the server |
| 56 |
|
|
is concerned, it is just a bunch of bits it serves to the client. |
| 57 |
|
|
The server uses the image number, the long name, and the fallback. |
| 58 |
|
|
The long name can be used when the client requests the images it |
| 59 |
|
|
gets sent. |
| 60 |
|
|
|
| 61 |
|
|
|
| 62 |
|
|
Combining individual small images into 1 big image: |
| 63 |
|
|
|
| 64 |
|
|
|
| 65 |
|
|
There are a great many objects in crossfire that are bigger than one square. |
| 66 |
|
|
Prior to this writing (May 18, 2002), there was no way to combine these into |
| 67 |
|
|
one big image. The server and unix clients now support this. |
| 68 |
|
|
|
| 69 |
|
|
1. Evaluate if the archetype should be as many spaces as the image may extend |
| 70 |
|
|
into. For example, a tower is tall, and even though the image may represent |
| 71 |
|
|
that, it should probably only be a single square object. But there are other |
| 72 |
|
|
objects, such as shops, which are short but large, and thus should be 2x2 |
| 73 |
|
|
square multipart objects. |
| 74 |
|
|
|
| 75 |
|
|
2. A combined image doesn't have parts anymore, so the first digit isn't |
| 76 |
|
|
meaning. Using an 'x' as the part number is a good notation to show that |
| 77 |
|
|
this is in fact a big image (eg, store_alch.x11). |
| 78 |
|
|
|
| 79 |
|
|
3. It is not possible to have combined images in one image set and non combined |
| 80 |
|
|
in another. What this basically means is that the base set should always have |
| 81 |
|
|
a combined image, with the other sets possibly having such images - since the |
| 82 |
|
|
name of the combined image will be different, until any other sets are updated, |
| 83 |
|
|
they will just use the image in the base set. |
| 84 |
|
|
|
| 85 |
|
|
4. the .arc file needs to be modified so that the face for all the different |
| 86 |
|
|
parts of an image are the same. The server makes this check based on name to |
| 87 |
|
|
know if it should handle this object as a combined image or not. |
| 88 |
|
|
|
| 89 |
|
|
5. Rebuild the archetypes, collect the images, and install. |
| 90 |
|
|
|
