[Freeciv-Dev] Re: (PR#3708) new isotrident_shields tileset

["DHerding@xxxxxx" <DHerding@xxxxxx>]

Hello Jason,

Friday, March 21, 2003, 10:33:28 PM, you wrote:


JS> When I try to use it, I get a bunch of warning messages like

JS> 1: warning: already have a sprite for f.serbia

This is strange. In fact, my isotrident_shields.tilespec has included
"isotrident/flags.spec" as well as "isoshields/shields.spec", which
probably leads to that warning. I used it because, in case someone
updated his flags but didn't update his shields, Freeciv will show the
flag instead of nothing when using isotrident_shields. See comment in
tilespec files:

; Below, the graphics spec files; must be somewhere (anywhere) in
; the data path. Order may be important for color allocation on 
; low-color systems, and if there are any duplicate tags (lattermost
; tag is used).

I thought this means that it wouldn't lead to problems when e.g.
f.serbia is duplicate, and freeciv would simply use the one from
isoshields/shields.spec. I also can't reproduce that warning.

JS> and then the isotrident_shields ends up looking exactly like isotrident.
JS>  I also get this (under your "patch") when using trident_shields.

Maybe you didn't extract the files to the correct directories? (you
must create a subdirectory 'isoshields' in the same directory where your
'isotrident' subdirectory is)

Also remember that e.g. in the GTK distribution, you have XPM files
which are preferred against PNGs by Freeciv. When you copy the PNG
files from my archive, make sure to delete any XPMs that have the same
names.

JS> I have a lot of other tilesets installed in different locations, and
JS> possibly different PNG or specfiles are conflicting with each other. 
JS> But this shouldn't happen if the tileset is structured properly.

JS> For development of the tileset, I'd recommend not *replacing* any of the
JS> files from the standard distribution.  If you need to change something,
JS> just introduce a new file (you can still use the old graphics files,
JS> referenced by your own specfiles - just don't change any graphics or
JS> spec files).  Then the tileset can be added to the set of contributed
JS> tilesets, and it can be easily downloaded and used.

That's exactly what I tried to do. Take a look at units.png, or
tiles.png. I only entered the graphics that are different from the
isotrident ones, and my tileset will share the other graphics with
isotrident / trident_shields.

The problem e.g. with isotrident/shields.png is that I can't use the
original files because I need some transparent pixels left to the
shields, and above it. But the authors of shields.png set the first
shield to the upper left of the file, so I had to insert some
transparent lines/rows to the file.

Having some transparent space between tiles, and at the borders of the
graphics file, increases flexibility for future tileset development.

I'm aware that this will conflict with any other specfile that
accesses shields.png/chiefs.png. But I think it's a necessary step to make
possible what you described above.

JS> If we decide to include this tileset in the core distribution (i.e., put
JS> it in CVS) then we can compress and merge the graphics with the existing
JS> tilesets.  Here we have to be careful to avoid conflicts.



JS> jason



-- 
Best regards,
 Daniel