Is there any easy way to do this? The "crossedit" docs and options do not seem to have it.
The server code "image.c" makes it appear that it parses the "crossfire.0" and "crossfire.1"
files, but these are important-looking and I am not sure if I should be modding these
adding new BMPs and arches
Moderator: Board moderators
-
cavesomething
- Forum Fanatic
- Posts: 852
- Joined: Sun Jun 13, 2004 2:07 am
- Location: Hemel Hempstead
crossedit uses the server's image and archetype collections, so does the server when it is running.
In order for an archetype to be usable in a map, the server running that map must have it installed, along with an image to correspond to it.
The installed images and archetypes are collected from the arch tree, this process creates the crossfire.0 file you mentioned, as well as the archetypes file.
The current arch tree can be found at http://cvs.sourceforge.net/viewcvs.py/crossfire/arch/ and can be checked out from CVS or the (slightly outdated) stable version downloaded from the crossfire project page.
in your server source tree, you need to have lib/arch point to the root of the arch tree you just acquired, and then run 'make collect' in lib/ (having first run ./configure)
To add a new archetype, create the image you want to use, and save it as a PNG somewhere in the arch tree (preferably in the same place as any similar items), it should have the name foo.base.111.png (where foo is the type of item you are creating an image for). If you have multiple facings and animations, they should have different numbers. If your image is of a multiple tile object, the first '1' should be an x (so 'x11' not '111')
Then create a .arc file to correspond to that item, this should be called foo.arc, and at a minimum will need to have lines containing name foo, face foo.111. Other properties will need to be set depending on the type of item you are creating, so I suggest that you look at some of the other ,arc files for existing similar items to act as a guide (if you find yourself stuck, read http://cvs.sourceforge.net/viewcvs.py/* ... s?rev=1.20 or ask on the IRC channel #crossfire on Freenode, or post here)
when you have done all of this, running make collect again will create new crossfire.0, archetypes, etc files that correspond to the complete arch tree, reinstalling the server (running make install again) will sync the two trees, or you could just copy the new files in lib over the old ones
In any case for a map using new archs to be usable, requires, a map file, a .arc file for each archetype, and the PNG file(s) corresponding to the object(s). When you have created all of these, then if you post them on http://sourceforge.net/tracker/?group_i ... tid=313833 they can be included into the game for everyone else to use as well.
In order for an archetype to be usable in a map, the server running that map must have it installed, along with an image to correspond to it.
The installed images and archetypes are collected from the arch tree, this process creates the crossfire.0 file you mentioned, as well as the archetypes file.
The current arch tree can be found at http://cvs.sourceforge.net/viewcvs.py/crossfire/arch/ and can be checked out from CVS or the (slightly outdated) stable version downloaded from the crossfire project page.
in your server source tree, you need to have lib/arch point to the root of the arch tree you just acquired, and then run 'make collect' in lib/ (having first run ./configure)
To add a new archetype, create the image you want to use, and save it as a PNG somewhere in the arch tree (preferably in the same place as any similar items), it should have the name foo.base.111.png (where foo is the type of item you are creating an image for). If you have multiple facings and animations, they should have different numbers. If your image is of a multiple tile object, the first '1' should be an x (so 'x11' not '111')
Then create a .arc file to correspond to that item, this should be called foo.arc, and at a minimum will need to have lines containing name foo, face foo.111. Other properties will need to be set depending on the type of item you are creating, so I suggest that you look at some of the other ,arc files for existing similar items to act as a guide (if you find yourself stuck, read http://cvs.sourceforge.net/viewcvs.py/* ... s?rev=1.20 or ask on the IRC channel #crossfire on Freenode, or post here)
when you have done all of this, running make collect again will create new crossfire.0, archetypes, etc files that correspond to the complete arch tree, reinstalling the server (running make install again) will sync the two trees, or you could just copy the new files in lib over the old ones
In any case for a map using new archs to be usable, requires, a map file, a .arc file for each archetype, and the PNG file(s) corresponding to the object(s). When you have created all of these, then if you post them on http://sourceforge.net/tracker/?group_i ... tid=313833 they can be included into the game for everyone else to use as well.
-
cavesomething
- Forum Fanatic
- Posts: 852
- Joined: Sun Jun 13, 2004 2:07 am
- Location: Hemel Hempstead
I'm not sure I understand what you are asking, there shouldn't be any issues from a restricted colour palette nowadays, and you should be able to use any colours you wish.
A number of the images were converted from xpm files years ago, and as such use a limited number of colours, most of these are gradually being replaced (although with ~5000 images, you will appriciate that takes some effort.
However, keeping in the same style as other images is recommended, and part of that may involve using the same colour choices.
A number of the images were converted from xpm files years ago, and as such use a limited number of colours, most of these are gradually being replaced (although with ~5000 images, you will appriciate that takes some effort.
However, keeping in the same style as other images is recommended, and part of that may involve using the same colour choices.
-
cavesomething
- Forum Fanatic
- Posts: 852
- Joined: Sun Jun 13, 2004 2:07 am
- Location: Hemel Hempstead
The client-server protocol only sends 3 layers, quite how it decides which ones to send is interesting, but from memory, it is roughly
1) highest (in the stacking order) tile which is a 'floor'
2) an item (can't recall how it decides which one).
3) the top item (in the stacking order).
It does not composite the images server side (to do so would probably be a bad idea anyway)
This is why if you cast spells towards a monster standing on a table, the table will sometimes disappear when the spell effect passes over.
This also means that if a monster walks over multiple objects, they will flip between layers. - this is one of the main motivations for wanting to write a new command, to handle this better (see: http://wiki.metalforge.net/doku.php/dev ... approtocol for the outline planning of this).
1) highest (in the stacking order) tile which is a 'floor'
2) an item (can't recall how it decides which one).
3) the top item (in the stacking order).
It does not composite the images server side (to do so would probably be a bad idea anyway)
This is why if you cast spells towards a monster standing on a table, the table will sometimes disappear when the spell effect passes over.
This also means that if a monster walks over multiple objects, they will flip between layers. - this is one of the main motivations for wanting to write a new command, to handle this better (see: http://wiki.metalforge.net/doku.php/dev ... approtocol for the outline planning of this).
Could someone explain why we are copying opaque and see-through images to a "xpm_pixmap" at 0, 0 for multiple layers, and then copying it back to the screen at the correct coords?
Conversely, why is it that when I try to copy additional things to "xpm_pixmap" in the loop before it is drawn on screen, it doesnt show up when "xpm_pixmap" is printed to the screen?
Conversely, why is it that when I try to copy additional things to "xpm_pixmap" in the loop before it is drawn on screen, it doesnt show up when "xpm_pixmap" is printed to the screen?