[Freeciv-Dev] [bug #19858] enum compat_road MinGW compilation failure

[Marko Lindqvist]

Update of bug #19858 (project freeciv):

  Status:  Ready For Test => Fixed  
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #2365] [citizens11] convert a citizen to the nation of the owner each x turns

[Marko Lindqvist]

Update of patch #2365 (project freeciv):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #4:

> I'd go for percent probability each turn.

Patch with that approach.

We could port core functionality to S2_4, just using hardcoded conversion
probability instead of one read from rulesets (and transmitted over network
protocol)

(file #15928)
___

Additional Item Attachment:

File name: CitizensConvert.diff   Size:7 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #2365] [citizens11] convert a citizen to the nation of the owner each x turns

[Marko Lindqvist]

Update of patch #2365 (project freeciv):

 Planned Release:2.4.0, 2.5.0 => 2.5.0  

___

Follow-up Comment #3:

Must drop 2.4 target as this will change ruleset format.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Marko Lindqvist]

Follow-up Comment #7, patch #3345 (project freeciv):

Classic AI is omniscient enough to see units anyway, so this effect has no
value for it. One could argue that having negative value applied to its cities
(countering positive effects some human opponents may have) would have some
value for the AI, but I think it's ok just to always consider value of this
effect zero. That's simply less code to maintain (especially code of which we
don't know if we got it right in the first place - overvalue here could cause
X-rays-through-city-walls to be built instead of something that is *really*
needed)

But for completeness sake to answer you question about performance: First of
all there must be such an effect for it to be evaluated. Current rulesets
without such effects would never trigger the evaluation. Second, this is about
evaluating building value (though I sometimes wonder if it should be used for
evaluating other things in the future). So the effect in question must have
requirement of type "Building". Function gets called once for each such effect
(even if player is not able to build building in question yet - evaluated
value of such buildings is further used to evaluate value of the tech to allow
it) for each city in every turn change.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Sveinung Kvilhaugsvik]

Follow-up Comment #6, patch #3345 (project freeciv):

Good catch. I looked at the compilation output again and found the mentioned
warning now. I overlooked it among the information from make, translations,
etc. (I don't have much experience concerning developing in C.) Seems like I
(re)read the testing tips a bit to fast. (The AI vs AI games I ran tested no
effect, the effect activated by nationality and activated by a wonder I gave
using the editor) I'll use --enable-debug from now on. (CFLAGS=-Werror
./autogen.sh && make stops before it reaches aicity.c)

As far as I understand the function if aicity.c is an utility function for
effects. Would something like the number of known foreign cities not hidden by
a fog of war (perhaps divided by the number of player cities) weighted to be
reasonable be an appropriate measure here? Is this function called often
enough that its really important to be fast vs accurate? Are the built in AI's
still so omniscient (as the other comments indicate) that the function still
is about pretending its valuable?

I misunderstood what qualifies as a change to the network protocol. It will be
removed. My bias had me consider the problem from an angle closer to "will it
make it quick and easy for software to know things are different assuming the
other party isn't lying" than to "will it let human players see if they can
play without installing a new client".

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19871] Leader name female forms: Chairman vs Chairwoman/Chairperson, etc

[Jacob Nevins]

URL:
  

 Summary: Leader name female forms: Chairman vs
Chairwoman/Chairperson, etc
 Project: Freeciv
Submitted by: jtn
Submitted on: Fri Jun 29 22:13:16 2012
Category: rulesets
Severity: 2 - Minor
Priority: 3 - Low
  Status: None
 Assigned to: mixcoatl
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

While going through leader names for bug #19870, I catalogued some
inconsistencies in the female forms of leader names.

This doesn't list every instance where female != male; I assume some are
deliberate. These are just the most jarring examples (some of which I've
noticed before).

* In nations with a Chairman, the female equivalent is often Chairwoman but
sometimes Chairperson. I much prefer Chairwoman.
* Dictator => Dictatress, Dictatrix, or ?female:Dictator.
* Usually Sheikh => Shaykha, but Palestinian has "?female:Sheikh %s".
* Usually Stadtholder => Stadtholdress, but tyrolian has "Stadholdress" (just
a typo?)




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19870] Sort out female qualifiers on leader names

[Jacob Nevins]

Update of bug #19870 (project freeciv):

  Status: In Progress => Ready For Test 

___

Additional Item Attachment:

File name: trunk-S2_4-female-qualifiers.diff Size:9 KB
File name: S2_3-female-qualifiers.diffSize:2 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #18196] gtk2-client -> gtk3-client settings migration

[Marko Lindqvist]

Follow-up Comment #6, bug #18196 (project freeciv):

Patch. I consider this best compromise between cleanliness and functional
correctness. We don't currently know if settings in effect are initial
defaults, or if they are read from file (which can be identical to initial
defaults, of course). This has no bad effects here, as migrating from gtk2
settings even if they are just initial defaults merely causes gtk3 client
initial defaults to be "replaced" with identical values.

For similar needs in the future we should add another internal setting
"settings_from_file" that is FALSE unless loaded from conffile as TRUE (
secfile_lookup_bool_default(FALSE) ), and always saved as TRUE to conffile.

(file #15925)
___

Additional Item Attachment:

File name: Gtk3OptionsMigration.diff  Size:4 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19870] Sort out female qualifiers on leader names

[Jacob Nevins]

URL:
  

 Summary: Sort out female qualifiers on leader names
 Project: Freeciv
Submitted by: jtn
Submitted on: Fri Jun 29 21:51:42 2012
Category: rulesets
Severity: 2 - Minor
Priority: 3 - Low
  Status: In Progress
 Assigned to: jtn
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: Any
 Planned Release: 2.3.3,2.4.0,2.5.0

___

Details:

Some leader name strings have unnecessary i18n qualifiers, like
"?female:Empress". Since "Empress" generally also exists as a string in other
nations, this just makes work for translators.

While looking for these, it's easy to spot missing ?female: qualifiers too;
these will lead to localised male titles appearing inappropriately.

This doesn't make any more strings, so let's apply to S2_3 where applicable.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #16976] Certain ruler titles are used for more than one government

[Jacob Nevins]

Update of bug #16976 (project freeciv):

 Summary: Certain ruler titles are applied inconsistently =>
Certain ruler titles are used for more than one government


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #16976] Certain ruler titles are applied inconsistently

[Jacob Nevins]

Follow-up Comment #2, bug #16976 (project freeciv):

Quick look on trunk finds these instances:
* (m/f) Bishop: usually Fundamentalism, but congolesebrazzaville uses for
Monarchy
* Duke/Duchess: usually Despotism, but sammarinese uses for Monarchy
* %s Bey, which came up before here: evenly split between Monarchy (turkmen,
tunisian, lipkatatar) and Despotism (circassian, ghaznavid, seljuk).
** r18364 moved Tunisian from Monarchy to Despotism. Is that the right
direction for the others?
** (m/f) Speaker: usually Democracy, but toltec uses for Republic

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #16559] Display no-citybuilding area

[Jacob Nevins]

Follow-up Comment #3, bug #16559 (project freeciv):

See also bug #17102 and bug #18763.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17102] Restrictions on where settlers can build cities could be made clearer

[Jacob Nevins]

Follow-up Comment #10, bug #17102 (project freeciv):

See also bug #16559 (wherein it's noted that client knowledge of city building
restrictions is not perfect).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #18850] changing only cma will not be saved

[Jacob Nevins]

Follow-up Comment #3, bug #18850 (project freeciv):

See also bug #17156.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17156] Governor settings saved only upon end of turn

[Jacob Nevins]

Follow-up Comment #1, bug #17156 (project freeciv):

See also bug #18850.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17216] Need to press 'ok' twice to load a game

[Jacob Nevins]

Follow-up Comment #1, bug #17216 (project freeciv):

I don't recall seeing this. I can't reproduce it now, with head-of-S2_3
(r21391).

For me, it takes a little while before anything much visible happens after
pressing "OK" the first time, which is annoying, but stuff does happen
eventually.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17221] multiple units on a tile: only see top to the left...

[Jacob Nevins]

Follow-up Comment #3, bug #17221 (project freeciv):

I think this is a deliberate behaviour when "Arrange widgets for small
displays" is set, to reduce the space taken up by the sidebar.

Whether that setting should be the default is perhaps another matter.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3348] move unit popups in citydlg slightly

[Jacob Nevins]

Follow-up Comment #1, patch #3348 (project freeciv):

I haven't tried this patch so don't know exactly what it does, but perhaps it
will help with the user experience problem noted in bug #18754?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #18754] Unit context menu in city dialog too responsive

[Jacob Nevins]

Update of bug #18754 (project freeciv):

 Summary: Unit context menu too responsive => Unit context
menu in city dialog too responsive


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #18196] gtk2-client -> gtk3-client settings migration

[Marko Lindqvist]

Follow-up Comment #5, bug #18196 (project freeciv):

> So, stage is all yours.

Ahem, then again, this is the only ticket with 2.4.0-beta1 target, so I'm
checking it now, even risking duplicate work.

Looking options.c I now remember why I choce to duplicate all the options for
gtk3. Options are either shared with all clients, or are specific to certain
client. I don't know how cleanly we could implement special case for this that
some options are shared between gtk2 and gtk3, and only them.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19846] Closing unit select dialog asserts

[anonymous]

Follow-up Comment #2, bug #19846 (project freeciv):

OK, partially wrong call in the second case - I was testing a different thing
than I though I was.

It seems to only affect "Select" button.
For whatever the reason, unit_focus_update() called after USDLG_CMD_SELECT
makes it not work properly.

On that note: it would likely make sense to turn the first tab of the dialog
to a "pastebin" - that is to allow to select more than one unit in the dialog
and put the selection into this first tab as it gets build.
Also, it would be nice if selecting a unit from that dialog wouldn't select
units from the same field. As a corollary, perhaps "center" action (one called
on map by "c") could cycle through the list of selected units (instead of just
focusing on the first unit of the list) ?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Marko Lindqvist]

Follow-up Comment #5, patch #3345 (project freeciv):

I still have only read the patch - not even tried to compile, but a couple of
more points:
- Does it compile without warnings? When ever I add new effects, I get warning
from ai code that "case" for new effect value is missing from "switch" in
building evaluation.
- I think that strictly speaking this does not change network protocol, so no
need to change capstr. Server may send more unit packets than previously, but
I don't see how that would break old client.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19846] Closing unit select dialog asserts

[anonymous]

Follow-up Comment #1, bug #19846 (project freeciv):

There's quite a bit more:
- the original problem: AFAICT, it comes down to cursor-changed callback
getting run *after* row-activated callback, so that usdlg_get(FALSE) returns
NULL, as the dialog has already been destroyed
- the second part: "Select" button of this dialog seems to work only while in
first tab (I suspect other buttons to be affected too, though row-activated
callback works regardless of the tab)

Assertions don't seem to happen in gtk2 client (even if the buttons still fail
in the same way) - it seems that either it's a minor problem in gtk3 or
treeview is simply less strict there (i.e. I've noticed (IIRC in a different
project) that treeselection returned by a treeview seems to be initially NULL
in gtk3, while I haven't seen checks for such case in gtk2-based code).

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Marko Lindqvist]

Follow-up Comment #4, patch #3345 (project freeciv):

Well, I'm a bit ashamed that I just the other day made similar boolean check
effect ("Gov_Center") myself. I guess someone should go through all such
effects and change them from "!= 0" to "> 0".

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Sveinung Kvilhaugsvik]

Follow-up Comment #3, patch #3345 (project freeciv):

Thank you for the tip. I'll send an updated patch after I have tested it.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Marko Lindqvist]

Follow-up Comment #2, patch #3345 (project freeciv):

It mitght be good idea to check if effect value > 0 instead of only checking
if it's not NULL. That would make it easier to implement one effect that
enables vision (value: +1) and counter-effect that disables it (value: -1). If
only latter is active (or multiple counter-effects are active) total value
would be negative.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3345] View units in foreign cities

[Sveinung Kvilhaugsvik]

Follow-up Comment #1, patch #3345 (project freeciv):

Rename and base on current trunk.

(file #15924)
___

Additional Item Attachment:

File name: see_city_units.patch   Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19016] unit dialog spits out assertions with cimpletoon tilespec

[Marko Lindqvist]

Update of bug #19016 (project freeciv):

  Status:  Ready For Test => Fixed  
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19860] Typo in antarctican.ruleset: "Belgarno II"

[Jacob Nevins]

Update of bug #19860 (project freeciv):

  Status:  Ready For Test => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17289] Fixed-width tables look bad with wide characters

[Jacob Nevins]

Follow-up Comment #1, bug #17289 (project freeciv):

This would be a lot easier if we could assume the internal character set was
UTF-8. Cf patch #3027.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [patch #3027] libicu

[Jacob Nevins]

Follow-up Comment #1, patch #3027 (project freeciv):

In some ways it would be a lot easier if the internal character set could be
relied on to be UTF-8. For instance I know of portable code to fix bug #17289
without introducing platform dependencies, but only assuming UTF-8. Right now
I think I have to code as if it could be any character set (I might end up
with Shift-JIS or something), and so be very conservative in my assumptions --
is that right? (I can't immediately locate the developer documentation on
character sets, I'm sure I'm seen some somewhere.)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17301] Experimental ruleset enables 'foggedborders' without borders=SEE_INSIDE

[Jacob Nevins]

Follow-up Comment #6, bug #17301 (project freeciv):

> why is it that some borders are permanently visible while 
> others are ephemeral and will disappear from the map when 
> fogged? This behavior seems to be random.
So, this was probably bug #18588. The last few comments are a digression on
that.

So, this ticket is back to whether borders=SEE_INSIDE is a sensible default
accompaniment to foggedborders. I still wouldn't play without it, but two
experienced Freecivers disagreed, so...

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17304] Multiplayer ruleset: enable borders+foggedborders by default?

[Jacob Nevins]

Follow-up Comment #2, bug #17304 (project freeciv):

This got stalled due to uncertainty over whether borders=SEE_INSIDE is a good
idea for a default (see bug #17301). What would Longturn do?

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17347] Incorrect numerical sort order in Cities report.

[Jacob Nevins]

Update of bug #17347 (project freeciv):

  Status:Wont Fix => Fixed  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #19868] Network protocol documentation

[Sveinung Kvilhaugsvik]

URL:
  

 Summary: Network protocol documentation
 Project: Freeciv
Submitted by: sveinung
Submitted on: Fri 29 Jun 2012 09:02:23 AM GMT
Category: None
Severity: 1 - Wish
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

The file common/packets.def don't contain all the knowledge needed to
implement Freeciv's protocol. In addition to it various constants, data
structures etc are also required. I notices that some of those are labeled
with a comment warning developers the items are being used in the protocol.
How interesting would it be to label the rest? I have already created a buggy,
unfinished, over engineered and messy program that extract the extra
information from the C-source code (when it doesn't extract it wrong). Based
on its output I have created a draft for a patch that adds comments where I
couldn't find any.
 * Items in packets.h, connection.h are not labeled (as developers probably
expect that those files are protocol relevant)
 * Coding style not looked at as I don't know if anyone is interested in this
at all
 * Some recursive dependencies are ignored
 * May contain errors caused by bugs in my code
 * May contain errors caused by brain powering down during repetitive tasks
   * Wrong item may be labeled
   * An item with a similar name may have been labeled
   * I may have ignored already existing warning comments

If adding these comments is interesting I can have an extra look at my patch
and fix it for code style, double check items and create smaller patches for
specific areas if required. If some one want to do something else based on the
information my program extracts, like creating a new format including all
needed information or just have a staring point for better understanding the
Freeciv code base, let me know . While the generated Java code probably is
buggy it will give a hint about what items are needed.




___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev