version 1.1 | | version 1.2 |
---|
| | |
The server uses the image number, the long name, and the fallback. | | 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 | | The long name can be used when the client requests the images it |
gets sent. | | 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. |