Re: [Freeciv-Dev] Development tasks

[David Lowe]

On 7 Jun, 2011, at 9:32 AM, Marko Lindqvist wrote:

> Qt-client development
> 
> Again, someone should take active role in Qt-client development if we
> want to see it forward. It was my original intend when I started that
> client that development should be later given to someone else, but as
> plan B I could slowly develop it myself. With the new things coming
> up, I really don't have time to execute that plan B. Qt-client is on
> hold until someone starts to work with it again.

Until somebody better comes along, i can at least at least keep this 
ball rolling.  Caveat: i've only worked through the TrollTech tutorials last 
semester while learning C++, so i'm far from being an expert.  Since i've never 
done anything this big before, i could benefit if somebody with "the big 
picture" gave a breakdown of the tasks.

Sent from my MacBookPro

You see, without that little doohicky, the Universe stops.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #17990] can see inside of lost city

[Jacob Nevins]

Follow-up Comment #16, bug #17990 (project freeciv):

New patch works just as well for me (my case didn't involve shared vision).

(NB, it doesn't apply cleanly to trunk, but it's trivial to fix up.)

___

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 #17990] can see inside of lost city

[Marko Lindqvist]

Update of bug #17990 (project freeciv):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #15:

- Take those having shared vision pact with city giver in to account

(file #13135)
___

Additional Item Attachment:

File name: InfoToCityLoser_17990-2.diff   Size:0 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 #2688] Insert linebreaks to long happiness effect provider lists in happiness tab

[Jacob Nevins]

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

In bug #16471 cazfi asks:
> I haven't checked [syntron's linebreak patch -- file #11988], 
> but does it insert linebreak at exactly 80 characters even if 
> that's in the middle of a word?
It calls astr_break_lines(), which calls fc_break_lines(), which tries to
break the lines in a good place.

___

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 #2679] Chuvash nation

[J.M. Maalderink]

Update of patch #2679 (project freeciv):

  Status:  Ready For Test => Done   
 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 #18007] 1: in city_owner() [city.c::1045]: assertion 'NULL != pcity->owner' failed.

[Marko Lindqvist]

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

> I'm guessing that this is one of those things that doesn't
> survive a save/load? 

Or client in original game had somehow gotten out of sync about worked tiles.
Now save/load would restore (correct) server view, and it's also told to
client.

Hmm.. for some reason I assumed we are talking about client side assert
failure here, but comments mention possible server memory corruption. Can you
clarify which side this is (assert is from common code, so can't tell from it
alone)?

___

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 #17990] can see inside of lost city

[Jacob Nevins]

Follow-up Comment #14, bug #17990 (project freeciv):

Units problem raised separately as bug #18194.

___

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 #18194] Client has out-of-date info about units transferred when city lost

[Jacob Nevins]

URL:
  

 Summary: Client has out-of-date info about units transferred
when city lost
 Project: Freeciv
Submitted by: jtn
Submitted on: Tue Jun  7 23:07:41 2011
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

Split out from bug #17990:

After losing a city by means such as civil war, a client can continue to
think that it owns units in those cities, even though this makes no sense.
Looks like the necessary unit removal packets aren't getting to the client
when the units disappear into the hostile city.

I've only tried reproducing this on trunk, but that's because the civil_war()
command makes it easy there. Don't know if S2_3 has the same problem.

Steps to reproduce (adapted from bug 17990 comment 6
:
* Trunk r19694.
* Start server with savegame canadians-T0330-Y01905-manual.sav.bz2 (file
#12846).
* Connect one client and take player 'jtn' (Canadian).
* Also connect another client as a global observer (user 'observer').
* Start game and run server command '/lua
print(civil_war(find.player(0),100))' (force civil war on Canadians, creating
the Iroquois).

Results:

'jtn' still sees the rebel cities of Winnipeg and Siem Pang, due to having
loyal units in vision range. Clicking on Winnipeg brings up a list of
supposedly-Canadian units; clicking on Siem Pang selects the single "Canadian"
Alpine Troops. But of course those units have actually defected to the
Iroquois (as the global observer can see), and jtn attempting to do anything
with them fails.

However, not all visible rebel cities are affected by this. Toronto is still
visible and contains units, but the client doesn't seem to think there are any
Canadian units in there.




___

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 #17860] S2_3 open city taken by enemy crashes the client

[Marko Lindqvist]

Follow-up Comment #4, bug #17860 (project freeciv):

Certainly bug #17990 at least affects this bug. There might be separate bug,
but it wouldn't appear like it does now without bug #17990.
For one, that backtrace would be different if results from some "if
(city_owner(pcity) == client_player())" -checks were different.

I think it's a bug if city dialog is updated at all after city has been lost.
But then again, maybe it's not when fix to bug #17990 informs also client that
city has been lost.

___

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 #18007] 1: in city_owner() [city.c::1045]: assertion 'NULL != pcity->owner' failed.

[Jacob Nevins]

Follow-up Comment #4, bug #18007 (project freeciv):

> Possibly related: there are two special tiles that are 
> unworkable to me and are marked as 'occupied' by somebody else, 
> and nobody else is there... The tiles in question are (2, 21) 
> and (2, 24) - both near cities that i've recently captured [but 
> not this turn].
I can't reproduce this observation from either savefile, either with
2.3.0-beta4 or with latest S2_3. The cities of yours that I think you mean
(Kaposvár and Eger) are actually working those tiles. I'm guessing that this
is one of those things that doesn't survive a save/load?

(I haven't tried reproducing the assertion failure from the savegames.)

___

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 #17990] can see inside of lost city

[Marko Lindqvist]

Update of bug #17990 (project freeciv):

  Status:  Ready For Test => In Progress

___

Follow-up Comment #13:

Yes, there certainly is more than one bug in play. At least for anything
units related you should open new ticket (even if those units are transferred
to new owner as part of city transfer).

When writing current patch I thought that I was smarter than previous time by
sending city info to previous owner only. Now I realized why it used to be
sent to all players in S2_2. Previous owner is not necessarily only one losing
city from sight. One has to consider shared vision also.

___

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 #18005] in dbv_isset() [bitvector.c::120]: assertion 'pdbv->vec != ((void *)0)' failed.

[Jacob Nevins]

Follow-up Comment #12, bug #18005 (project freeciv):

I've confirmed I can still reproduce the asserts per comment #5 with the
latest trunk (r19694), and that the patch makes them go away. Hurrah.

___

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 #17990] can see inside of lost city

[Jacob Nevins]

Follow-up Comment #12, bug #17990 (project freeciv):

Fix looks good, but there is another problem with out-of-date info on the
client (may be a different bug). Details:

I can still reproduce the symptoms with the latest trunk (r19694) and the
procedure in comment #6. But applying the patch in file #13128, jtn's view of
Quebec is now correct. So that's good. (We can hope that this might also fix
bug #17860, although I don't have a strong chain of reasoning for that hope.)

(The game_remove_unit() messages still appear, however, suggesting that bug
#13701 is not related. For completeness, the bug #18005 treatments respond to
the patch in that bug and are unaffected by this one, as expected.

Now to the new problem I've noticed: regardless of whether this patch is
applied, jtn's client still thinks he can control units in some rebellious
cities which he can still see -- notably Winnipeg and Siem Pang. Clicking on
those cities brings up lists of supposedly-Canadian units, although of course
since there is no alliance, they are actually Iroquois units now, as the
global observer can see; and trying to get them to do anything doesn't work.
However, this only happens for some cities; Toronto, which jtn can also still
see, doesn't behave like this.
(This problem could have always been there; I don't think I played with this
before.)

___

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 #17990] can see inside of lost city

[Jacob Nevins]

Follow-up Comment #11, bug #17990 (project freeciv):

> Funny thing is that I remember fixing exactly this several years 
> ago, but there's no trace of my fix any more. Someone has 
> "optimized" out what he considered redundant city update?
Looks like this was removed as part of the fix for bug #17238. I haven't
thought whether knowing that influences what the correct patch should be.

___

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 #17990] can see inside of lost city

[Marko Lindqvist]

Update of bug #17990 (project freeciv):

  Status:   Confirmed => Ready For Test 


___

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 #2687] Chickasaw nation

[J.M. Maalderink]

Update of patch #2687 (project freeciv):

  Status:None => In Progress

___

Follow-up Comment #1:

We've got quite a lot of North American Native nations now; maybe it's a good
idea to make an updated version of the North American map to include all of
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 #18182] Adjective of Botswana

[J.M. Maalderink]

Update of bug #18182 (project freeciv):

  Status: In Progress => Ready For Test 

___

Follow-up Comment #4:

and the Bashoto and Lesothoans

I'm not really sure how Bantustan symbolism is regarded nowadays. For the
Tswana, Venda, Zulu and Xhosa nations there wasn't really an alternative, but
since Lesotho previously used a flag different from its current one I guess
it's safer to use one of those for the Sotho nation
(http://commons.wikimedia.org/wiki/File:Flag_of_Lesotho_%281966%29.svg by
Zachary Harden). 

(file #13132, file #13133, file #13134)
___

Additional Item Attachment:

File name: lesothoan.ruleset  Size:1 KB
File name: lesotho_old.svgSize:7 KB
File name: sotho.ruleset  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 #18182] Adjective of Botswana

[J.M. Maalderink]

Update of bug #18182 (project freeciv):

  Status:None => In Progress

___

Follow-up Comment #3:

The Batswana and Botswanans

(file #13129, file #13130, file #13131)
___

Additional Item Attachment:

File name: tswana.ruleset Size:1 KB
File name: bophuthatswana.svg Size:21 KB
File name: botswanan.ruleset  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 #17748] Adv/ai diplomacy slot allocation for new players midgame

[Marko Lindqvist]

Update of bug #17748 (project freeciv):

  Status:None => Invalid
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

adv_data_init() allocation is actually for MAX_NUM_PLAYER_SLOTS slots, not
for current number of players as it first seemed.

Not wasting so much memory when there is only several players in game would
be nice, but I'm closing this ticket as invalid.

___

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 #18005] in dbv_isset() [bitvector.c::120]: assertion 'pdbv->vec != ((void *)0)' failed.

[Marko Lindqvist]

Update of bug #18005 (project freeciv):

Category:None => client 
  Status:None => Ready For Test 
 Planned Release:   2.3.0 => 2.3.0, 2.4.0   

___

Follow-up Comment #11:

Unnecessary memory allocation now in its own ticket, bug #18192.


___

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 #18192] Client allocates unnecessarily memory for tile knowledge maps

[Marko Lindqvist]

URL:
  

 Summary: Client allocates unnecessarily memory for tile
knowledge maps
 Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 07 Jun 2011 09:54:51 PM EEST
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 

___

Details:

>From bug #18005:

client_player_maps_reset() allocates tile knowledge map for all players.
Client should ever need only map of the player using 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] [bug #18005] in dbv_isset() [bitvector.c::120]: assertion 'pdbv->vec != ((void *)0)' failed.

[Marko Lindqvist]

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

Can you test if the patch I provided in comment #7 fixes the assert problem?
It's the more important one, client using a bit more memory than it would
actually need is less urgent.

___

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] Development tasks

[Marko Lindqvist]

 I wonder if there is people lurking on this mailing list wanting to
start contributing to freeciv, but don't really know what to work on.
We do have some areas where we really would have use for some help. As
you can see, we basically would want someone taking active role with
each client.


 gtk3 migration.

 Yesterday I copied gtk2-client code as base to start gtk3-client
development. gtk3-client is really important thing to do so we will
have at least one well maintained client also in the future when gtk2
libraries are no longer available by default, or maybe not at all. But
all of the currently active contributors seem to lack either time or
other resources to take really active role in this work. I'd like to
see someone taking main responsibility for gtk3 migration. More
information about our plans are in https://gna.org/task/?7334 and
https://gna.org/patch/?2689
 I'll add gtk3-client category to task and bug trackers tonight.


 SDL-client maintainership

 If we want to keep SDL-client in well maintained state, we really
need someone taking active role with it. At the moment biggest single
issue is https://gna.org/bugs/?15804 If that is not fixed soon, we
have quite useless sdl-client in 2.3 series already.


 Qt-client development

 Again, someone should take active role in Qt-client development if we
want to see it forward. It was my original intend when I started that
client that development should be later given to someone else, but as
plan B I could slowly develop it myself. With the new things coming
up, I really don't have time to execute that plan B. Qt-client is on
hold until someone starts to work with it again.



  -ML

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

[Freeciv-Dev] [bug #17962] Inability to generate huge maps

[Marko Lindqvist]

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

...or network (connection between server and client) buffers overflowing with
such a massive amount of data. That could happen if for some reason server is
sending data faster than client accepts. Server should be as fast in Windows
as in Linux, but Windows gtk is definitely slower.

___

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 #17962] Inability to generate huge maps

[Marko Lindqvist]

Follow-up Comment #9, bug #17962 (project freeciv):

What kind of hardware you have? I just wonder if this could be simply problem
of map generation taking so long that connection between client and server
timeouts? Or server running out of memory for such a massive map?

___

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 #17816] 1: City size 4, citizen count 5 for Nassau

[Marko Lindqvist]

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

Ok, it's related to that map_clear_borders().

When city shrinks (due to enemy attack in this case) border is temporarily
removed from tile that *neighboring* city is working on. In
map_claim_ownership_full() workers of that city are frozen with
city_map_update_tile_frozen() and there's no thaw for that city before all the
cities are sent with sync_cities()

___

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 #17816] 1: City size 4, citizen count 5 for Nassau

[Marko Lindqvist]

Follow-up Comment #4, bug #17816 (project freeciv):

Turns out to be rather complicated one to track down.

Anyway, there's suspicious code in city_reduce_size() that might be related
(or bug of its own):

  map_clear_border(pcity->tile);
  city_size_add(pcity, -pop_loss);
  map_claim_border(pcity->tile, pcity->owner);

 If I'm right:
 map_clear_border() can cause all the workers of the city to leave fields!
They are returned to some fields with auto_arrange_workers() later, but all
the worker arrangements player has done are lost.


___

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 #17816] 1: City size 4, citizen count 5 for Nassau

[Marko Lindqvist]

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

Findings so far:

- City size has not recently changed, so problem is in increasing citizen
count when city does not grow.
- Last time information of city was sent without problems, it had just 4
workers
- City has 4 workers and one elvis. Note that elvis is DEFAULT_SPECIALIST
that gets added in many places in code when city size is assumed to grow or
worker is taken off the field.
- City radius has not changed, so problem cannot be in how workers from that
way lost territory are turned to elvises


* City is in worker update queue: it may has just turned worker to elvis, but
feelings calculation sanity has not yet been restored (in queue thaw)

This last point means it should be quite straightforward to check where the
freeze begins and why there is no thaw once I get backtrace.

___

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 #18191] transfer_city() callers are not prepared for city destruction

[Marko Lindqvist]

URL:
  

 Summary: transfer_city() callers are not prepared for city
destruction
 Project: Freeciv
Submitted by: cazfi
Submitted on: Tue 07 Jun 2011 11:59:47 AM EEST
Category: general
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: 
 Discussion Lock: Any
Operating System: None
 Planned Release: 2.3.1, 2.4.0

___

Details:

transfer_city() itself consider the possibility that scripting causes city to
be destroyed in the process. Callers on the other hand happily use old
pcity-pointer after call to transfer_city().




___

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 #17990] can see inside of lost city

[Marko Lindqvist]

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

Untested fix attached

Since S2_2 the final city update sent to everyone seeing the city has been
moved later. In S2_2 it's before player losing the city loses vision to the
tile, now it's after.

(file #13128)
___

Additional Item Attachment:

File name: InfoToCityLoser_17990.diff Size:0 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 #17990] can see inside of lost city

[Marko Lindqvist]

Follow-up Comment #9, bug #17990 (project freeciv):

> the server simply isn't sending a city update to the client to
> reflect the change in ownership, as I suspected; I'm guessing
> that this might be because at that point the player can't see
> the city, having lost it and nearby units.

Funny thing is that I remember fixing exactly this several years ago, but
there's no trace of my fix any more. Someone has "optimized" out what he
considered redundant city update?

___

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 #2684] New Spanish nation

[Andrzej M. Gorzym]

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

Ok, it seems that proposition of this nation is a little bit exaggerated. Can
close the topic...

___

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 #2698] Update filename references in README

[Marko Lindqvist]

Update of patch #2698 (project freeciv):

  Status:None => Ready For Test 
 Assigned to:None => cazfi  
 Planned Release: => 2.3.0, 2.4.0   

___

Follow-up Comment #1:

References to source file civserver.c? That one remains, and could be used in
example anyway.

___

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 #2697] Update filename references in README.graphics

[Marko Lindqvist]

Update of patch #2697 (project freeciv):

Category:None => docs   
  Status:None => Ready For Test 
 Assigned to:None => cazfi  
 Planned Release: => 2.3.0, 2.4.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 #2696] Update filename references in README.cma

[Marko Lindqvist]

Update of patch #2696 (project freeciv):

  Status:None => Ready For Test 
 Assigned to:None => cazfi  
 Planned Release: => 2.3.0, 2.4.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 #2695] Update filename references in README.sound

[Marko Lindqvist]

Update of patch #2695 (project freeciv):

  Status:None => Ready For Test 
 Assigned to:None => cazfi  
 Planned Release: => 2.3.0, 2.4.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