Re: [Freeciv-Dev] (PR#40300) can't compile S2_2

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

Jason Dorje Short wrote:

 It seems to me that this is a missing 
 dependency for api_gen.c however; it should depend on the toluaxx 
 program itself so if that program changes it gets regenerated.

Like this.

-jason

Index: server/scripting/Makefile.am
===
--- server/scripting/Makefile.am	(revision 14826)
+++ server/scripting/Makefile.am	(working copy)
@@ -34,5 +34,5 @@
 
 BUILT_SOURCES = api_gen.c api_gen.h
 
-api_gen.c api_gen.h: api.pkg
+api_gen.c api_gen.h: api.pkg $(TOLUA)
 	$(TOLUA) -n api -o $(srcdir)/api_gen.c -H $(srcdir)/api_gen.h $(srcdir)/api.pkg
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] (PR#40300) can't compile S2_2

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

Marko Lindqvist wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 
 
 2008/6/22 Jason Dorje Short [EMAIL PROTECTED]:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

 api_gen.c:11:19: error: tolua.h: No such file or directory

 I'm fairly sure this is after a fresh compilation.
 
  It seems that api_gen.c has not been regenerated with toluaxx. It
 might require --enable-maintainer-mode to work correctly if
 api_gen.[ch] already exist.
 
  Here is header of api_gen.c when generated with toluaxx:
 
 /*
 ** Lua binding: api
 ** Generated automatically by toluaxx-1.1.0 on Sun Jun 22 05:57:04 2008.
 */

Okay ignore that last.  It was a fresh checkout of the dependencies 
directory only; the server directory containing the stale copy of 
api_gen.c was unchanged.  It seems to me that this is a missing 
dependency for api_gen.c however; it should depend on the toluaxx 
program itself so if that program changes it gets regenerated.

/*
** Lua binding: api
** Generated automatically by tolua 5.0a on Sat Jun 21 22:56:45 2008.
*/

-jason



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


Re: [Freeciv-Dev] (PR#40300) can't compile S2_2

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

Marko Lindqvist wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 
 
 2008/6/22 Jason Dorje Short [EMAIL PROTECTED]:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

 api_gen.c:11:19: error: tolua.h: No such file or directory

 I'm fairly sure this is after a fresh compilation.
 
  It seems that api_gen.c has not been regenerated with toluaxx. It
 might require --enable-maintainer-mode to work correctly if
 api_gen.[ch] already exist.
 
  Here is header of api_gen.c when generated with toluaxx:
 
 /*
 ** Lua binding: api
 ** Generated automatically by toluaxx-1.1.0 on Sun Jun 22 05:57:04 2008.
 */

This error occurs on a fresh checkout of S2_2.  So it seems to me 
something must be wrong.

-jason



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


Re: [Freeciv-Dev] (PR#39938) paratroopers disappear

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39938 

2008/4/15 Marko Lindqvist:
 For
 S2_2 and TRUNK we should probably add new event category for unit
 deaths other than normal battle.

 Patch


 - ML

diff -Nurd -X.diff_ignore freeciv/common/events.c freeciv/common/events.c
--- freeciv/common/events.c 2008-04-06 15:19:10.0 +0300
+++ freeciv/common/events.c 2008-06-22 06:02:49.0 +0300
@@ -146,9 +146,10 @@
   GEN_EV(E_UNIT_WIN_ATT,   E_S_UNIT,   N_(Attack Succeeded)),
   GEN_EV(E_UNIT_BUY,   E_S_UNIT,   N_(Bought)),
   GEN_EV(E_UNIT_BUILT, E_S_UNIT,   N_(Built)),
-  GEN_EV(E_UNIT_LOST,  E_S_UNIT,   N_(Defender Destroyed)),
+  GEN_EV(E_UNIT_LOST_DEF,  E_S_UNIT,   N_(Defender Destroyed)),
   GEN_EV(E_UNIT_WIN,   E_S_UNIT,   N_(Defender Survived)),
   GEN_EV(E_UNIT_BECAME_VET,E_S_UNIT,   N_(Promoted to Veteran)),
+  GEN_EV(E_UNIT_LOST_MISC,  E_S_UNIT,   N_(Lost outside battle)),
   GEN_EV(E_UNIT_UPGRADED,  E_S_UNIT,   N_(Production Upgraded)),
   GEN_EV(E_UNIT_RELOCATED, E_S_UNIT,   N_(Relocated)),
   GEN_EV(E_UNIT_ORDERS,E_S_UNIT,   N_(Orders / goto 
events)),
@@ -246,7 +247,9 @@
   switch (event) {
   case E_GLOBAL_ECO:
   case E_CITY_LOST:
-  case E_UNIT_LOST:
+  case E_UNIT_LOST_DEF:  /* FIXME: Is this correct.
+  * I'd like to find now defendeseless city quickly! */
+  case E_UNIT_LOST_MISC:
   case E_UNIT_WIN:
   case E_ENEMY_DIPLOMAT_FAILED:
   case E_ENEMY_DIPLOMAT_POISON:
diff -Nurd -X.diff_ignore freeciv/common/events.h freeciv/common/events.h
--- freeciv/common/events.h 2008-04-06 15:19:10.0 +0300
+++ freeciv/common/events.h 2008-06-22 05:48:10.0 +0300
@@ -102,7 +102,7 @@
   E_UNIT_WIN_ATT,
   E_UNIT_BUY,
   E_UNIT_BUILT,
-  E_UNIT_LOST,
+  E_UNIT_LOST_DEF,
   E_UNIT_WIN,
   E_UNIT_BECAME_VET,
   E_UNIT_UPGRADED,
@@ -125,10 +125,11 @@
   E_LOG_ERROR, /* Warning messages */
   E_LOG_FATAL,
   E_TECH_GOAL, /* Changed tech goal */
+  E_UNIT_LOST_MISC, /* Non-battle unit deaths */
   /* 
* Note: If you add a new event, make sure you make a similar change
-   * to the events array in common/events.c using GEN_EV and to
-   * data/stdsounds.soundspec.
+   * to the events array in common/events.c using GEN_EV,
+   * data/stdsoundes and to server/scripting/api.pkg
*/
   E_LAST
 };
diff -Nurd -X.diff_ignore freeciv/data/stdsounds.soundspec 
freeciv/data/stdsounds.soundspec
--- freeciv/data/stdsounds.soundspec2008-02-10 11:05:27.0 +0200
+++ freeciv/data/stdsounds.soundspec2008-06-22 05:46:52.0 +0300
@@ -286,8 +286,9 @@
 ;e_unit_became_vet = 
 ;e_unit_built = 
 ;e_unit_buy = 
-;e_unit_lost = 
+;e_unit_lost_def = 
 ;e_unit_lost_att = 
+;e_unit_lost_misc = 
 ;e_unit_orders = 
 ;e_unit_relocated = 
 ;e_unit_upgraded = 
diff -Nurd -X.diff_ignore freeciv/server/citytools.c freeciv/server/citytools.c
--- freeciv/server/citytools.c  2008-06-18 17:45:27.0 +0300
+++ freeciv/server/citytools.c  2008-06-22 05:57:51.0 +0300
@@ -586,7 +586,7 @@
  nation_rule_name(nation_of_player(from_player)),
  nation_rule_name(nation_of_player(to_player)));
   if (verbose) {
-   notify_player(from_player, punit-tile, E_UNIT_LOST,
+   notify_player(from_player, punit-tile, E_UNIT_LOST_MISC,
  /* TRANS: Polish Destroyer ... German city */
  _(%s %s lost in transfer to %s %s),
  nation_adjective_for_player(from_player),
@@ -670,7 +670,7 @@
  city_name(pcity));
   if (verbose) {
notify_player(unit_owner(vunit), vunit-tile,
-E_UNIT_LOST,
+E_UNIT_LOST_MISC,
 _(%s lost along with control of %s.),
 unit_name_translation(vunit),
 city_name(pcity));
@@ -1191,7 +1191,7 @@
   }
 } adjc_iterate_end;
 if (!moved) {
-  notify_player(unit_owner(punit), NULL, E_UNIT_LOST,
+  notify_player(unit_owner(punit), NULL, E_UNIT_LOST_MISC,
   _(When %s was disbanded your %s could not 
 get out, and it was therefore lost.),
   city_name(pcity),
diff -Nurd -X.diff_ignore freeciv/server/cityturn.c freeciv/server/cityturn.c
--- freeciv/server/cityturn.c   2008-05-13 13:26:10.0 +0300
+++ freeciv/server/cityturn.c   2008-06-22 05:58:25.0 +0300
@@ -716,7 +716,7 @@
   if (unit_type(punit)-upkeep[O_FOOD]  0 
!unit_has_type_flag(punit, F_UNDISBANDABLE)) {
 
-   notify_player(city_owner(pcity), pcity-tile, E_UNIT_LOST,
+   notify_player(city_owner(pcity), pcity-tile, E_UNIT_LOST_MISC,
 _(Famine feared in %s, %s lost!), 
 city_name(pcity),
 

Re: [Freeciv-Dev] (PR#40300) can't compile S2_2

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

2008/6/22 Jason Dorje Short [EMAIL PROTECTED]:

 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

 api_gen.c:11:19: error: tolua.h: No such file or directory

 I'm fairly sure this is after a fresh compilation.

 It seems that api_gen.c has not been regenerated with toluaxx. It
might require --enable-maintainer-mode to work correctly if
api_gen.[ch] already exist.

 Here is header of api_gen.c when generated with toluaxx:

/*
** Lua binding: api
** Generated automatically by toluaxx-1.1.0 on Sun Jun 22 05:57:04 2008.
*/


 - ML



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


Re: [Freeciv-Dev] (PR#40255) [PATCH] Only draw output sprites in citymode.

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40255 

2008/6/6 Madeline Book:

 Alright, I'll check if I haven't missed something in the
 view-menu and see if some existing patches could do the job.

 I were referring to ticket #40213. There's no other patches than yours.


 - ML



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


Re: [Freeciv-Dev] (PR#40300) can't compile S2_2

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40300 

2008/6/22 Jason Dorje Short:

 It seems to me that this is a missing
 dependency for api_gen.c however; it should depend on the toluaxx
 program itself so if that program changes it gets regenerated.

 Like this.

 This will break cross-compile at least. (well, cross-compiling is not
working exactly right at the moment, but at least it is possible)

 This has been discussed several times in the past and current model
has been considered lesser evil.


 - ML



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


Re: [Freeciv-Dev] (PR#40299) fix buffer overflow in send_chat_printf

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40299 

2008/6/22 Jason Dorje Short:
 Also with utf-8 truncating things like this is not at all safe.  This
 can send incorrect utf-8 to the server which when sent back to the
 client becomes very hard to handle.  GTK will crash (yes, crash) if
 given invalid utf-8; it's supposed to be checked before it's passed in
 but I'm not sure if we do that.  If it is checked the best thing the
 client could do is discard the invalid utf-8 string.

 Actually, that truncation is not needed with any correctly working
implementation of vsnprintf(). Ending zero should be there already,
and hopefully in right place UTF-8 wise.

 But does it makes sense to send such truncated command at all. At
worst case we execute wrong variant of the command that has different
versions taking different number of parameters. At best case we are
just abbreviating something so that server still understands it.


 - ML



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


Re: [Freeciv-Dev] (PR#40299) fix buffer overflow in send_chat_printf

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40299 

Marko Lindqvist wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40299 
 
 2008/6/22 Jason Dorje Short:
 Also with utf-8 truncating things like this is not at all safe.  This
 can send incorrect utf-8 to the server which when sent back to the
 client becomes very hard to handle.  GTK will crash (yes, crash) if
 given invalid utf-8; it's supposed to be checked before it's passed in
 but I'm not sure if we do that.  If it is checked the best thing the
 client could do is discard the invalid utf-8 string.
 
  Actually, that truncation is not needed with any correctly working
 implementation of vsnprintf(). Ending zero should be there already,
 and hopefully in right place UTF-8 wise.

Yes, most (all?) implementations of snprintf should truncate.  But it 
will NOT be in the right place utf-8 wise; snprintf knows nothing about 
characters, only bytes.  If truncation happens it'll be on the 50th byte 
regardless of how many characters fit in there or if it gets truncated 
mid-character.

  But does it makes sense to send such truncated command at all. At
 worst case we execute wrong variant of the command that has different
 versions taking different number of parameters. At best case we are
 just abbreviating something so that server still understands it.

Possibly aborting and giving the user an error message is better, yes.

For *commands* truncation shouldn't be much issue anyway as utf-8 should 
generally not be used (possible exceptions being with player names or 
such).  For chat lines utf-8 would be the standard.  Chat lines are also 
limited (by packet length if nothing else) and thus some form of 
truncation or filtering (discarding too-long lines) is needed.  This may 
be done at the client end (limiting lines to 100 letters for instance, 
in GTK code) but should also be checked before such strings received 
across the network are actually used (glib has a function for checking 
UTF-8 string validity, for instance).

I don't know how much of this has been done, but having written most of 
the encoding code I believe this is probably one area where our checks 
fall short.

-jason



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


[Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

 $subject

 To be committed soon.


 - ML

diff -Nurd -X.diff_ignore freeciv/client/gui-gtk-2.0/gui_main.c 
freeciv/client/gui-gtk-2.0/gui_main.c
--- freeciv/client/gui-gtk-2.0/gui_main.c   2008-05-16 01:50:17.0 
+0300
+++ freeciv/client/gui-gtk-2.0/gui_main.c   2008-06-22 09:50:37.0 
+0300
@@ -1487,7 +1487,9 @@
   if (game.player_ptr) {
 char *text;
 
-if (game.player_ptr-is_ready) {
+if (game.player_ptr == NULL) {
+  text = _(_Ready);
+} else if (game.player_ptr-is_ready) {
   text = _(Not _ready);
 } else {
   int num_unready = 0;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

Marko Lindqvist wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 
 
  $subject
 
  To be committed soon.

if (game.player_ptr) {
  char *text;

-if (game.player_ptr-is_ready) {
+if (game.player_ptr == NULL) {
+  text = _(_Ready);
+} else if (game.player_ptr-is_ready) {
text = _(Not _ready);
  } else {
int num_unready = 0;

This patch makes no sense.

How can game.player_ptr be NULL when 3 lines above there's a check to 
see if it's non-NULL?

And why is the text Not ready when the is_ready field is set?

-jason



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


[Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Jason Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

 [EMAIL PROTECTED] - Sun Jun 22 07:01:15 2008]:
 
 Marko Lindqvist wrote:
  URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 
  
   $subject
  
   To be committed soon.
 
 if (game.player_ptr) {
   char *text;
 
 -if (game.player_ptr-is_ready) {
 +if (game.player_ptr == NULL) {
 +  text = _(_Ready);
 +} else if (game.player_ptr-is_ready) {
 text = _(Not _ready);
   } else {
 int num_unready = 0;
 
 This patch makes no sense.
 
 How can game.player_ptr be NULL when 3 lines above there's a check to 
 see if it's non-NULL?

Conclusion: whatever crash you saw must be caused by something else
(likely, the buffer overrun I just fixed).  The code here is never
encountered when the player is a global observer (the button is
desensitized and the text left untouched, as the check up above skips
over this code block).  The patch should probably be reverted as it's
unnecessarily obfuscitory.

 And why is the text Not ready when the is_ready field is set?

Having looked at the code again I see that is the way it's supposed to be.

-jason


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


Re: [Freeciv-Dev] Should we release 2.0.10?

2008-06-22 Thread Daniel Markstedt
On Sun, 22 Jun 2008 11:15:47 +0900, Jason Dorje Short [EMAIL PROTECTED]  
wrote:

 Daniel Markstedt wrote:
 On 6/19/08, Marko Lindqvist [EMAIL PROTECTED] wrote:
  Many distributions are still not released version (of the
  distribution) which uses Freeciv 2.1 (Ubuntu Dapper  Gutsy are both
  supported to 2009 and use Freeciv 2.0) My public 2.0 server seems to
  be sometimes more used than 2.1 ones. It's over year since 2.0.9 was
  released and many crasher bugs and security fixes has been since made
  to S2_0 branch.



   - ML


 I support this.

 Jason, are there any particular differences in creating a 2.0 release
 as opposed to a 2.1 one?

 2.0 should be just the same release system as 2.1.  Making a new 2.0.x
 should be rather easy.  Might be a good idea to give translators the
 opportunity to backport any new translations though (there shouldn't
 really be new strings in 2.0 but trunk or 2.1 may contain expanded
 translations).

 Honestly I'd even consider a new 1.14 release.  Some people really liked
 the 1.14 gameplay and the branch does contain some bugfixes.

 -jason


I'm preparing changelog and news for 2.0.10. Can I tag the release at any  
time?

  ~Daniel

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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


[Freeciv-Dev] (PR#40267) [editor] icons

2008-06-22 Thread Daniel Markstedt

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40267 

 [book - Wed Jun 11 21:10:32 2008]:
 
 First version of editor icons that where suggested to be
 added to svn in PR#40184 so as remove the need for binary
 patches.
 
 Most images are from tileset images already in the repository.
 
 As for the 'X', brush, pointing hand, eye, and wrench+screwdriver
 they based on various sources which may not be GPL (e.g. some
 are from tango.freedesktop.org which are CC, wherease others
 were unattributed in the first place), so I may redo them.
 
 
 --
 綺麗な絵!自分で創ったの?
 

Did you sort out the licensing of these gfx? I see it has been added to 
svn but is still lacking an accompanying .spec so I cannot see how 
attribution has been worked out.

BTW, the Japanese is incorrect here. Someone used a very odd kanji for 
the verb 'tsukuru'. :-P

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


Re: [Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

 Maybe this patch makes more sense.

 Crash was caused by adjusting player_idx, and setting bogus
player_ptr, for global observer in game_renumber_players.

 S2_1 version:
 - Fixes the bug
 - Adds sanity check for player number received in player_remove_player
 - Reverts my earlier patch

 There is no game.player_ptr or packet_remove_player in S2_2 and
TRUNK. This patch only
 - Revert my earlier patch, but uses proper accessor functions instead
of old implementation


 - ML

diff -Nurd -X.diff_ignore freeciv/client/gui-gtk-2.0/gui_main.c 
freeciv/client/gui-gtk-2.0/gui_main.c
--- freeciv/client/gui-gtk-2.0/gui_main.c   2008-06-22 10:07:27.0 
+0300
+++ freeciv/client/gui-gtk-2.0/gui_main.c   2008-06-22 11:21:52.0 
+0300
@@ -1487,9 +1487,7 @@
   if (game.player_ptr) {
 char *text;
 
-if (game.player_ptr == NULL) {
-  text = _(_Ready);
-} else if (game.player_ptr-is_ready) {
+if (game.player_ptr-is_ready) {
   text = _(Not _ready);
 } else {
   int num_unready = 0;
diff -Nurd -X.diff_ignore freeciv/client/packhand.c freeciv/client/packhand.c
--- freeciv/client/packhand.c   2008-05-16 01:50:17.0 +0300
+++ freeciv/client/packhand.c   2008-06-22 11:02:53.0 +0300
@@ -2178,6 +2178,12 @@
 **/
 void handle_player_remove(int player_id)
 {
+  if (player_id  0 || player_id = MAX_NUM_PLAYERS) {
+freelog(LOG_ERROR, Illegal player_remove packet from server (%d),
+player_id);
+return;
+  }
+
   client_remove_player(player_id);
   update_conn_list_dialog();
 }
diff -Nurd -X.diff_ignore freeciv/common/game.c freeciv/common/game.c
--- freeciv/common/game.c   2008-05-08 00:25:01.0 +0300
+++ freeciv/common/game.c   2008-06-22 11:21:01.0 +0300
@@ -534,7 +534,7 @@
 assert(city_list_size(game.players[i].cities) == 0);
   }
 
-  if(game.info.player_idx  plrno) {
+  if(game.player_ptr  game.info.player_idx  plrno) {
 game.info.player_idx--;
 game.player_ptr = game.players[game.info.player_idx];
   }
diff -Nurd -X.diff_ignore freeciv/client/gui-gtk-2.0/gui_main.c 
freeciv/client/gui-gtk-2.0/gui_main.c
--- freeciv/client/gui-gtk-2.0/gui_main.c   2008-06-22 10:07:44.0 
+0300
+++ freeciv/client/gui-gtk-2.0/gui_main.c   2008-06-22 11:24:47.0 
+0300
@@ -1559,12 +1559,10 @@
 {
   GtkTreeIter it[player_count()];
 
-  if (NULL != client.conn.playing) {
+  if (!client_has_player()) {
 char *text;
 
-if (!client_has_player()) {
-  text = _(_Ready);
-} else if (client.conn.playing-is_ready) {
+if (client_player()-is_ready) {
   text = _(Not _ready);
 } else {
   int num_unready = 0;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] (PR#40272) Meta-ticket for 2.2 release

2008-06-22 Thread Daniel Markstedt
On Fri, 13 Jun 2008 06:51:24 +0900, Marko Lindqvist [EMAIL PROTECTED]  
wrote:

 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 

 This is a pre-emptive meta-ticket for the 2.2 release. Any tickets
 which the new release should depend on should be linked here.


Thanks Marko for the initiative.


 In order to get new features faster to end-users I'd like to make
 feature releases more often (with smaller changesets)
 My suggestion:
  - 2.2 should be released as soon as Madeline's editor work is
 finished and current bugs are fixed. Other features may go in as long
 as they do not postpone release schedule. I hope to implement some of
 the most important features missing from scripting. First beta could
 come out in about two months.

IMHO another must-fix for 2.2 first beta is some kind of update to the  
default tilesets. William's new terrain rules have outdated all 2.1  
tilesets. Wooded hills provide different resources from verdant hills,  
for example, but use the same sprite and often exist in the same general  
area. If we release a beta without doing anything about this, I can  
promise it'll generate alot of negative buzz among veteran users.

For starters, I will make ugly-but-usable tweaks to the current default  
tilesets, while trying to recruit the services of our artist community.

  - We will branch S2_3 from S2_2 branch some time after editor is in.
 2.3 will contain remaining features earlier planned for S2_2 and some
 minor new ones (We really should provide IPv6 version soon. Debian and
 other distributions based on it of course have patched version of
 Freeciv with IPv6 support already)



Is it really necessary to branch 2.3 already? Can't we just work on trunk  
until the next feature freeze?


  - ML



Best,
  ~Daniel

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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


Re: [Freeciv-Dev] (PR#40272) Meta-ticket for 2.2 release

2008-06-22 Thread Daniel Markstedt

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 

On Fri, 13 Jun 2008 06:51:24 +0900, Marko Lindqvist [EMAIL PROTECTED]  
wrote:

 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 

 This is a pre-emptive meta-ticket for the 2.2 release. Any tickets
 which the new release should depend on should be linked here.


Thanks Marko for the initiative.


 In order to get new features faster to end-users I'd like to make
 feature releases more often (with smaller changesets)
 My suggestion:
  - 2.2 should be released as soon as Madeline's editor work is
 finished and current bugs are fixed. Other features may go in as long
 as they do not postpone release schedule. I hope to implement some of
 the most important features missing from scripting. First beta could
 come out in about two months.

IMHO another must-fix for 2.2 first beta is some kind of update to the  
default tilesets. William's new terrain rules have outdated all 2.1  
tilesets. Wooded hills provide different resources from verdant hills,  
for example, but use the same sprite and often exist in the same general  
area. If we release a beta without doing anything about this, I can  
promise it'll generate alot of negative buzz among veteran users.

For starters, I will make ugly-but-usable tweaks to the current default  
tilesets, while trying to recruit the services of our artist community.

  - We will branch S2_3 from S2_2 branch some time after editor is in.
 2.3 will contain remaining features earlier planned for S2_2 and some
 minor new ones (We really should provide IPv6 version soon. Debian and
 other distributions based on it of course have patched version of
 Freeciv with IPv6 support already)



Is it really necessary to branch 2.3 already? Can't we just work on trunk  
until the next feature freeze?


  - ML



Best,
  ~Daniel

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



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


Re: [Freeciv-Dev] Should we release 2.0.10?

2008-06-22 Thread Christian Prochaska
Is somebody able to fix the 2.0.9 crashes reported in #39472 and
#39582? I can still reproduce the crashes with current S2_0. Another
reported 2.0 problem is #39757, which has a patch that hasn't been
committed yet.

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


[Freeciv-Dev] (PR#39472) Bug in v2.08 2.09 - Crash

2008-06-22 Thread Christian Prochaska

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39472 

this is reported by valgrind with current S2_0 on Linux:

==10725== Invalid read of size 1
==10725==at 0x8093E09: improvement_redundant (improvement.c:317)
==10725==by 0x8093F38: improvements_update_redundant (improvement.c:592)
==10725==by 0x809432E: allot_island_improvs (improvement.c:505)
==10725==by 0x8071D7E: handle_tile_info (packhand.c:2040)
==10725==by 0x80723BF: client_handle_packet (packhand_gen.c:80)
==10725==by 0x8058588: handle_packet_input (civclient.c:389)
==10725==by 0x805CE52: input_from_server (clinet.c:350)
==10725==by 0x43C6B2E: (within /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==10725==by 0x45E364C: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45AF977: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2BCD: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2F56: g_main_loop_run (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==  Address 0x6eea8ac is not stack'd, malloc'd or (recently) free'd
==10725== 
==10725== Invalid read of size 1
==10725==at 0x8093E68: improvement_redundant (improvement.c:329)
==10725==by 0x8093F38: improvements_update_redundant (improvement.c:592)
==10725==by 0x809432E: allot_island_improvs (improvement.c:505)
==10725==by 0x8071D7E: handle_tile_info (packhand.c:2040)
==10725==by 0x80723BF: client_handle_packet (packhand_gen.c:80)
==10725==by 0x8058588: handle_packet_input (civclient.c:389)
==10725==by 0x805CE52: input_from_server (clinet.c:350)
==10725==by 0x43C6B2E: (within /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==10725==by 0x45E364C: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45AF977: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2BCD: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2F56: g_main_loop_run (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==  Address 0x6eea89b is not stack'd, malloc'd or (recently) free'd
==10725== 
==10725== Conditional jump or move depends on uninitialised value(s)
==10725==at 0x8093E6E: improvement_redundant (improvement.c:330)
==10725==by 0x8093F38: improvements_update_redundant (improvement.c:592)
==10725==by 0x809432E: allot_island_improvs (improvement.c:505)
==10725==by 0x8071D7E: handle_tile_info (packhand.c:2040)
==10725==by 0x80723BF: client_handle_packet (packhand_gen.c:80)
==10725==by 0x8058588: handle_packet_input (civclient.c:389)
==10725==by 0x805CE52: input_from_server (clinet.c:350)
==10725==by 0x43C6B2E: (within /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==10725==by 0x45E364C: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45AF977: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2BCD: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2F56: g_main_loop_run (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725== 
==10725== Conditional jump or move depends on uninitialised value(s)
==10725==at 0x8093E73: improvement_redundant (improvement.c:330)
==10725==by 0x8093F38: improvements_update_redundant (improvement.c:592)
==10725==by 0x809432E: allot_island_improvs (improvement.c:505)
==10725==by 0x8071D7E: handle_tile_info (packhand.c:2040)
==10725==by 0x80723BF: client_handle_packet (packhand_gen.c:80)
==10725==by 0x8058588: handle_packet_input (civclient.c:389)
==10725==by 0x805CE52: input_from_server (clinet.c:350)
==10725==by 0x43C6B2E: (within /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==10725==by 0x45E364C: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45AF977: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2BCD: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2F56: g_main_loop_run (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725== 
==10725== Conditional jump or move depends on uninitialised value(s)
==10725==at 0x8093E0F: improvement_redundant (improvement.c:318)
==10725==by 0x8093F38: improvements_update_redundant (improvement.c:592)
==10725==by 0x809432E: allot_island_improvs (improvement.c:505)
==10725==by 0x8071D7E: handle_tile_info (packhand.c:2040)
==10725==by 0x80723BF: client_handle_packet (packhand_gen.c:80)
==10725==by 0x8058588: handle_packet_input (civclient.c:389)
==10725==by 0x805CE52: input_from_server (clinet.c:350)
==10725==by 0x43C6B2E: (within /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==10725==by 0x45E364C: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45AF977: g_main_context_dispatch (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2BCD: (within /usr/lib/libglib-2.0.so.0.1600.3)
==10725==by 0x45B2F56: g_main_loop_run (in
/usr/lib/libglib-2.0.so.0.1600.3)
==10725== 
==10725== Conditional jump or move depends on uninitialised value(s)
==10725==at 0x8093E13: improvement_redundant (improvement.c:318)
==10725==by 

Re: [Freeciv-Dev] (PR#39982) Wonder Report does not mark obsolete Wonders

2008-06-22 Thread [EMAIL PROTECTED]

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39982 

I'd quite like to get this patch committed on S2_1 for the next 2.1.x
release. It fixes a fairly obvious bug, and I've been running with it
since 2.1.3 and haven't spotted any problems.



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


Re: [Freeciv-Dev] (PR#40272) Meta-ticket for 2.2 release

2008-06-22 Thread Per I. Mathisen

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 

On Sun, Jun 22, 2008 at 12:14 PM, Daniel Markstedt [EMAIL PROTECTED] wrote:
 IMHO another must-fix for 2.2 first beta is some kind of update to the
 default tilesets. William's new terrain rules have outdated all 2.1
 tilesets. Wooded hills provide different resources from verdant hills,
 for example, but use the same sprite and often exist in the same general
 area. If we release a beta without doing anything about this, I can
 promise it'll generate alot of negative buzz among veteran users.

 For starters, I will make ugly-but-usable tweaks to the current default
 tilesets, while trying to recruit the services of our artist community.

I would rather suggest these terrain code changes are reverted. I see
no good reason for them other than the inane we have to do it like
game XYZ. Even with new graphics they will be quite confusing.

  - Per



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


[Freeciv-Dev] (PR#40304) Cannot start civclient 2.0 from prefix directory

2008-06-22 Thread Daniel Markstedt

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40304 

S2_0 r14840:

If Freeciv is installed to a prefix defined directory (configured with  
--prefix=/foo/bar), starting civclient gives me:

1: Did not read help texts
1: Trying isotrident tileset.
0: No usable default tileset found, aborting!

It works fine if started from the source directory.

S2_1 works fine in both cases.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/



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


[Freeciv-Dev] (PR#40305) G++ not tested in autogen.sh

2008-06-22 Thread Joan Creus

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40305 

I can't build version 2.2, because g++ is not installed. The error message
is:

../../../../bootstrap/depcomp: line 470: exec: g++: not found
make[5]: *** [toluaxx.bind.o] Error 127

I can install g++, sure, but perhaps autogen.sh should have checked g++'s
existence before? Right now, autogen doesn't report any problems.

Joan

I cant build version 2.2, because g++ is not installed. The error message is:../../../../bootstrap/depcomp: line 470: exec: g++: not foundmake[5]: *** [toluaxx.bind.o] Error 127I can install g++, sure, but perhaps autogen.sh should have checked g++s existence before? Right now, autogen doesnt report any problems.
Joan
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] (PR#40272) Meta-ticket for 2.2 release

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 

2008/6/22 Per I. Mathisen:

 On Sun, Jun 22, 2008 at 12:14 PM, Daniel Markstedt [EMAIL PROTECTED] wrote:
 IMHO another must-fix for 2.2 first beta is some kind of update to the
 default tilesets. William's new terrain rules have outdated all 2.1
 tilesets. Wooded hills provide different resources from verdant hills,
 for example, but use the same sprite and often exist in the same general
 area. If we release a beta without doing anything about this, I can
 promise it'll generate alot of negative buzz among veteran users.

 For starters, I will make ugly-but-usable tweaks to the current default
 tilesets, while trying to recruit the services of our artist community.

 I would rather suggest these terrain code changes are reverted. I see
 no good reason for them other than the inane we have to do it like
 game XYZ. Even with new graphics they will be quite confusing.

 Default ruleset should have same terrains 2.1 had + second ocean
type. The second ocean type still has several display problems
(#18466)

 Reverting other terrains is one of the goals of the #40165 . There is
also some 'compatibility' changes that tweak savegame identifiers when
loading old saves for no obvious reason (except that all rulesets can
use same identifiers, I don't see how this cleanup is worth the
savegame handling trouble)


 - ML



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


Re: [Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

How do you trigger this crash?

-jason



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


Re: [Freeciv-Dev] (PR#40272) Meta-ticket for 2.2 release

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 

Per I. Mathisen wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40272 
 
 On Sun, Jun 22, 2008 at 12:14 PM, Daniel Markstedt [EMAIL PROTECTED] wrote:
 IMHO another must-fix for 2.2 first beta is some kind of update to the
 default tilesets. William's new terrain rules have outdated all 2.1
 tilesets. Wooded hills provide different resources from verdant hills,
 for example, but use the same sprite and often exist in the same general
 area. If we release a beta without doing anything about this, I can
 promise it'll generate alot of negative buzz among veteran users.

 For starters, I will make ugly-but-usable tweaks to the current default
 tilesets, while trying to recruit the services of our artist community.
 
 I would rather suggest these terrain code changes are reverted. I see
 no good reason for them other than the inane we have to do it like
 game XYZ. Even with new graphics they will be quite confusing.

Agreed on that.

-jason



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


Re: [Freeciv-Dev] (PR#39582) 2.0.9: crash at end of turn

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39582 

Christian Prochaska wrote:

 The 2.0.9 uninstaller deletes only files installed by itself, so the
 savegames should still be where they were stored (by default in the game
 directory - C:\Program Files\Freeciv-2.0.9-gtk2 or C:\Program
 Files\Freeciv-2.0.9-win32). Please look again.

That's a bug right there.  Savegames should be shared across freeciv 
installations (freeciv is generally backward-compatible and mostly 
forward-compatible in loading savegames) so only one savegame directory 
should be needed.

-jason



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


Re: [Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Marko Lindqvist

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

2008/6/22 Jason Dorje Short [EMAIL PROTECTED]:

 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

 How do you trigger this crash?

 In theory:
 1) Start New Game
 2) Observe (become global observer)
 3) Pick Nation ( /take - )

 In practice, crash has happened more consistently after:
 1) Start New Game
 2) Observe
 3) Do not Observe
 4) Observe
 5) Pick Nation

 Server is probably removing aifill-player to make space for me when
the crash happens.


 - ML



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


Re: [Freeciv-Dev] (PR#40303) [Patch] Fix Global Observer crash in connectdlg

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

Marko Lindqvist wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 
 
 2008/6/22 Jason Dorje Short [EMAIL PROTECTED]:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40303 

 How do you trigger this crash?
 
  In theory:
  1) Start New Game
  2) Observe (become global observer)
  3) Pick Nation ( /take - )
 
  In practice, crash has happened more consistently after:
  1) Start New Game
  2) Observe
  3) Do not Observe
  4) Observe
  5) Pick Nation
 
  Server is probably removing aifill-player to make space for me when
 the crash happens.

I'd suggest using valgrind to find the exact line where the error occurs 
here and to make sure the fix actually fixes and doesn't just hide the 
error.

-jason



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


[Freeciv-Dev] (PR#40267) [editor] icons

2008-06-22 Thread Madeline Book

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40267 

 [dmarks - Sun Jun 22 08:27:57 2008]:
 
 Did you sort out the licensing of these gfx? I see it has been
 added to svn but is still lacking an accompanying .spec so I
 cannot see how attribution has been worked out.

The spec file is in the latest patch in #40184 which I will
commit as soon as I can (the speed of RT permitting :/).

Unless there is some problem with the CC license or
unattributed graphics (e.g. no license public domain)?
Do all graphics have to be GPL and GPL only?

 BTW, the Japanese is incorrect here. Someone used a very odd
 kanji for the verb 'tsukuru'. :-P

I guess 創 is a little over the top and I should have stuck
with 作. ;)


--
実は正しい語法は自信なしです。まだあまり上手じゃありませんから。

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


Re: [Freeciv-Dev] (PR#40267) [editor] icons

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40267 

Madeline Book wrote:
 URL: http://bugs.freeciv.org/Ticket/Display.html?id=40267 
 
 [dmarks - Sun Jun 22 08:27:57 2008]:

 Did you sort out the licensing of these gfx? I see it has been
 added to svn but is still lacking an accompanying .spec so I
 cannot see how attribution has been worked out.
 
 The spec file is in the latest patch in #40184 which I will
 commit as soon as I can (the speed of RT permitting :/).
 
 Unless there is some problem with the CC license or
 unattributed graphics (e.g. no license public domain)?
 Do all graphics have to be GPL and GPL only?

It would be extremely convenient if everything were GPL.  Mixed licenses 
are possible but then we need to change COPYING and other files to make 
it clear.  Dual-license is fine; if you can get the original authors to 
release the graphics under multiple licenses.

Public domain files are fine to include as GPL.

-jason



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


Re: [Freeciv-Dev] (PR#39582) 2.0.9: crash at end of turn

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39582 

I can't reproduce the crash here with S2_0.  On loading the game and 
ending turn a time or two, the game ends.  What client is used to get 
the crash and what is necessary to do other than just end turn?

-jason



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


[Freeciv-Dev] (PR#39472) Bug in v2.08 2.09 - Crash

2008-06-22 Thread Jason Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39472 

map.num_continents is never actually sent to the client - the client
just deduces it from the continent numbers of each tile.  So when new
terrain is revealed, which can happen mid-turn, the num_continents can
rise (packhand.c:2039 in S2_0).  This is the same way things are handled
in trunk as well so it's likely this issue is still present.

From the backtrace on the valgrind error (--db-attach=yes):

(gdb) p pcity-tile-continent
$11 = 53
(gdb) p map.num_continents
$12 = 5

For a quick fix the attached patch will probably do (possibly for
S2_1/S2_2/trunk as well; it should certainly be harmless there).

Similar problems may easily crop up elsewhere however.  The question
here is how a tile with continent 53 gets into the system (at the client
end) while map.num_continents is still set at 5.  A closer look at the
backtrace will probably show the num_continents gets properly changed
later on in the same packet-handling sequence that causes the crash. 
I'd think the easiest and best fix by far would be to have
num_continents just sent to the client outright.  I don't know why it's
done as it is; any idea of fairness (as sending num_continents to the
client gives away global information) is misplaced as some players will
have higher continent numbers than others and will therefore gain more
global information by it - meaning the current system is unfair.

-jason

Index: common/improvement.c
===
--- common/improvement.c	(revision 14840)
+++ common/improvement.c	(working copy)
@@ -285,7 +285,7 @@
   if (pplayer) {
 equiv_list[IR_PLAYER] = pplayer-improvements;
 
-if (cont  0  pplayer-island_improv) {
+if (cont  0  cont = map.num_continents  pplayer-island_improv) {
   equiv_list[IR_ISLAND] =
   pplayer-island_improv[cont * game.num_impr_types];
 }
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] (PR#39472) Bug in v2.08 2.09 - Crash

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=39472 

A closer look at the backtrace reveals a rather severe bug in packhand.c.

   /* update continents */
   if (ptile-continent != packet-continent  ptile-continent != 0
packet-continent  0) {
 /* We're renumbering continents, somebody did a transform.
  * But we don't care about renumbering oceans since
  * num_oceans is not kept at the client. */
 map.num_continents = 0;
   }

   ptile-continent = packet-continent;

   if (ptile-continent  map.num_continents) {
 map.num_continents = ptile-continent;
 allot_island_improvs();
   }

The num_continents reset to 0 is triggered when a land tile changes 
continent (this only happens when continents are merged or split via 
land-ocean transformation).  This then triggers num_continents to be 
set below which triggers a recheck of the island improvements.  But the 
setting of num_continents is incorrect as there is no guarantee that 
THIS tile is the highest numbered continent.  Thus for a while 
map.num_continents is wrong and the bug will be triggered.  In the 
savegame of course there were a huge number of continents so the bug is 
likely triggered most of the time when two of them are unified via ocean 
transformation.

trunk code doesn't have the allot_island_improvs call but the 
num_continents bug appears to still be there.  allot_island_improvs is a 
bit problematic here because it appears when a continent renumbering 
happens it will be called once for EACH tile on the renumbered 
continent.  For 2.0 this needn't be changed of course but hopefully 
trunk does have a better system.

The short explanation is that we can never decrease map.num_continents 
without iterating over the entire map to find the correct value for it, 
which the code does not do.  The safest way to handle this is just to 
always increase it.

The attached patches should fix it for 2.0 and trunk.  This probably 
replaces the previous patch I sent.  One variant or another should 
probably apply to S2_1 and S2_2 also.

-jason

Index: client/packhand.c
===
--- client/packhand.c	(revision 14840)
+++ client/packhand.c	(working copy)
@@ -1967,6 +1967,7 @@
   enum known_type old_known = ptile-known;
   bool tile_changed = FALSE;
   bool known_changed = FALSE;
+  bool renumbered = FALSE;
 
   if (ptile-terrain != packet-type) { /*terrain*/
 tile_changed = TRUE;
@@ -2030,13 +2031,17 @@
 /* We're renumbering continents, somebody did a transform.
  * But we don't care about renumbering oceans since 
  * num_oceans is not kept at the client. */
-map.num_continents = 0;
+renumbered = TRUE;
   }
 
   ptile-continent = packet-continent;
 
   if (ptile-continent  map.num_continents) {
 map.num_continents = ptile-continent;
+renumbered = TRUE;
+  }
+
+  if (renumbered) {
 allot_island_improvs();
   }
 
Index: client/packhand.c
===
--- client/packhand.c	(revision 14840)
+++ client/packhand.c	(working copy)
@@ -2370,21 +2370,9 @@
 unit_list_unlink_all(ptile-units);
   }
 
-  /* update continents */
-  if (ptile-continent != packet-continent  ptile-continent != 0
-   packet-continent  0) {
-/* We're renumbering continents, somebody did a transform.
- * But we don't care about renumbering oceans since 
- * num_oceans is not kept at the client. */
-map.num_continents = 0;
-  }
-
   ptile-continent = packet-continent;
+  map.num_continents = MAX(ptile-continent, map.num_continents);
 
-  if (ptile-continent  map.num_continents) {
-map.num_continents = ptile-continent;
-  }
-
   if (known_changed || tile_changed) {
 /* 
  * A tile can only change if it was known before and is still
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev


Re: [Freeciv-Dev] Should we release 2.0.10?

2008-06-22 Thread Daniel Markstedt
On Sun, 22 Jun 2008 20:05:19 +0900, Christian Prochaska  
[EMAIL PROTECTED] wrote:

 Is somebody able to fix the 2.0.9 crashes reported in #39472 and
 #39582? I can still reproduce the crashes with current S2_0. Another
 reported 2.0 problem is #39757, which has a patch that hasn't been
 committed yet.

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

Please let me know when these issues are resolved, and I'll resume the  
release process.

Preliminary NEWS at http://freeciv.wikia.com/wiki/NEWS-2.0.10

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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


[Freeciv-Dev] (PR#40306) hourglass mouse pointer never goes away

2008-06-22 Thread Jason Dorje Short

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40306 

Only tested in S2_1 gtk client so far.

At turn end the mouse pointer is changed to the hourglass.  This is 
changed back to a regular mouse pointer at the start of the next turn.

If you have the research dialog tab open when you press turn done, the 
hourglass pointer is still activated.  But it's not changed back to the 
regular mouse pointer until you switch back to the map tab, no matter 
how long you wait.

-jason



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


Re: [Freeciv-Dev] Should we release 2.0.10?

2008-06-22 Thread Jason Dorje Short
Daniel Markstedt wrote:
 On Sun, 22 Jun 2008 20:05:19 +0900, Christian Prochaska  
 [EMAIL PROTECTED] wrote:
 
 Is somebody able to fix the 2.0.9 crashes reported in #39472 and
 #39582? I can still reproduce the crashes with current S2_0. Another
 reported 2.0 problem is #39757, which has a patch that hasn't been
 committed yet.

 
 Please let me know when these issues are resolved, and I'll resume the  
 release process.
 
 Preliminary NEWS at http://freeciv.wikia.com/wiki/NEWS-2.0.10

39582 and 39757 are done.  39582 I can't reproduce without more 
instructions.

-jason

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


[Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work

2008-06-22 Thread Madeline Book

URL: http://bugs.freeciv.org/Ticket/Display.html?id=40184 

Hopefully committed correctly to S2_2 (r14846) and trunk (r14847).

There were some files added/moved and lots of changes to
makefiles, so be sure to re-run autogen.sh.


--
ほとんどできなかった。

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