Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852
After looking at airgoto code some more, found (more than one) function on
the server side that looks for an airbase. Copied part here.
Essentially no change for AI.
The user can run the aircraft any direction for 1/2 move, *and* another
1/2 move that takes it near a possible airbase. This allows setting
waypoints anywhere on a path (outgoing and incoming) near an airbase.
I ran many trials removing the restriction on single flight paths (that is,
letting it self-select a refueling base on the way to P1, as it did
initially). The code already exists. It works sometimes
As you may remember, in the early messages of this PR, it refueled at P5
for me, but not for you. After many boring tests (restart, test, quit, ...),
it has become clear that some code doesn't work consistently.
Sometimes it refuels at P5, other times P7, and sometimes, it just jogs
around P5 and dies. Trying to go to P3 or P8, it always makes a straight
path just past P5 over the engineer, never refuels, and dies.
There must be some kind of random path selection between equal paths, but
they didn't use a standard function, and I cannot find it! Or maybe it's
an uninitialized variable.
Therefore, for 2.1.1, I'm leaving in the restriction. If you need to
specify refueling on a long path, use waypoints. They always work.
For 2.2 (or 2.3), we can look at better combining the 4 different path
selection methods (with 2 different Dijkstra implementations)!
Committed S2_1 revision 13958.
Index: common/aicore/pf_tools.c
===
--- common/aicore/pf_tools.c(revision 13957)
+++ common/aicore/pf_tools.c(working copy)
@@ -550,8 +550,9 @@
{
int moves = SINGLE_MOVE * real_map_distance(param-start_tile, ptile);
int have = get_moves_left_initially(param);
+ int left = have - moves;
- if (have moves) {
+ if (left 0) {
/* not enough fuel. */
return TRUE;
}
@@ -576,6 +577,14 @@
return FALSE;
}
+ /* similar to find_nearest_airbase() */
+ iterate_outward(ptile, left / SINGLE_MOVE, atile) {
+if (TILE_UNKNOWN != tile_get_known(atile, param-owner)
+ is_possible_base_fuel(atile, param)) {
+ return FALSE;
+}
+ } iterate_outward_end;
+
/* Carriers are ignored since they are likely to move. */
return TRUE;
}
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Committed S2_2 revision 13959. Committed trunk revision 13960. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 It is getting better. But... * Units still can move of the half of their moves and die when they go to dangerous positions. * Way points don't work well since all far positions are considered as dangerous. You must finish the turn (with 0 move only) to use them. For example, you cannot move to P1 if you move first to P7 and P8 before. To fix this, you have to make the all cities or airbases as safe places, then the pf code will make a dangerous path. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [wsimpson - Jeu. Nov. 15 14:56:13 2007]: Pepeto _ wrote: * Units still can move of the half of their moves and die when they go to dangerous positions. By design. Sadly yes. * Way points don't work well since all far positions are considered as dangerous. ... Obviously, there is a language or comprehension problem. Please re-read the earlier discussion. Don't cut my comment. The explanation is written after. Waypoints are working as designed. The pf dangerous path code does not, and will not be used, because it has been superceded by waypoints. I just said that Waypoints don't work well. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Try to move to P1... airgoto.sav.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [dmarks - Mer. Nov. 14 11:37:18 2007]: On 11/14/07, Pepeto _ [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [pepeto - Mar. Nov. 13 15:14:19 2007]: - You cannot move on all tiles you should be able to move to. For example, you cannot choose your path when the unit has only the half of its moves. Actually, it's when you are in a potential dangerous position. - Suicidal attack are supposed to be only for unit with the flag F_MISSILE only. Else, this is dangerous. Yes, this is dangerous. But it's also up to the player to decide if it's worth sacrificing the air unit or not. I don't think so. If people want to move to dangerous positions they should use numerical keyboard (like for triremes or land unit to dangerous terrain). ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [dmarks - Mer. Nov. 14 11:37:18 2007]: - A unit with 2 turns of fuel (example AWACS or Bomber) always can move of it's half of it's moves, including when it's lost in the middle of the ocean. Then it dies. This is indeed a problem. It seems the code always assumes an air unit starts its turn on a safe tile, which is (practically) never the case when a two turn air unit starts its second turn of a mission. Actually, the only time a goto to an unsafe tile should be allowed for a non-attack move on the last turn of a mission is when the air unit sits on a safe tile. ~Daniel That's maybe why I thought about a unsafe status for positions. The theory of it is very clear: * safe: we can end there at the end of the turn to refuel * unsafe: we cannot refuel there, but there is position to do in range * dangerous: if we move there, we lose it. But carriers are still a big problem. Maybe there isn't any good solution. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 - It ignores if unit hasn't its full moves left. For example, if your unit already did some move this turn, it check as your unit didn't make this moves. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 I'm using MacOS 10.3.9, standard iso Amplio (shouldn't make a difference), and standard GTK2 (shouldn't make a difference). We are talking about a fighter to the S of the continent, in the middle of the ocean. It has moves (7)7. Daniel Markstedt wrote: - Can issue goto to any unsafe tile within its current moves. The unit dies on EOT. Let's concentrate on this. This may be a difference of desired results. As I have deliberately re-written the code, it displays the unreachability of any tile more than it has enough fuel -- more than 7 away. * On the 7th tile, the cursor turn number changes from 0 to 1. This seems a little odd to me, but I didn't change it, as I presumed this was chosen for/by the gui designer. (I don't like it, slightly confusing.) * On the 8th tile, it displays a forbidden symbol. (This is part of the bug fix -- it used to display forbidden on the 7th tile.) It will not allow this distance to be selected. It will reach anywhere it has enough fuel, even places it will die. It has to work this way, or you would be unable to set waypoints on its way home. Waypoints was one of the bugs fixed. I'm presuming that the user is not so stupid that they dump the unit in the ocean. However, I didn't want the *code* to keep *me* from doing it But now, I'm thinking about what happens to an AI using this code. It probably *would* just dump it in the ocean. So, I could change the code to prevent it for AI (or allow it for users). The pseudonymous puppeteer also suggested (in his inimitable way) that the code also disallow being able to return to the current dangerous position. Not a goal for a human (it's obviously wrong), but maybe useful for an AI? - Can issue goto to city two turns away, e.g. PY. The unit does not refuel in city and dies on EOT. When I tested before, it automatically went into P5. Perhaps that was an accident of the path. Testing to PY, you are correct. It inexplicably runs out over the S ice continent. The code path chooser is flaky. This requires thought. I only fixed a particular callback, not the entire path chooser! That would be a different PR! - Can not issue goto to city more than two turns away, e.g. P1. If you set a waypoint in P5, you can go on to P1. That's one of the things that waypoints are for Perhaps the goto.c struct part code should keep a tally on a per waypoint basis about refueling. That would allow truly long term planning. But why? I certainly don't make moves for more than 2 turns, and I doubt the AI could cope!?!? And is this a 2.1 project goal? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Pepeto _ wrote: - It ignores if unit hasn't its full moves left. For example, if your unit already did some move this turn, it check as your unit didn't make this moves. Amazingly, you are actually correct. I tried moving the fighter one move, the display correctly shows (6)6 -- but the code passes in the value 7 to the callback function! Yet another annoying bug in the badly written pathfinding code. My guess is the entire thing needs to be reviewed -- some logic error elsewhere the fuel isn't being properly decremented. (All I can easily find are the places it's _correctly_ decremented.) But since the visual display is correct, this should not delay 2.1.1. I don't think we should be doing any more than fixing crashers. Code improvements are for *.minor.* releases, not *.*.trivial releases. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [wsimpson - Mar. Nov. 13 10:51:44 2007]: Pepeto _ wrote: - It ignores if unit hasn't its full moves left. For example, if your unit already did some move this turn, it check as your unit didn't make this moves. Amazingly, you are actually correct. I tried moving the fighter one move, the display correctly shows (6)6 -- but the code passes in the value 7 to the callback function! Yet another annoying bug in the badly written pathfinding code. My guess is the entire thing needs to be reviewed -- some logic error elsewhere the fuel isn't being properly decremented. (All I can easily find are the places it's _correctly_ decremented.) But since the visual display is correct, this should not delay 2.1.1. I don't think we should be doing any more than fixing crashers. Code improvements are for *.minor.* releases, not *.*.trivial releases. For this bug, there is a very simple trick to change: - int fuel = param-move_rate * param-fuel_left_initially; + int fuel = param-moves_left_initially + param-move_rate * (param-fuel_left_initially - 1) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 On 11/13/07, William Allen Simpson [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 I'm using MacOS 10.3.9, standard iso Amplio (shouldn't make a difference), and standard GTK2 (shouldn't make a difference). I have the same setup, incidentally. We are talking about a fighter to the S of the continent, in the middle of the ocean. It has moves (7)7. Daniel Markstedt wrote: - Can issue goto to any unsafe tile within its current moves. The unit dies on EOT. Let's concentrate on this. This may be a difference of desired results. As I have deliberately re-written the code, it displays the unreachability of any tile more than it has enough fuel -- more than 7 away. * On the 7th tile, the cursor turn number changes from 0 to 1. This seems a little odd to me, but I didn't change it, as I presumed this was chosen for/by the gui designer. (I don't like it, slightly confusing.) * On the 8th tile, it displays a forbidden symbol. (This is part of the bug fix -- it used to display forbidden on the 7th tile.) It will not allow this distance to be selected. It will reach anywhere it has enough fuel, even places it will die. It has to work this way, or you would be unable to set waypoints on its way home. Waypoints was one of the bugs fixed. I'm presuming that the user is not so stupid that they dump the unit in the ocean. However, I didn't want the *code* to keep *me* from doing it But now, I'm thinking about what happens to an AI using this code. It probably *would* just dump it in the ocean. So, I could change the code to prevent it for AI (or allow it for users). The pseudonymous puppeteer also suggested (in his inimitable way) that the code also disallow being able to return to the current dangerous position. Not a goal for a human (it's obviously wrong), but maybe useful for an AI? I'm generally for freedom. If the player wants to goto their stealth fighter to certain death, the gui should allow them to do it. It's not uncommon to make suicide attacks with air units anyway. Let's leave this behavior as it is. - Can issue goto to city two turns away, e.g. PY. The unit does not refuel in city and dies on EOT. When I tested before, it automatically went into P5. Perhaps that was an accident of the path. Testing to PY, you are correct. It inexplicably runs out over the S ice continent. The code path chooser is flaky. This requires thought. I only fixed a particular callback, not the entire path chooser! That would be a different PR! The issue here is that the pathfinding code believes this goto can be completed, while the poor stealth fighter in fact only gets halfway and crashes. It must somehow believe the air unit will become refuled just because a friendly city is nearby. This is IMHO in the scope of this ticket. - Can not issue goto to city more than two turns away, e.g. P1. If you set a waypoint in P5, you can go on to P1. That's one of the things that waypoints are for Perhaps the goto.c struct part code should keep a tally on a per waypoint basis about refueling. That would allow truly long term planning. But why? I certainly don't make moves for more than 2 turns, and I doubt the AI could cope!?!? And is this a 2.1 project goal? Certainly not for 2.1. It would be a useful feature if city-hopping could be done automagically, but as you say it can be done with waypoints. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Forgot to mention, I also discovered that you could locate unseen units in the field by using goto to detect attack points. So, I added some checking to stop the cheat. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Very better. But still some problems: - You still cannot reach P1, and waypoints don't help me. Anyway, I don't think they should be needed to use air goto. For a land unit, you don't need to define a new way point for every turn, why should it be different for air goto. - You cannot move on all tiles you should be able to move to. For example, you cannot choose your path when the unit has only the half of its moves. - Helicopters still doesn't work. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [pepeto - Mar. Nov. 13 15:14:19 2007]: - You cannot move on all tiles you should be able to move to. For example, you cannot choose your path when the unit has only the half of its moves. Actually, it's when you are in a potential dangerous position. - Suicidal attack are supposed to be only for unit with the flag F_MISSILE only. Else, this is dangerous. - A unit with 2 turns of fuel (example AWACS or Bomber) always can move of it's half of it's moves, including when it's lost in the middle of the ocean. Then it dies. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Pepeto _ wrote: and say me that this stealth fighter can move to P1 and not go to dangerous positions. Verified. The stealth fighter, currently in the middle of the ocean, with 7/7 remaining, is unable to go to any dangerous position. It could reach P1 on the other side of the continent on the next turn. The code causes it to stop in P5 and refuel on the way. Works (as all my previous tests have indicated.) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852
Committed S2_1 revision 13941.
Committed S2_2 revision 13942.
Committed trunk revision 13943.
The slightly different S2_2/trunk patch for posterity:
Index: common/aicore/pf_tools.c
===
--- common/aicore/pf_tools.c(revision 13941)
+++ common/aicore/pf_tools.c(working copy)
@@ -546,31 +546,32 @@
enum known_type known,
struct pf_parameter *param)
{
- struct base_type *pbase;
+ struct base_type *pbase = tile_get_base(ptile);
int moves = SINGLE_MOVE * real_map_distance(param-start_tile, ptile);
- int fuel = param-fuel_left_initially - 1;
+ int fuel = param-move_rate * param-fuel_left_initially;
- if (is_allied_city_tile(ptile, param-owner)) {
+ if (fuel moves) {
+/* not enough fuel. */
+return TRUE;
+ }
+
+ if (fuel = moves * 2) {
+/* has enough fuel for round trip. */
return FALSE;
}
- pbase = tile_get_base(ptile);
-
- if (pbase is_native_base_to_uclass(pbase, param-uclass)) {
+ if (fuel = moves
+(is_allied_city_tile(ptile, param-owner)
+|| (pbase is_native_base_to_uclass(pbase, param-uclass {
/* All airbases are considered non-dangerous, although non-allied ones
* are inaccessible. */
return FALSE;
}
- if (param-moves_left_initially + param-move_rate * fuel = moves * 2) {
-if (param-fuel_left_initially 1
-|| ((param-fuel_left_initially 2
- || !BV_ISSET(param-unit_flags, F_ONEATTACK))
- (is_enemy_unit_tile(ptile, param-owner)
-|| (ptile-city is_enemy_city_tile(ptile, param-owner)
{
- /* allow movement if fuelled, and attacks, even suicidal ones */
- return FALSE;
-}
+ if (is_enemy_unit_tile(ptile, param-owner)
+ || is_enemy_city_tile(ptile, param-owner)) {
+/* allow attacks, even suicidal ones */
+return FALSE;
}
/* Carriers are ignored since they are likely to move. */
@@ -629,7 +630,7 @@
parameter-get_MC = single_airmove;
break;
default:
-freelog(LOG_ERROR, Impossible move type to pft_fill_unit_parameter()!);
+freelog(LOG_ERROR, pft_fill_unit_parameter() impossible move type!);
break;
}
@@ -670,7 +671,7 @@
parameter-get_MC = single_airmove; /* very crude */
break;
default:
-freelog(LOG_ERROR, Impossible move type to
pft_fill_unit_overlap_param()!);
+freelog(LOG_ERROR, pft_fill_unit_overlap_param() impossible move type!);
break;
}
@@ -701,7 +702,7 @@
parameter-get_MC = single_airmove; /* very crude */
break;
default:
-freelog(LOG_ERROR, Impossible move type to
pft_fill_unit_attack_param()!);
+freelog(LOG_ERROR, pft_fill_unit_attack_param() impossible move type!);
break;
}
@@ -754,8 +755,8 @@
struct unit *punit)
{
parameter-turn_mode = TM_CAPPED;
+ parameter-unknown_MC = SINGLE_MOVE;
- parameter-unknown_MC = SINGLE_MOVE;
if (uclass_has_flag(unit_class(punit), UCF_TERRAIN_SPEED)) {
/* Unit is subject to terrain movement costs */
struct unit_type *punittype = unit_type(punit);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [wsimpson - Lun. Nov. 12 15:47:11 2007]: Works (as all my previous tests have indicated.) Doesn't. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 [wsimpson - Mon Nov 12 15:47:11 2007]: Pepeto _ wrote: and say me that this stealth fighter can move to P1 and not go to dangerous positions. Verified. The stealth fighter, currently in the middle of the ocean, with 7/7 remaining, is unable to go to any dangerous position. It could reach P1 on the other side of the continent on the next turn. The code causes it to stop in P5 and refuel on the way. Works (as all my previous tests have indicated.) Issues as of S2_1 r13943: - Can issue goto to any unsafe tile within its current moves. The unit dies on EOT. - Can issue goto to city two turns away, e.g. PY. The unit does not refuel in city and dies on EOT. - Can not issue goto to city more than two turns away, e.g. P1. ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 That's right, this function is wrong, else, there shouldn't be any problem. Your patch forbid the moves for path bigger than 1 turn. You should name your fuel variable moves_left or something like this, since it's a number of moves and not a number of turn for the fuel. I think that is_pos_dangerous_fuel() should be used for all types of moves if there is fuel. Why shouldn't be a ruleset with a land fueled unit? As long that helicopter is not a fueled unit, there shouldn't be any dangerous position, or a special function for it (but it could be very slow). Helicopter moves still cannot work with this patch, except if you have the United Nations wonder. And as I remember, Per said, helicopter shouldn't have dangerous position, the users just should take care of it. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Pepeto _ wrote: I think when you will get all this, you will conclude on a quite identical patch than PR#20772. The rejected patch(es) in PR#20772 did not address the underlying problem that this patch corrects. Those patches demonstrate that you didn't understand the code very well. Heck, that's fairly likely, as the code was not well documented. They also demonstrate that you didn't thoroughly test your patches before posting them. This is *not* a race. Looking at your patch(es), there seem to be some language difficulties. The term position dangerous does not mean there is any inherent danger concerning the tile, or that a foreign unit or city is there. It simply means it is not a good *final* resting place at the end of a turn (or after a series of turns). The term began with the trireme code. Perhaps not a good term, but I didn't choose it. I found no need for unsafe positions. But then, I didn't look very hard, as I started from scratch, not from your patch, and compared the code in S2_0, S2_1, and S2_2. As to the comments in the previous posting, I rest my case. I tested this patch with more than 1 turn. I also tested it with waypoints, and with nearly around the world, single goto, 2 turn stealth bomber paths requiring map scrolling. All were bugs reported, now fixed. (I did not test helicopters. Perhaps that should be another patch on another day, assuming somebody reports a problem after my commit, and gives a really good test case) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39852) BUG: path finding incorrect air destination calculations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39852 Well, I ignore what you can write against me... Look at this savegame, and say me that this stealth fighter can move to P1 and not go to dangerous positions. airgoto.sav.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
