[Freeciv-Dev] Changes request

[Artur Biesiadowski <abies@xxxxxxxxx>]

Hi, I'm thinking seriously about creating java client for freeciv. I
will not do serious coding within month, but after that I would like to
spend some time on this. I have some questions/requests that would help
creating port tremedously and at the same time could make freeciv
maintance easier.

I could do some of this things, but I do not know freeciv internals well
and I have limited possibility of testing. I suppose that for somebody
with deep knowledge of freeciv they will be a lot easier to implement.

1) Externalize all data that is possible. One sure thing are citynames
for races, maybe there are others. Just move them to text files similar
to other things in data dir.
BTW There is a very strange thing in units.rules with special abilities.
Types of special abilities first are given in hardcoded order and later
given to units. I think that it is better to hardcode strings for
special abilities in program and add name/enum lookup table.

2) Enums. To create a maintainable port I would need an automatic parser
for it. I suppose that I'll end writing simple parser for .h files to
extract enums and put them in java class, but if anybody has any ideas
to make it easier/more reasonable please tell.

3) Image data. Xpm is not very good format (as it is noted in some doc)
and other format should be used. Plain RGBA (either 5-5-5-1 or 8-8-8-8)
seems reasonable to me.

4) In same doc there is a note about tile handling. There is too much
logic in client and TILE_KNOWN_NODRAW hack... I agree with statement
that it all should be handled by server. It would be good if it could be
resolved before I'll get deep into coding.

Note to point 4 - if server gives exact info about tile that should be
used, then tile and terrain type can be in fact separate things. This
allows for easy implementation of different images for exactly same tile
type/neighbours. I'm not sure if it is needed, but extra possibilities
do not hurt. I wonder if rotation of tile graphics can be done - this
way instead of 16 versions of given terrain, we would have to do only
1+1+2+1+1=6 types in resource file. It would reduce size consiredably.
This space could be used, for example, for two sets of same terrain
type.

Syntax for communicating tile image could be something like (few bits,
or just byte for each field):

- basic image id
- basic image rotation
- extra resource id
- roads/rails id
- roads/rails rotation
- irrigation/mine id
- maybe irrigation rotation (for connecting irrigations to each other or
sea/river)

If at some point river would be changed to original civ way, it could be
added to that list (with rotation).

I'll be available for few next days, so if you have any questions
concerning planned port or flames about above ideas feel free to
ask/flame. After that I'm going away for few weeks and during that time
somebody could implement needed changes to C code ;)


Artur