[Freeciv-Dev] [bug #13848] [Patch] More detailed coding style guidelines

2009-07-01 Thread Madeline Book

URL:
  

 Summary: [Patch] More detailed coding style guidelines
 Project: Freeciv
Submitted by: mbook
Submitted on: Thursday 07/02/2009 at 02:33
Category: docs
Severity: 4 - Important
Priority: 5 - Normal
  Status: None
 Assigned to: mbook
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

As promised I expanded the coding style guidelines
with more specific rules, examples, and general
suggestions. I also made the guide itself follow
its own formatting rules.

I would please ask that everyone read the new guide
and comment if something is not acceptable or should
be added.

When this patch is applied to S2_1 and trunk, I will
also update the wiki page at:
http://freeciv.wikia.com/wiki/Coding_Style



新しい法律が発表されます。



___

File Attachments:


---
Date: Thursday 07/02/2009 at 02:33  Name: more_style.diff  Size: 18kB   By:
mbook



___

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 #13847] Build of multiple clients fails when one of them is ggz enabled gtk

2009-07-01 Thread Marko Lindqvist

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

Fix

(file #6109)
___

Additional Item Attachment:

File name: EmbedGgzMultiClient.diff   Size:11 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


Re: [Freeciv-Dev] how to use git locally for freeciv

2009-07-01 Thread Madeline Book
On 01/07/2009, Matthias Pfafferodt  wrote:
>
> You don't need to. As I said the 3 GB size is not a problem. I think I will
> also get warclient and longturn to compare ...

The 3 GB is just silly. The entire history of the trunk and S2_1
branches when cloned from freeciv-svn-mirror are only 269M.



どうしてあんまり太っている。

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


[Freeciv-Dev] [bug #13846] recursion checking for the read command

2009-07-01 Thread Madeline Book

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

Please no static variables. Use a context argument
and a wrapper/recursive function pair. Ask if you
need an example.



なんじゃそりゃ。

___

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


Re: [Freeciv-Dev] settings rework

2009-07-01 Thread Madeline Book
On 01/07/2009, Matthias Pfafferodt  wrote:
>
> I did rename op_* to pset_* as it matches the purpose of the variable: a
> pointer to a setting struct

Do this for variable names whose type is 'struct setting *' or 'const
struct setting *' only, not function names.

>> > How many freeciv versions are out there? I knew of freeciv (the
>> > original), warclient and longturn.
>>
>> Those are the 3 that are being "actively" developed. My
>> longterm goal is to merge them all into one project.
>
> ... and also a download of the longturn svn ...
>
> Do you can say something more about this plan?

More details would be here:
http://freeciv.wikia.com/wiki/User:Mbook

> I read that your first priority  is the editor for freeciv 2.2. What are
> the most important points to merge into freeciv?

They are listed on the page above, but really only users of
those programs would know this...

> Tips how to do it?

Ask people playing on warclient/longturn servers about what
warclient/longturn features they absolutely cannot live without,
then re-implement those features in 2.1 and trunk, usually by
copying and adapting (rewriting) code from their repositories.



書き直す罰ゲーム。

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


[Freeciv-Dev] [bug #13846] recursion checking for the read command

2009-07-01 Thread Marko Lindqvist

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

Easy, but acceptable, solution would be to add max recursion level. Nobody
needs recursion deeper than 5 (so make max 10 to be safe :-) levels and
exceeding it may mean infinite recursion.

___

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 #13847] Build of multiple clients fails when one of them is ggz enabled gtk

2009-07-01 Thread Marko Lindqvist

URL:
  

 Summary: Build of multiple clients fails when one of them is
ggz enabled gtk
 Project: Freeciv
Submitted by: cazfi
Submitted on: Thursday 07/02/2009 at 01:21
Category: client
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

Common client code compiles in to different library depending on if ggz is
enabled. If multiple clients are built, and one of them is ggz enabled (gtk),
those clients that cannot support ggz (all but gtk) fail to build.




___

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


Re: [Freeciv-Dev] settings rework

2009-07-01 Thread Madeline Book
On 01/07/2009, Matthias Pfafferodt  wrote:
>> Those are the 3 that are being "actively" developed. My
>> longterm goal is to merge them all into one project.
>
> Looking through the patches of longturn and warclient I found the
> patch 'Setting to control distance of traderoutes.' (longturn 20090623).
> This
> is something I also wanted to implement for the standard freeciv ...
>
> What are the rules to merge patches from warclient or longturn into the main
> freeciv?

You submit them like other feature/bugfix patches, because
they are usually implemented in a not very clean manner and
need to be checked.



キタナイ!

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


[Freeciv-Dev] [bug #13846] recursion checking for the read command

2009-07-01 Thread Marko Lindqvist

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

Just infinite recursion should be prohibited, not any read inside other
read.
That is, original file should not read itself, nor file that reads the
original, nor file that reads file that read original... but otherwise read
should be allowed.

___

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 #13810] [patch] use unions to save the game settings

2009-07-01 Thread Madeline Book

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

> _(pset_short_help(i))

Why not put the _() in setting_short_help() and write
in the comment header that it returns the translated
version? This goes for all such dupicated expressions.

Why do you use the setting number as first argument
to almost every setting function? The only function
that takes a setting id should be setting_by_number().

> for (i = 0; i < SETTINGS_NUM; i++) {

Use an iteration macro, either as the for loop or
using the generic iterator interface in utility/
iterator.h. Iterate on 'pset' which is a 'struct
setting *'.



なんだかむかつく。

___

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 #13846] recursion checking for the read command

2009-07-01 Thread Matthias Pfafferodt

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

add missing changes to stdinhand.h

(file #6108)
___

Additional Item Attachment:

File name: 0001-recursion-checking-for-the-read-command.patch Size:7 KB


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #13846] recursion checking for the read command

2009-07-01 Thread Matthias Pfafferodt

URL:
  

 Summary: recursion checking for the read command
 Project: Freeciv
Submitted by: syntron
Submitted on: Mittwoch 01.07.2009 um 21:42
Category: general
Severity: 2 - Minor
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

see summery



___

File Attachments:


---
Date: Mittwoch 01.07.2009 um 21:42  Name:
0001-recursion-checking-for-the-read-command.patch  Size: 6kB   By: syntron



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


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


[Freeciv-Dev] [bug #13810] [patch] use unions to save the game settings

2009-07-01 Thread Madeline Book

Follow-up Comment #8, bug #13810 (project freeciv):

I meant "pset" only for the variable names; functions
structs, etc. should have "setting". The variable name
should usually give some hint as to what it stands for.
So "cmd", when the type is "struct setting *", would
not be a good variable name (someone would think it
was a "struct command").

Also, do not do this

> pset_sval_validate(cmd)(arg, caller, &reject_message)

Just make the wrapper like

  setting_string_validate(pset, arg, ...)

and have it call the validate function if it exists,
i.e., if the function pointer is not NULL it returns
the return value of the call, otherwise it returns TRUE.



注意して読みなさい。

___

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 #13845] [Patch] Help mentions if unit has no "TerrainDefense" flag

2009-07-01 Thread Marko Lindqvist

URL:
  

 Summary: [Patch] Help mentions if unit has no
"TerrainDefense" flag
 Project: Freeciv
Submitted by: cazfi
Submitted on: Thursday 07/02/2009 at 00:23
Category: client
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

$subject




___

File Attachments:


---
Date: Thursday 07/02/2009 at 00:23  Name: UCFTerrDefHalp.diff  Size: 660B  
By: cazfi



___

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 #13753] [Patch] TerrainDefense unit class flag

2009-07-01 Thread Marko Lindqvist

Update of bug #13753 (project freeciv):

  Status:None => 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


Re: [Freeciv-Dev] settings rework

2009-07-01 Thread Matthias Pfafferodt
> Those are the 3 that are being "actively" developed. My
> longterm goal is to merge them all into one project.

Looking through the patches of longturn and warclient I found the 
patch 'Setting to control distance of traderoutes.' (longturn 20090623). This 
is something I also wanted to implement for the standard freeciv ...

What are the rules to merge patches from warclient or longturn into the main 
freeciv?

Matthias
-- 
Matthias Pfafferodt - http://www.mapfa.de
Matthias.Pfafferodt  mapfa.de

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


[Freeciv-Dev] [bug #13707] [Patch] Free memory allocated by init_nls()

2009-07-01 Thread Marko Lindqvist

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

S2_1 version

(file #6105)
___

Additional Item Attachment:

File name: NlsMemLeakFix_13707-S2_1.diff  Size: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 #13684] [Patch] AI: Check fuel, not AIR_MOVING, when determining type simpliness

2009-07-01 Thread Marko Lindqvist

Update of bug #13684 (project freeciv):

  Status:None => 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 #13810] [patch] use unions to save the game settings

2009-07-01 Thread Matthias Pfafferodt

Follow-up Comment #7, bug #13810 (project freeciv):

version 4; changes:

- rename op_* to pset_* (pset = pointer to struct setting)

(file #6104)
___

Additional Item Attachment:

File name: version4-gna13810.patch.diff   Size:41 KB


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Gna!
  http://gna.org/


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


Re: [Freeciv-Dev] settings rework

2009-07-01 Thread Matthias Pfafferodt
> The thing is, using just "s" as the variable name might conflict
> with string variables, and "ss" is not much better (but probably
> as good as "op", if some other pointer-to-object variables do
> not use it already). Another possibility is "psetting" (like there
> is "pcity", "punit", etc.), though it is quite long. We can combine
> the best of both worlds and get "pset", which is short, unique
> (as far as I know) and reminds the programmer what the
> variable is (once they have seen it with its full type of 'struct
> setting *').

I did rename op_* to pset_* as it matches the purpose of the variable: a 
pointer to a setting struct

[...]

> Yes. The convention of appending "_s" to the struct name is not
> used in freeciv, so there is no reason to keep it here in this case
> (there are some bits of code that awkwardly use "setting" as a
> variable name which should probably be fixed, altough using
> "setting" as both the struct label and a variable name is not a
> syntax error).

This should even less a problem as the struct settings is only define within 
settings.c

>
> >> > 7. new option
> >> >   - skill  skill level of new AI players
> >>
> >> Fine, but in its own ticket please (each new feature should
> >> have its own patch).
> >
> > yes; each list point should be (at least) one ticket; if I get how to
> > plan my
> > work it will be several patches with each resulting in a working freeciv
> > version ...
>
> Sorry to keep reminding you about basic things you probably already
> know well; I do it also for anybody reading these discussions in the
> future. ;)

It is good to read it from somebody else. So I know it is the right way to do

>
> >> > 8. new command
> >> >   - default (set default values)
> >>
> >> A command to do this has already existed a long time in
> >> warclient; it is called /reset and I think this is a slightly better
> >> name than /default (for example in the future it could take
> >> parameters so you could "/reset settings", "/reset map",
> >> "/reset teams" etc.).
> >
> > OK; I will look into warclient.
>
> There are instructions on how to download and build it here:
> http://freeciv.wikia.com/wiki/Warclient

I do a download of the warclient svn at the moment ...

>
> > How many freeciv versions are out there? I knew of freeciv (the
> > original), warclient and longturn.
>
> Those are the 3 that are being "actively" developed. My
> longterm goal is to merge them all into one project.

... and also a download of the longturn svn ...

Do you can say something more about this plan? I read that your first priority 
is the editor for freeciv 2.2. What are the most important points to merge 
into freeciv? Tips how to do it?

Matthias

>
> >> > 9. special fields within the ruleset
> >> >   - game.default = [0/1] if all options should be set to the default
> >> > values - game.showchanged = [0/1] if changed values should be listed
> >>
> >> Is there a reason why you would want to disallow users from
> >> using the '/show changed' command?
> >
> > The idea is to (1) reset all settings before loading the values from the
> > ruleset and (2) show the settings changed by the ruleset. This would be
> > in addition to the available commands. The function to load the ruleset
> > file would evaluate this settings and act accordingly.
>
> I don't think it makes sense for the ruleset to reset all settings when it
> is loaded, since there are a lot of settings that really only affect the
> internal workings of the server or user interaction, rather than the game
> itself (for example timeout, savename, scorelog, etc.). Well, since
> over time a lot of very different things have been made "settings" this
> is hard to say definitively.
>
> So I suppose 'game.default' is alright (maybe call it
> 'game.reset_settings'), but the other flag should just be the default
> behavior: if some settings are changed when the ruleset is loaded, a
> message about it should be printed on the console and sent to all
> connections so that at least everyone knows what is going on.
>
>
> 
> 一緒にリセットしませんか。



-- 
Matthias Pfafferodt - http://www.mapfa.de
Matthias.Pfafferodt  mapfa.de

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


Re: [Freeciv-Dev] how to use git locally for freeciv

2009-07-01 Thread Matthias Pfafferodt
and here is one copy for the list ..

Am Wednesday 01 July 2009 01:48:20 schrieben Sie:
> On 30/06/2009, Matthias Pfafferodt  wrote:
> > Am Tuesday 30 June 2009 05:06:02 schrieben Sie:
> >> On 29/06/2009, Madeline Book  wrote:
> >> > I just made a git repository on gitorious mirroring the
> >> > trunk branch in gna svn. Try it out:
> >> >
> >> > $ git clone
> >> > git://gitorious.org/freeciv-svn-mirror/freeciv-svn-mirror.git
> >
> > I tried - but I never got to the point there I get the entire repo ;-)
> >
> > matth...@mattsys:/home/matthias/git/test> git clone
> > git://gitorious.org/freeciv-svn-mirror/freeciv-svn-mirror.git
> > Initialized empty Git repository
> > in /home/matthias/git/test/freeciv-svn-mirror/.git/
> > remote: Counting objects: 113273, done.
> > remote: Compressing objects: 100% (18758/18758), done.
> > fatal: The remote end hung up unexpectedly.16 MiB | 19 KiB/s
> > fatal: early EOF
> > fatal: index-pack failed
> >
> > Is it possible to 'restart' the clone process?
>
> Hmm I hope I have not exceeded some size/bandwidth limit for
> the gitorious free service; I did not find any such limit in perusing
> their site though.
>
> Unfortunately when I did a test clone last night it succeeded in
> one go, so I do not know if it will restart from the beginning if
> you just reissue the command. In most cases like this I think
> git is smart enough to pick up where it left off.

One minute ago I started todays first try ;-)

>
> > Will this git mirror be up-to-date?
>
> I have to keep it up to date manually by pushing commits from
> my repository (which has to also manually "pull" commits from the
> main svn repository on gna), so it may be up to a few days behind
> if I do not work on freeciv some days.
>
> I guess I could just make a cron script to do that. ;)

You don't need to. As I said the 3 GB size is not a problem. I think I will 
also get warclient and longturn to compare ...

Matthias

>
>
> 
> それは我々の任務だ。



-- 
Matthias Pfafferodt - http://www.mapfa.de
Matthias.Pfafferodt  mapfa.de

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


[Freeciv-Dev] [bug #13750] [Patch] Configure time fix for ggz enabled gtk client

2009-07-01 Thread Marko Lindqvist

Update of bug #13750 (project freeciv):

  Status:None => 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 #13843] [Patch] Build base menu

2009-07-01 Thread Marko Lindqvist

URL:
  

 Summary: [Patch] Build base menu
 Project: Freeciv
Submitted by: cazfi
Submitted on: Wednesday 07/01/2009 at 20:11
Category: client-gtk-2.0
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

This patch adds "Build Base" submenu with all buildable base types under
Orders menu of gtk client.

This far only one base with gui type "Fortress" and one with gui type
"Airbase" has been selectable for building at any one time. This limitation
is not as bad as it first appears. This set of two base types can be
different for different units, terrain types, technological level...



___

File Attachments:


---
Date: Wednesday 07/01/2009 at 20:11  Name: BaseMenu.diff  Size: 4kB   By:
cazfi



___

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 #13842] [Patch] Base flag "NoAggressive" works with units other than land moving

2009-07-01 Thread Marko Lindqvist

URL:
  

 Summary: [Patch] Base flag "NoAggressive" works with units
other than land moving
 Project: Freeciv
Submitted by: cazfi
Submitted on: Wednesday 07/01/2009 at 19:54
Category: general
Severity: 3 - Normal
Priority: 1 - Later
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

Base flag "NoAggressive" affects only those units that are native to base
*and* are land moving. Any native unit should be affected. Fix attached.



___

File Attachments:


---
Date: Wednesday 07/01/2009 at 19:54  Name: GenMovNoAggrBase.diff  Size: 587B 
 By: cazfi



___

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 #13841] [Patch] Worklist clean up

2009-07-01 Thread Marko Lindqvist

Update of bug #13841 (project freeciv):

 Assigned to:None => cazfi  


___

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 #13841] [Patch] Worklist clean up

2009-07-01 Thread pepeto

URL:
  

 Summary: [Patch] Worklist clean up
 Project: Freeciv
Submitted by: pepeto
Submitted on: Wednesday 07/01/2009 at 16:20
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 
Operating System: None

___

Details:

Description:
The attached patch (against trunk/) fixes two problems linked with the client
global worklists and the option 'save_options_on_exit'.  In some cases, the
global worklists are not loaded then when the rc file is rebuilt, the
informations are lost and you have to recompute all your global worklists. 
This may occur when:
- you leave a server before the game starts.
- you have a worklist which doesn't fit the used ruleset.

Feature details:
- 'struct worklist' loses 2 fields: is_valid and name, which don't make sense
on a city worklist.
- init_worklist() is renamed worklist_init() and copy_worklist() is renamed
worklist_copy().
- A new structure exists, named 'global_worklist', which contains a worklist
or the information strings to compute a worklist after a ruleset is sent.
- The number of user worklists are no more limited to a hard-coded reference
(using genlist).
- All worklists are loaded at start. They are built at the start of running
start, and unbuilt when the game is freeing.  All worklists are saved,
notably the ones which doesn't fit the ruleset.
- universal_kind_name() and universal_type_rule_name() appeared to be
similar.  But, at many points of the code (notably the savegame module), a
function taking a 'enum universals_n' was needed.  I modified
universal_kind_name() according to this consideration.
- Note also it breaks the network compability with sending less informations
in the worklist packet.




___

File Attachments:


---
Date: Wednesday 07/01/2009 at 16:20  Name: global_worklist.diff.gz  Size:
13kB   By: pepeto



___

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