[Freeciv-Dev] (PR#40430) Bug: Incorrect check for libggz in 2.1.6
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40430 This is an error in ggz.m4 but I don't know quite where. The intended behavior is: * libggz and ggzcore and ggzmod = 0.0.14 are required for client support. If --with-ggz-client=yes is given, configure exits if they are not found; otherwise client support simply isn't compiled in. * libggz and ggzdmod = 0.99.4 are required for server support. If --with-ggz-server=yes is given, configure exits if they are not found; otherwise server support simply isn't compiled in. What appears to happen is that the first check for 0.0.14 finds it, causing client support to succeed. The following check for 0.99.4 then also succeeds, even though 0.99.4 is not present, and this is what I don't understand. I think josef needs to look at ggz.m4. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40401) consistent segfault
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40401 Just on a hunch, try running it without sound: civclient -P none I believe it is. Also, you showed the behavior of the program in gdb but not a backtrace. After it crashes type bt full and send the output from that. Thirdly, you're running the fedora core version. I don't know what, if any, changes that distribution has. It's possible they are causing the problem. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40144) [Patch] Build multiple clients at once
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40144 For the record I think this is a great idea. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40317) ggz savegame support
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40317
New patch.
Some version checks will be necessary as only newer ggzd versions have
savegame support. And it's still not quite working.
-jason
Index: configure.ac
===
--- configure.ac (revision 14950)
+++ configure.ac (working copy)
@@ -535,6 +535,9 @@
else
AC_GGZ_CHECK
fi
+if test $ggz_server = yes ; then
+ AC_CHECK_FUNCS([chdir mkdtemp])
+fi
AC_SUBST(gui_sources)
AC_SUBST(CLIENT_CFLAGS)
Index: server/srv_main.c
===
--- server/srv_main.c (revision 14950)
+++ server/srv_main.c (working copy)
@@ -973,6 +973,8 @@
freelog(LOG_VERBOSE, Save time: %g seconds (%g apparent),
read_timer_seconds_free(timer_cpu),
read_timer_seconds_free(timer_user));
+
+ ggz_game_saved(filename);
}
/**
Index: server/ggzserver.c
===
--- server/ggzserver.c (revision 14950)
+++ server/ggzserver.c (working copy)
@@ -17,6 +17,9 @@
#ifdef GGZ_SERVER
+#include limits.h
+#include unistd.h
+
#include ggzdmod.h
#include fciconv.h
@@ -31,6 +34,8 @@
#include ggzserver.h
#include score.h
#include sernet.h
+#include srv_main.h
+#include stdinhand.h
bool with_ggz = FALSE;
@@ -93,12 +98,42 @@
static void handle_ggz_state_event(GGZdMod * ggz, GGZdModEvent event,
const void *data)
{
-#if 0
const GGZdModState *old_state = data;
GGZdModState new_state = ggzdmod_get_state(ggz);
- /* Currently no handling is done. */
-#endif
+ freelog(LOG_DEBUG, ggz changed state to %d., new_state);
+
+ if (*old_state == GGZDMOD_STATE_CREATED) {
+const char *savegame = ggzdmod_get_savedgame(ggz);
+
+/* If a savegame is given, load it. */
+freelog(LOG_DEBUG, Instructed to load \%s\., savegame);
+if (savegame) {
+ if (!load_command(NULL, savegame, FALSE)) {
+ /* no error handling? */
+ server_quit();
+ }
+}
+
+/* If we loaded a game that'll include the serverid. If not we
+ * generate one here. */
+if (strlen(srvarg.serverid) == 0) {
+ strcpy(srvarg.serverid, ggz-civ-XX);
+ if (!mkdtemp(srvarg.serverid)) {
+ fc_fprintf(stderr,
+ _(Unable to make temporary directory for GGZ game.\n));
+ exit(EXIT_FAILURE);
+ }
+}
+
+/* Change into the server directory */
+if (chdir(srvarg.serverid) 0) {
+ fc_fprintf(stderr, _(Unable to change into temporary server
+ directory %s.\n), srvarg.serverid);
+ server_quit();
+}
+freelog(LOG_DEBUG, Changed into directory %s., srvarg.serverid);
+ }
}
/
@@ -199,6 +234,10 @@
handle_ggz_seat_event);
ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_SPECTATOR_JOIN,
handle_ggz_spectator_seat_event);
+ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_SPECTATOR_LEAVE,
+ handle_ggz_spectator_seat_event);
+ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_SPECTATOR_SEAT,
+ handle_ggz_spectator_seat_event);
if (ggzdmod_connect(ggzdmod) 0) {
exit(EXIT_FAILURE);
}
@@ -332,4 +371,29 @@
num_victors = 0; /* In case there's another game. */
}
+/
+ Reports a savegame file to the GGZ server. In theory GGZ will allow
+ reloading from a file later.
+/
+void ggz_game_saved(const char *filename)
+{
+ char full_filename[PATH_MAX];
+
+ if (!path_is_absolute(filename)) {
+if (!getcwd(full_filename, sizeof(full_filename))) {
+ freelog(LOG_FATAL, Could not get cwd.);
+ exit(EXIT_FAILURE);
+}
+sz_strlcat(full_filename, /);
+sz_strlcat(full_filename, filename);
+ } else {
+sz_strlcpy(full_filename, filename);
+ }
+ freelog(LOG_DEBUG, Reporting filename %s to ggz., full_filename);
+
+ if (with_ggz) {
+ggzdmod_report_savegame(ggzdmod, full_filename);
+ }
+}
+
#endif
Index: server/ggzserver.h
===
--- server/ggzserver.h (revision 14950)
+++ server/ggzserver.h (working copy)
@@ -28,12 +28,15 @@
void ggz_report_victor(const struct player *winner);
void ggz_report_victory(void);
+void ggz_game_saved(const char *filename);
+
#else
# define with_ggz FALSE
# define ggz_initialize() (void)0
# define ggz_report_victor(pplayer) (void)0
# define ggz_report_victory() (void)0
+# define ggz_game_saved(filename) (void)0
#endif
Index: server/stdinhand.c
===
--- server/stdinhand.c (revision 14950)
+++ server/stdinhand.c (working copy)
@@ -3301,7 +3301,7 @@
legitimate but has inconsistencies) and would lead to a broken server
afterwards.
[Freeciv-Dev] (PR#40319) Removing a player causes client disonnection
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40319
Indeed, the same bug was present before but the symptoms were not as
harsh. After the fix game.players[-1] gets entirely overwritten;
before only some of it did, when game.nplayers dropped to negative in
the client.
The error seems to be that game.nplayers was never being sent to the
client in the first place. No matter how many players connect in
pregame the number of players in the client always remains 0. This does
not appear to be an issue in 2.1 or later.
This quick fix should avoid the error. It might be desirable to track
down the root problem and have the nplayers be sent but I'm not going to
spend the time on it.
-jason
Index: common/game.c
===
--- common/game.c (revision 14869)
+++ common/game.c (working copy)
@@ -481,6 +481,12 @@
{
int i;
+ if (game.nplayers == 0) {
+/* This happens in pregame, it's a bug that the nplayers is not being
+ * sent to the client and so is always zero. */
+return;
+ }
+
for (i = plrno; i game.nplayers - 1; i++) {
game.players[i]=game.players[i+1];
game.players[i].player_no=i;
@@ -495,6 +501,7 @@
}
game.nplayers--;
+ assert(game.nplayers = 0);
/* Reset player structure. */
player_init(game.players[game.nplayers]);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40124) Server option to disable hack challenge
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40124 Seems reasonable. However the hack request packet needs to be discarded too. I also think the GGZ case should be explicit, rather than requiring GGZ to call --no-hack. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#12472) abusable bug: team research
URL: http://bugs.freeciv.org/Ticket/Display.html?id=12472
Good patch. This variant turns it into a function and sync's the whole
research structure. I'll commit shortly.
-jason
Index: server/plrhand.c
===
--- server/plrhand.c (revision 14848)
+++ server/plrhand.c (working copy)
@@ -68,6 +68,19 @@
struct player *receiver);
/**
+ Make sure all research of players on the team is in sync with this
+ player's.
+**/
+static void sync_team_research(struct player *plr)
+{
+ players_iterate(pplayer) {
+if (players_on_same_team(pplayer, plr) pplayer-is_alive) {
+ pplayer-research = plr-research;
+}
+ } players_iterate_end;
+}
+
+/**
...
**/
void do_dipl_cost(struct player *pplayer, Tech_Type_id new_tech)
@@ -543,6 +556,8 @@
plr-research.bulbs_researched =
MAX(plr-research.bulbs_researched - total_bulbs_required(plr), 0);
+ sync_team_research(plr);
+
/* do all the updates needed after finding new tech */
found_new_tech(plr, plr-research.researching, TRUE, TRUE, A_NONE);
}
@@ -556,17 +571,10 @@
/* count our research contribution this turn */
plr-research.bulbs_last_turn += bulbs;
+ plr-research.bulbs_researched += bulbs;
- players_iterate(pplayer) {
-if (pplayer == plr) {
- pplayer-research.bulbs_researched += bulbs;
-} else if (pplayer-diplstates[plr-player_no].type == DS_TEAM
-pplayer-is_alive) {
- /* Share with union partner(s). We'll get in return later. */
- pplayer-research.bulbs_researched += bulbs;
-}
- } players_iterate_end;
-
+ sync_team_research(plr);
+
excessive_bulbs =
(plr-research.bulbs_researched - total_bulbs_required(plr));
@@ -576,6 +584,9 @@
update_tech(plr, 0);
}
}
+
+ /* Sanity check */
+ sync_team_research(plr);
}
/**
@@ -697,6 +708,10 @@
plr-research.changed_from = -1;
}
plr-research.researching=tech;
+
+ /* Update team research */
+ sync_team_research(plr);
+
if (plr-research.bulbs_researched total_bulbs_required(plr)) {
tech_researched(plr);
}
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#38354) Autoconnect can't handle password
URL: http://bugs.freeciv.org/Ticket/Display.html?id=38354 Any idea if this is present on 2.1/2.2/trunk? How do I set up a server with authentication anyway? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39131) Connection troubles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39131 I frankly have no idea if this change is correct. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39745) [Bug] 2.0 removing player should reset his team
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39745 Kinda strange, if you remove then create a player the team gets reset but if you disconnect then a new player connects, it does not get reset. But I wonder if this bug could hit other fields in the player structure too. What about re-initting the whole player? If so this could possibly apply to other branches too (team issue should only affect 2.0 I believe). -jason Index: common/game.c === --- common/game.c (revision 14856) +++ common/game.c (working copy) @@ -498,11 +498,7 @@ /* a bit of cleanup to keep connections sane */ conn_list_init(game.players[game.nplayers].connections); - game.players[game.nplayers].is_connected = FALSE; - game.players[game.nplayers].was_created = FALSE; - game.players[game.nplayers].ai.control = FALSE; - sz_strlcpy(game.players[game.nplayers].name, ANON_PLAYER_NAME); - sz_strlcpy(game.players[game.nplayers].username, ANON_USER_NAME); + player_init(game.players[game.nplayers]); } /** ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39745) [Bug] 2.0 removing player should reset his team
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39745 Seems this exact fix was already done for 2.1 and 2.2. Should work fine for 2.0 also. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39358) vote in pregame
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39358 A 5-minute fix for this is to stick the votes into the player structure. This is easy enough but as the vote records are still in an array inside the vote structures themselves player reordering will change everyone's vote around. Which basically means voting is useless since anyone leaving the game will change all votes around at complete random. This is actually a rather serious bug. The only solutions are to disable the vote code or to reset all votes when a player leaves. -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
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
[Freeciv-Dev] (PR#39472) Bug in v2.08 2.09 - Crash
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
[Freeciv-Dev] (PR#40227) Invalid string conversion from UTF-8 to ISO-8859-1
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40227 [EMAIL PROTECTED] - Sun May 04 09:50:59 2008]: 2008/5/4 Jason Dorje Short: This is not a bug in freeciv. If you use a non-universal character set on your command line then freeciv will simply be unable to display some characters. We can try to fudge it using transliteration but iconv/glibc support for that is pretty varied. The real solution is to use utf-8 for your command line charset. It might be bug that there *is* conversion to ISO-8859-1. I though that this conversion cannot be internal encoding - local encoding thing. Commandline should be UTF8. It is possible that it's not set at all in the actual Freeciv server environment launched from cron. Found two uses for ISO-8869-1 in Freeciv 2.1 codebase. 1) data encoding 2) fallback local encoding /* HACK: use latin1 instead of ascii in typical cases when the * encoding is unconfigured. */ local_encoding = ISO-8859-1; Latter probably explains my problem. Should we change this fallback to UTF-8 for 2.2 (S2_2) or 2.3 (TRUNK)? You can try it and see if it works. But my understanding is that when the locale is unconfigured (i.e. left at C in older distributions before utf-8 became standard) it's actually ascii or latin1 and any attempt to print utf-8 to the console will give garbage. If terminal software is better now and itself defaults to utf-8, then perhaps we could default there too. Perhaps it would even be possible to find the default of the terminal in that case. Or perhaps we should default just to ascii and get the transliteration to improve. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39563) [Bug] AI doesn't want to build anything in trunk / default.ruleset
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39563
[EMAIL PROTECTED] - Tue Feb 12 22:42:03 2008]:
/**
-...
-**/
-void copy_if_better_choice(struct ai_choice *cur, struct ai_choice *best)
-{
- if (best-want cur-want) {
-best = cur;
- }
-}
Just catching up on a week of freeciv mail and noticing this
now...but...surely the above function does nothing? best = cur only
assigns the pointer values, changing nothing in the actual data.
Ha! Nevermind me. Having read the rest of the ticket now I see that is
exactly the bug that caz is fixing.
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40094) Wrong choice of defender
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40094 It may be a foolish or misplaced bit of intelligence, but I'm pretty sure the reason for this is that when you attack with the howitzer the game judges the battle unwinnable and thus defends with the cheaper unit. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40080) replace city id with tile pointer or index
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40080 [wsimpson - Tue Feb 05 13:29:46 2008]: I've found a serious overflow bug already. The ids are unsigned short, the range is 65536 numbers, but ai/aidata.c allocates all players arrays with: /* max size of a short */ #define MAX_NUM_ID 32767 BV_DEFINE(bv_id, MAX_NUM_ID); BV_SET(ai-stats.diplomat_reservations, pcity-id); That's really ludicrous. First of all, unless IDs are recycled there is no theoretical limit on the highest ID. There is a limit on the total number of cities available at once, that being 1/4 the number of tiles (or possibly equal to the number of tiles, in some cases). Having a massive array to index what is basically a hash value is incredibly wasteful. Assuming doing a lookup into pcity-ai-diplomat_reservation boolean value is too slow (which is I assume why the BV is used), it would be appropriate to change the BV immediately to do a lookup by tile index. As for the general change, Mike has a good point that there could be hidden risks in making this conversion. If the conversion IS done, however, it should be as simple as simply removing the pcity-id value completely, seeing what breaks, and replacing those breakages with the use of pcity-tile-index. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40068) client gtk_progress_set_percentage() assertion
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40068 [wsimpson - Sun Feb 03 12:30:40 2008]: Jason Short wrote: Saving and loading doesn't generally give identical AI behavior so if this is caused by AI units moving or something then you won't get the same behavior from the savegame most likely. I've argued about this before (PR#39365), and it damn well SHOULD! I've spent a fair amount of time getting 2.1 to be reproducible, by checking and saving all myrand() states. Time to do again for 2.2! (Necessary, but tedious. Another ticket for another time.) For sure. I did some work on this in the past (there's an old old ticket about it) but never got past AI reproducibility problems. Meanwhile, this report has two problems listed. Let's dedicate it to solving the client issue (leaving the server issue for the next ticket): (civclient:17913): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage = 0 percentage = 1.0' failed 2: Verbindung zum Server verloren! The civclient.c line number is bogus, there are currently 807 lines. That's not civclient.c, that's civclient! The log message is merely: #: client/clinet.c:143 client/clinet.c:144 msgid Lost connection to server! msgstr Verbindung zum Server verloren! So, how is gtk_progress_set_percentage() called? There's no direct reference anywhere in the code, and nothing seems relevant in clinet.c at all! It's probably unrelated. Anybody out there understand the GTK2 client enough to track this down? Possibly. Note that the GTK error is likely completely unrelated to the disconnect, possibly having occurred many turns earlier. There are two places gtk_progress is used, in citydlg production progress and in the science progress dialog. At a glance I'd guess that the error happens because a negative value is set for one of these progress bars. This would be most likely if freecost or one of the other *cost server options is set, causing total research to fall below 0. It's also possible for city production to exceed 100% (as for settlers in a size-0 city) but this happens so often it is no doubt not the cause. Chris, were you playing with freecost or a similar option? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40069) server crash 2
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40069 Looks identical (or at least indistinguishable) from PR#40068. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40068) server crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40068 [wsimpson - Sat Feb 02 23:07:04 2008]: Jason Short wrote: Looks to me like this means dsite-location is invalid. I have no familiarity with this code however. That's (my) very new border code. I'll take a look at it. What I don't understand is why it's not reproducible? Usually, that means an uninitialized variable, but all these structures are zeroed with calloc(), so that's unlikely Saving and loading doesn't generally give identical AI behavior so if this is caused by AI units moving or something then you won't get the same behavior from the savegame most likely. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40070) Server crash 3
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40070 get_city_bonus is passing in a NULL city. This is allowed according to the effects interface (undocumented of course) but because it calls city_owner that function now segfaults on it. I have no definite opinion on whether NULL targets are worthwhile for get_xxx_bonus functions, but the function docs do need to specify. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40068) server crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40068 [chrisk - Sat Feb 02 12:25:18 2008]: SVN S2_2 rev 14375 02 FEB 2008 GTK2 Unreproducible server crash. I think I was moving a trireme. Previous savegame attached. Core file available on request. Backtrace follows. tile0 is being passed in a 0x04, obviously an invalid value. From the maphand code: struct vision_site *dsite = map_get_player_site(dtile, downer); int r = sq_map_distance(dsite-location, dtile); Looks to me like this means dsite-location is invalid. I have no familiarity with this code however. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40060) civserver core dump on debug command
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40060
This doesn't reliably crash for me either. But the memory error is
obvious enough from the backtrace and shows up in valgrind. This will
cause arbitrary memory reads every time /debug is done with no parameters.
Looks like this affects only 2.2/trunk. This patch should fix it.
-jason
Index: server/stdinhand.c
===
--- server/stdinhand.c (revision 14356)
+++ server/stdinhand.c (working copy)
@@ -2390,7 +2390,7 @@
} unit_list_iterate_end;
} else if (ntokens 0 strcmp(arg[0], timing) == 0) {
TIMING_RESULTS();
- } else if (strcmp(arg[0], ferries) == 0) {
+ } else if (ntokens 0 strcmp(arg[0], ferries) == 0) {
if (game.debug[DEBUG_FERRIES]) {
game.debug[DEBUG_FERRIES] = FALSE;
cmd_reply(CMD_DEBUG, caller, C_OK, _(Ferry system is no longer
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40064) Server crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40064 Looks like this is cause by 40063. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40058) mystrerror() and local encoding
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40058 Patch is fine but the comment is a bit misleading - generally the returned value is passed off to GTK which wants it in UTF-8 (aka the internal encoding). When used in the server this may not be the case. A similar patch should then work for the strsockerror function. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40020) Segfault in server aiunit.c ai_manage_units = plrhand.c maybe_make_contact()
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40020
I just ran it under S2_1 as:
$ ./ser -f ~/-0200x.sav -p 5557
...
set timeout 1
start
...
civserver: player.c:246: player_index: Assertion `pplayer' failed.
Aborted (core dumped)
Then the same under valgrind:
==5035== Invalid read of size 4
==5035==at 0x808A7B4: maybe_make_contact (plrhand.c:1206)
==5035==by 0x806D1E9: move_unit (unittools.c:2853)
==5035==by 0x80B11C4: handle_unit_move_request (unithand.c:1201)
==5035==by 0x813D2E8: ai_unit_move (aitools.c:1022)
==5035==by 0x813B69C: ai_unit_execute_path (aitools.c:194)
==5035==by 0x813BDFF: ai_follow_path (aitools.c:385)
==5035==by 0x813C10B: ai_unit_goto_constrained (aitools.c:459)
==5035==by 0x813C9B3: ai_unit_goto (aitools.c:790)
==5035==by 0x813BBA9: ai_gothere (aitools.c:317)
==5035==by 0x8141B85: ai_military_attack (aiunit.c:1755)
==5035==by 0x81423AF: ai_manage_military (aiunit.c:2078)
==5035==by 0x8142B09: ai_manage_unit (aiunit.c:2245)
==5035==by 0x8142F7F: ai_manage_units (aiunit.c:2351)
==5035==by 0x81343BE: ai_do_first_activities (aihand.c:426)
==5035==by 0x8054D25: ai_start_phase (srv_main.c:594)
==5035==by 0x8055124: begin_phase (srv_main.c:726)
==5035==by 0x80571D9: srv_running (srv_main.c:1816)
==5035==by 0x8057B87: srv_main (srv_main.c:2194)
==5035==by 0x804B195: main (civserver.c:258)
==5035== Address 0x4dd2e30 is 8 bytes inside a block of size 12 free'd
==5035==at 0x402365C: free (vg_replace_malloc.c:323)
==5035==by 0x8050488: genlist_unlink (genlist.c:141)
==5035==by 0x80C7B3F: unit_list_unlink (speclist.h:105)
==5035==by 0x80C7AD0: game_remove_unit (game.c:148)
==5035==by 0x8068E13: server_remove_unit (unittools.c:1374)
==5035==by 0x8069072: wipe_unit (unittools.c:1436)
==5035==by 0x8068014: bounce_unit (unittools.c:1044)
==5035==by 0x8068393: resolve_stack_conflicts (unittools.c:1086)
==5035==by 0x8068403: resolve_unit_stacks (unittools.c:1110)
==5035==by 0x8088937: update_players_after_alliance_breakup
(plrhand.c:457)
==5035==by 0x8088BB2: handle_diplomacy_cancel_pact (plrhand.c:546)
==5035==by 0x808A5C9: make_contact (plrhand.c:1180)
==5035==by 0x808A7F3: maybe_make_contact (plrhand.c:1207)
==5035==by 0x806D1E9: move_unit (unittools.c:2853)
==5035==by 0x80B11C4: handle_unit_move_request (unithand.c:1201)
==5035==by 0x813D2E8: ai_unit_move (aitools.c:1022)
==5035==by 0x813B69C: ai_unit_execute_path (aitools.c:194)
==5035==by 0x813BDFF: ai_follow_path (aitools.c:385)
==5035==by 0x813C10B: ai_unit_goto_constrained (aitools.c:459)
==5035==by 0x813C9B3: ai_unit_goto (aitools.c:790)
==5035==by 0x813BBA9: ai_gothere (aitools.c:317)
==5035==by 0x8141B85: ai_military_attack (aiunit.c:1755)
==5035==by 0x81423AF: ai_manage_military (aiunit.c:2078)
==5035==by 0x8142B09: ai_manage_unit (aiunit.c:2245)
==5035==by 0x8142F7F: ai_manage_units (aiunit.c:2351)
==5035==by 0x81343BE: ai_do_first_activities (aihand.c:426)
==5035==by 0x8054D25: ai_start_phase (srv_main.c:594)
==5035==by 0x8055124: begin_phase (srv_main.c:726)
==5035==by 0x80571D9: srv_running (srv_main.c:1816)
==5035==by 0x8057B87: srv_main (srv_main.c:2194)
==5035==by 0x804B195: main (civserver.c:258)
make_contact kills the unit because of the broken treaty and bouncing
(strange in itself but whatever). Then since maybe_make_contact doesn't
use a proper iterator it breaks the loop. Attached patch should fix it
for 2.1 and most likely 2.2/trunk.
-jason
Index: server/plrhand.c
===
--- server/plrhand.c (revision 14329)
+++ server/plrhand.c (working copy)
@@ -1203,9 +1203,9 @@
if (pcity) {
make_contact(pplayer, city_owner(pcity), ptile);
}
-unit_list_iterate(tile1-units, punit) {
+unit_list_iterate_safe(tile1-units, punit) {
make_contact(pplayer, unit_owner(punit), ptile);
-} unit_list_iterate_end;
+} unit_list_iterate_safe_end;
} square_iterate_end;
}
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40028) gtk/pango invalid UTF-8 warning, fix documentation
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40028
Here is a quick and partial fix. I assume that strerror() is one of the
most common offending functions, so I quickly went through and converted
all mystrerror users in client/ and server/ directories to use the
newly-written L_(). The only real issue with it is the use of
fixed-sized buffers which are wasteful if too large and broken if too
small, but as I said in my previous message I see no real alternative here.
Madeline, if you can test this and verify it fixes those strings then at
least we'll know we're getting somewhere. It would also be helpful if
you'd point out to us what other strings are being handled wrongly.
It is important to recognize which strings go in which encoding. If you
use printf() directly your strings must be in the local encoding. More
commonly freelog or fc_fprintf is used and these functions expect
strings in the internal encoding. Generally all freeciv functions
should expect the internal encoding unless specifically documented
otherwise.
Also as a side note there's another library we use, lua. Strings from
LUA are probably in the local encoding so should use L_ too.
-jason
Index: utility/fciconv.h
===
--- utility/fciconv.h (revision 14336)
+++ utility/fciconv.h (working copy)
@@ -19,6 +19,8 @@
#define FC_DEFAULT_DATA_ENCODING UTF-8
+#define L_(s, b) local_to_internal_string_buffer((s), (b), sizeof(b))
+
void init_character_encodings(const char *internal_encoding,
bool use_transliteration);
Index: server/meta.c
===
--- server/meta.c (revision 14336)
+++ server/meta.c (working copy)
@@ -44,6 +44,7 @@
#include connection.h
#include dataio.h
#include fcintl.h
+#include fciconv.h
#include log.h
#include mem.h
#include netintf.h
@@ -200,6 +201,7 @@
{
static char msg[8192];
static char str[8192];
+ char buf[512];
int rest = sizeof(str);
int n = 0;
char *s = str;
@@ -213,13 +215,14 @@
if ((sock = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
freelog(LOG_ERROR, Metaserver: can't open stream socket: %s,
- mystrerror());
+ L_(mystrerror(), buf));
metaserver_failed();
return FALSE;
}
if (my_connect(sock, (struct sockaddr *) meta_addr, sizeof(meta_addr)) == -1) {
-freelog(LOG_ERROR, Metaserver: connect failed: %s, mystrerror());
+freelog(LOG_ERROR, Metaserver: connect failed: %s,
+ L_(mystrerror(), buf));
metaserver_failed();
my_closesocket(sock);
return FALSE;
Index: server/sernet.c
===
--- server/sernet.c (revision 14336)
+++ server/sernet.c (working copy)
@@ -806,7 +806,9 @@
fromlen = sizeof(fromend);
if ((new_sock = accept(sockfd, fromend.sockaddr, fromlen)) == -1) {
-freelog(LOG_ERROR, accept failed: %s, mystrerror());
+char buf[512];
+
+freelog(LOG_ERROR, accept failed: %s, L_(mystrerror(), buf));
return -1;
}
@@ -885,16 +887,17 @@
struct ip_mreq mreq;
const char *group;
int opt;
+ char buf[512];
/* Create socket for client connections. */
if((sock = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
-die(socket failed: %s, mystrerror());
+die(socket failed: %s, L_(mystrerror(), buf));
}
opt=1;
if(setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
(char *)opt, sizeof(opt)) == -1) {
-freelog(LOG_ERROR, SO_REUSEADDR failed: %s, mystrerror());
+freelog(LOG_ERROR, SO_REUSEADDR failed: %s, L_(mystrerror(), buf));
}
if (!net_lookup_service(srvarg.bind_addr, srvarg.port, src)) {
@@ -904,23 +907,23 @@
}
if(bind(sock, src.sockaddr, sizeof (src)) == -1) {
-freelog(LOG_FATAL, bind failed: %s, mystrerror());
+freelog(LOG_FATAL, bind failed: %s, L_(mystrerror(), buf));
exit(EXIT_FAILURE);
}
if(listen(sock, MAX_NUM_CONNECTIONS) == -1) {
-freelog(LOG_FATAL, listen failed: %s, mystrerror());
+freelog(LOG_FATAL, listen failed: %s, L_(mystrerror(), buf));
exit(EXIT_FAILURE);
}
/* Create socket for server LAN announcements */
if ((socklan = socket(AF_INET, SOCK_DGRAM, 0)) 0) {
- freelog(LOG_ERROR, socket failed: %s, mystrerror());
+freelog(LOG_ERROR, socket failed: %s, L_(mystrerror(), buf));
}
if (setsockopt(socklan, SOL_SOCKET, SO_REUSEADDR,
(char *)opt, sizeof(opt)) == -1) {
-freelog(LOG_ERROR, SO_REUSEADDR failed: %s, mystrerror());
+freelog(LOG_ERROR, SO_REUSEADDR failed: %s, L_(mystrerror(), buf));
}
my_nonblock(socklan);
@@ -933,7 +936,7 @@
addr.sockaddr_in.sin_port = htons(SERVER_LAN_PORT);
if (bind(socklan, addr.sockaddr, sizeof(addr)) 0) {
-freelog(LOG_ERROR, bind failed: %s, mystrerror());
+freelog(LOG_ERROR, bind failed: %s, L_(mystrerror(), buf));
}
mreq.imr_multiaddr.s_addr = inet_addr(group);
@@ -941,7 +944,7 @@
if
[Freeciv-Dev] (PR#40028) gtk/pango invalid utf8 warning for LANG=fr_FR
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40028 [wsimpson - Sat Jan 26 10:38:42 2008]: Jason Short wrote: Madeline Book wrote: Oh wow, it really was trivial! But certainly not obvious for the likes of me :(. Once I ran the client with LANG= fr_FR.UTF-8 the libc messages displayed correctly and gtk/ pango was very happy. Nor to me. Leaving open until this is documented on our web pages and in the distributed files. This is a bug in freeciv. Background: when I wrote the charset code, I divided freeciv into 3 charsets. ... And where the heck is this documented? In this and other RT tickets, it seems. Strange, I thought I had written this up somewhere in the code, but I can find nothing. Where should it be documented? So in summary, if any bug reporters can track where the offending strings are coming from, fixing each incident is not too hard. In the meantime this should be listed as a known bug. I'm really tired of this laissez fair attitude toward bug fixing. Huh? I'm the one who pointed out it's a bug in the first place, remember? It may be a known bug, but that means there should be an open ticket, probably with a tracking ticket to gather the related incidents. Obviously. But this is not a bug that is going to be easy to verify as completely fixed. Doing so requires scanning every string (not every translated string; every string) to check for inclusions of libc output. It is a serious bug. That depends on how many such strings there are. I suspect there are very few, thus making it a non-fatal and rather rare bug. In any case, we can quickly fix the most common places and make it such. And the .UTF-8 workaround needs to be clearly documented! Everywhere! What workaround? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40028) gtk/pango invalid utf8 warning for LANG=fr_FR
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40028 [wsimpson - Mon Jan 21 09:51:15 2008]: Madeline Book wrote: Oh wow, it really was trivial! But certainly not obvious for the likes of me :(. Once I ran the client with LANG= fr_FR.UTF-8 the libc messages displayed correctly and gtk/ pango was very happy. Nor to me. Leaving open until this is documented on our web pages and in the distributed files. This is a bug in freeciv. Background: when I wrote the charset code, I divided freeciv into 3 charsets. The local charset is the one supported on the command line: this one is not under our control, and all output to the command line must be converted into it. The internal charset is the one used internally within freeciv: this is always utf-8 at the server but can be configured by the GUI at the client side (GUI writing is a lot easier if your charset is the same as your GUI library's). Meanwhile the data charset is the one used in all data files and network transactions and is utf-8. Now, the relevant point here is that while freeciv strings as translated by _() go directly into the internal encoding (see bind_textdomain_codeset in fciconv.c), anything returned by a library is going to go into whatever encoding that library uses. In the case of libc, this is the local encoding, and thus any translatable strings returned by libc need to be converted before they can be used. This can't really be changed; although we could hack the local encoding to switch to UTF-8 or just change the libc domain to return strings in that encoding, this would be poorly portable and would also cause stuff printed to the command line directly by libc to be in the wrong encoding. The functions to do the conversion exist in fciconv.h and are the same ones used for reading data from the command line: local_to_internal_string_malloc and local_to_internal_string_buffer. It would be nice to have a shortened form of these (like L_()), as has been discussed before, but since iconv requires a buffer into which to stick results this buffer must be either provided or allocated. Declaring the buffer statically is tempting but would lead to hard-to-trace bugs when L_() was used twice at once; some sort of garbage collection or buffer-rotating scheme might also come to mind for this. Perhaps #define L_(t,b) local_to_internal_string_buffer((t),b,sizeof(b)) might be the best way to go. Of course the real work lies in finding all the places where L_ should be used...which will require either a full audit or just fixing it as bugs are reported. The latter would be the easiest place to start as we already have a concrete bug report of a few and it's not likely too many libc-translated strings are being used internally within freeciv. So in summary, if any bug reporters can track where the offending strings are coming from, fixing each incident is not too hard. In the meantime this should be listed as a known bug. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40006) Placeholder strings like %d for gold amount isn't replaced
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40006
#: server/unittools.c:2143
#, c-format
msgid You found %d gold.
msgstr 金%dを見つけました。
static void hut_get_gold(struct unit *punit, int cred)
{
struct player *pplayer = unit_owner(punit);
notify_player(pplayer, punit-tile, E_HUT_GOLD,
_(You found %d gold.), cred);
pplayer-economic.gold += cred;
}
This is very bizarre and almost certainly the same as PR#40007. The
strings look fine (in PR#40007 also) and the code looks fine. There's a
very good chance it's caused by windows printf problems in combination
with utf-8. If that is the case, then there is a very good chance using
libutf8 (which has its own printf) would fix it. Use of libutf8 was
added in PR#12932 but removed in PR#36496, afaict. So if someone on
windows has the time, apply this patch and re-compile with
--with-libutf8=yes on your configure. If anyone can test this on other
platforms (or walk me through setting up locales, which have
mysteriously stopped working again) that would also be good.
-jason
Index: configure.ac
===
--- configure.ac (revision 14241)
+++ configure.ac (working copy)
@@ -372,6 +372,18 @@
AC_DEFINE_UNQUOTED(LOCALEDIR, ./share/locale, [Locale directory (windows)])
fi
+dnl Check libUTF8
+AC_ARG_WITH(libutf8,
+AC_HELP_STRING([--with-libutf8],
+ [Use the libutf8 library (needed for some systems)]),
+[with_libutf8=$withval], [with_libutf8=no])
+if test $MINGW32 = yes || test $with_libutf8 = yes; then
+ AC_CHECK_HEADER(libutf8.h, [],
+ AC_MSG_ERROR([Could not find libutf8 library (libutf8.h)]))
+ AC_DEFINE(HAVE_LIBUTF8_H, 1, [Use libutf8's stdio functions])
+ LIBS=$LIBS -lutf8
+fi
+
dnl Check for zlib (needed for libpng)
AC_CHECK_LIB(z, gzgets, ,
AC_MSG_ERROR([Could not find zlib library.]), )
Index: utility/support.h
===
--- utility/support.h (revision 14241)
+++ utility/support.h (working copy)
@@ -26,6 +26,9 @@
#ifdef HAVE_SYS_TYPES_H
#include sys/types.h
#endif
+#ifdef HAVE_LIBUTF8_H
+#include libutf8.h
+#endif
#ifdef TRUE
#undef TRUE
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39991) 2.1.1 GTK assert message pane after turn done + SDL future tech
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39991
I think neither of these bugs may be easy to solve.
[EMAIL PROTECTED] - Sat Dec 29 03:13:49 2007]:
Version: Freeciv 2.1.1
Client crash bug 1: (SDL AND GTK)
During the end-of-turn processing, you can still click on things on
the
screen. Have a long list on the message window from the last turn.
Before
this list is refreshed at the beginning of the next turn, double-click
one of
the messages near the bottom, which would normally take you to a city
or unit.
If the message list on the next turn is shorter, this will trigger an
assertion
failure. I think messages in the queue should be quietly discarded
when the
message window is cleared.
The queue is stored in the gtk events and I think there is no simple way
to discard it. A first step is to see what the assertion is and fix or
remove that. Long-term the solution may be to save all old messages
(previous turn's messages are useful to scroll back to...).
Can you tell us the assertion that is failing? Or even better, send a
backtrace after the crash?
Client reporting bug 1: (SDL) - This appears to work as expected for
GTK
I have researched all tech and I am working on Future Tech. One of
my units
encounters a hut and the report is:
Learned Future Tech 2. Researching Future Tech 3.
You found Future Tech 3 in ancient scrolls of wisdom.
I had been researching Future Tech 2. The research is now Future
Tech 3.
It looks like the second line is reporting one tech level too high.
I have not tested these with version 2.1.2 yet.
This one is also not easy to fix properly, because giving a random tech
is an atomic function and because of the hackish way future techs work.
The function call is give_random_free_tech which picks and assigns the
text. On its return the tech name can be determined. But because the
future tech count has already been incremented by this time the name for
the tech will be wrong.
There are a couple not-as-easy ways this could be fixed. The attached
patch breaks up give_random_free_tech, removing it completely and
integrating its parts into the 2 callers. We can therefore get the name
before the tech is assigned.
An alternative would be passing a string pointer (char**) parameter to
give_random_free_tech. This could then fill in the tech name. This
doesn't lend itself to future techs as Future tech %d is not a string
already allocated. A second problem is with translation if multiple
translations are to be sent to the clients, or if they are to receive a
pre-translated version.
Yet a third alternative is to redesign the future-tech system to be more
sane. But I don't know what form this would take.
-jason
Index: server/unittools.c
===
--- server/unittools.c (revision 14241)
+++ server/unittools.c (working copy)
@@ -2152,22 +2152,26 @@
struct player *pplayer = unit_owner(punit);
Tech_type_id new_tech;
const char* tech_name;
-
- new_tech = give_random_free_tech(pplayer);
-
+
+ new_tech = pick_random_tech(pplayer);
+
tech_name = advance_name_for_player(pplayer, new_tech);
notify_player(pplayer, punit-tile, E_HUT_TECH,
_(You found %s in ancient scrolls of wisdom.),
tech_name);
- script_signal_emit(tech_researched, 3,
- API_TYPE_TECH_TYPE, advances[new_tech],
- API_TYPE_PLAYER, pplayer,
- API_TYPE_STRING, hut);
notify_embassies(pplayer, NULL, NULL, E_TECH_GAIN,
_(The %s have acquired %s
from ancient scrolls of wisdom.),
nation_plural_for_player(pplayer),
tech_name);
+
+ do_free_cost(pplayer, new_tech);
+ found_new_tech(pplayer, new_tech, FALSE, TRUE);
+
+ script_signal_emit(tech_researched, 3,
+ API_TYPE_TECH_TYPE, advances[new_tech],
+ API_TYPE_PLAYER, pplayer,
+ API_TYPE_STRING, hut);
}
/**
Index: server/techtools.c
===
--- server/techtools.c (revision 14241)
+++ server/techtools.c (working copy)
@@ -622,7 +622,7 @@
/
Gives a player random tech, which he hasn't researched yet.
- Returns the tech. This differs from give_random_free_tech - it doesn't
+ Returns the tech. This differs from give_immediate_free_tech - it doesn't
apply free cost
/
Tech_type_id give_random_initial_tech(struct player* pplayer)
@@ -784,27 +784,16 @@
}
/
- Gives a player random tech, which he hasn't researched yet. Applies freecost
- Returns the tech.
-/
-Tech_type_id give_random_free_tech(struct player* pplayer)
-{
[Freeciv-Dev] (PR#40016) 2.1.2 assert - message pane after turn done
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40016 This is the same as 39991 which explains the cause. The message click is being dequeued after the next turn has started, meaning the message list was already reset. So it tries to activate message 5 (say) but the message list is of length 0. There needs to either be a check for this case (including the turn # in the queued event, assuming the turn is incremented at the same time the message queue is cleared, and assuming that's even possible which in the GTK case it may not be), or we could allow it by tracking old messages (keeping a message queue for each turn, say, which could then be flipped through...and on the same note the message queue should be saved and stored at the server end then so it will come back after a game is reloaded). Although 3991 says this is a problem under GTK and SDL on further thought I'm dubious it could happen in the GTK event system. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39792) explore server assert
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39792 [wsimpson - Tue Jan 15 17:28:03 2008]: Jason Short wrote: I'd really like a savegame from which this can be reproduced. What's wrong with the two existing savegames they've already provided? Indeed, I missed the first savegame. For some reason I thought it was the same as the second savegame which directly implies that it cannot be used to reproduce the problem. Yes, it is triggered for ground units. Apparently, you're the one who added the bad assert() because you didn't properly study the code. [I just didn't say so publicly until now. I was trying to be polite.] Obviously I'm the one who added the assert. It was intended to catch the situation where the invariant is broken. Which it has done. Nonetheless it was probably added by mistake as such checks are normally done with a CHECK_* macro (though that may not have been around back then) and it wasn't included in the last patch from RT. I'm using the two savegames to test my work, and I'll post the patch after they've been tested on both 2.1 and 2.2! Great, I'll leave you to it then. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40008) Server sends message using inappropriate language
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40008 [wsimpson - Fri Jan 11 18:48:25 2008]: Agro Rachmatullah wrote: However, the server sends Japanese message to all players (e.g., turn X starts)! Which means it will irritate people that can't understand Japanese. I also reported this problem in PR#39979, fixing the login messages. This will be released in 2.1.3. Other messages will have to wait for 2.2.0 or beyond, as they require extensive network packet format changes. Every client should be able to report its preferred language to the server. The server then should send messages with language appropriate for each client, or if not possible, in English. Your solution is not currently possible. Why not? I am not an expert with gettext but there's no fundamental reason the server cannot translate into multiple languages. And for some purposes (modpacks) this is more flexible than requiring client translations. Every client has the *.po files for all languages. All messages should be sent to every client in the (ASCII msgid) canonical form without translation. Each client translates to the appropriate local language. This will require a complete revision of the notify system, probably closely matching the event system (each notify message is usually followed by an event message). This requires the variable parameters to be sent to the client in a canonical form. Perhaps the systems can be merged. This also requires the unified object numbering system (PR#39476) and the struct universal revisions (PR#39515) be completed, started about 6 months ago To summarize: known problem, I'm working on it! I've spent the better part of 7 months cleaning up the translation code, beginning with PR#39383. Not what I'd intended to work on here (I was working on the new terrain), but there was such a mess, it was too hard to add new things properly. I think this problem is larger than you're making it out to be. It's not enough just to send an untranslated printf string and paramaters and have the string translated. Some parameters (but not others) must also be translated. What you're looking at therefore is a reimplementation of printf. In fact, this has been done before. It wasn't implemented, partly due to the complexity but largely because multilingual games are rare. The patch was by mateusz and should reside in RT somewhere, though I haven't been able to find it. It provided a printf-like syntax with different escape codes for each type of printable unit (non-translated string, translated string, etc, but working with the ugly-hack parts of translation like the near/at lines instead of removing them). Again, though this is possible, I don't see it as being advantageous over server-side translations into the target language. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39792) explore server assert
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39792 I'm pretty sure the bug here is more than just removing the assert. In the examples given, there WAS more to explore. Yet exploration stopped, and (presumably) inside the explore code the unit was turned off of explore mode, which isn't supposed to be possible (though I don't see why the check should be in the calling code and not in the explore code). /* ai_manage_explorer isn't supposed to change the activity but we * don't count on this. */ Incidentally it looks like this assert will trigger if handle_unit_change_activity is ever invoked for ACTIVITY_EXPLORE and an air unit, meaning a malicious client could crash the server that way. But I don't see how the assert can ever trigger for ground units unless ai_manage_explorer does drop the unit back into IDLE, which shouldn't be possible. I'd really like a savegame from which this can be reproduced. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40007) Crash when upgrading unit using Japanese language
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40007 [wsimpson - Mon Jan 14 05:22:11 2008]: Was finally able to get some labels showing in Japanese (mostly _Quit, _Cancel, but hardly any other buttons) -- the upgrade dialog showed English, and it didn't crash That means that the GTK library is using japanese correctly, but freeciv is still using the untranslated strings. I have trouble with this myself and aside from making sure you have gettext installed and linked (use --enable-nls in your configure I believe) I'm not sure what else needs to be done. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39970) BUG: makes fuzzy msgstr with c-format, when the msgid doesn't have any
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39970 Ugly problem. Isn't there a po-check script that compares printf arguments in the po files? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39961) Open diplomacy tabs from previous turns have wrong data during current turns
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39961 I agree that these dialogs should be automatically closed on turn end, and that it's a bug that they aren't updated. But there's more to the problem than just closing them. Cities, gold, and treaty status can change mid-turn and it is a bug that this isn't updated. This may not be fixable (actually for cities and gold it should be easy, for treaty status not so much) but that doesn't make it right. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39954) Savegame got corrupted - Bug? Cannot Meet with nations any longer.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39954 This is a reintroduction of an old, oft-fixed, and apparently under 2.1 oft-reported bug. Namely, the save (autosave) is being created with the human player toggled to AI. On load the AI flag is not unset. This happened in the past when the client crashed and the server would toggle the player to AI before doing an autosave and exiting. This was fixed some time ago, I don't remember the PR#. What we're seeing appears to be the same thing except that in the reported case it is always happening, not just when the client exits abnormally. The results of a human player being set as AI are annoying. The AI will move your units at the end of the turn if you didn't already. It will change your city productions. It will do your diplomacy for you, not letting you do it yourself. And so on. This should sound familiar from a few other recently reported bugs. The question then is how is the player getting toggled. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39961) Open trading tabs from previous turns have wrong data during current trading...
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39961 [EMAIL PROTECTED] - Mon Dec 10 23:16:18 2007]: Any open trading tabs from previous turns have wrong data during current trading because there is no refresh. For example, Gold data is not refreshed and a NEW trading tab is not opened, so... trading with Gold is all wrong. Are you talking about diplomacy? If not, what do you mean by trading tabs? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39959) SaveGame compression level changes when Leaving (re)Loading savegames!
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39959
Not sure how you could get the idea this was caused by the rulesets...
The bug is simple; compress_level (and in the development version,
compress_type) are not saved in the savegame.
Attached are some quick patches to fix it. This should get a bit of
review; care must be taken on load since the available compression types
may not be the same as when the game was saved.
The compress_type is saved as an integer meaning the enumeration order
gets linked to the savegame format. Alternately this could be saved as
a string I suppose. In 2.1 the compress_type is explicitly saved as
zlib (1) so such games loaded in 2.2 will continue to use zlib
compression rather than switching mid-game.
-jason
Index: utility/ioz.h
===
--- utility/ioz.h (revision 14152)
+++ utility/ioz.h (working copy)
@@ -27,6 +27,7 @@
typedef struct fz_FILE_s fz_FILE;
/* (possibly) supported methods (depending on config.h) */
+/* Do not reorder these or compatibility will be broken. */
enum fz_method { FZ_PLAIN = 0, FZ_ZLIB = 1, FZ_BZIP2 = 2, FZ_LAST };
#define FZ_NOT_USED FZ_LAST
Index: server/settings.c
===
--- server/settings.c (revision 14152)
+++ server/settings.c (working copy)
@@ -197,25 +197,7 @@
//
-#if defined(HAVE_LIBBZ2)
-#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
-#define GAME_MAX_COMPRESS_TYPE FZ_BZIP2
-#define GAME_DEFAULT_COMPRESS_TYPE FZ_BZIP2
-#elif defined(HAVE_LIBZ)
-#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
-#define GAME_MAX_COMPRESS_TYPE FZ_ZLIB
-#define GAME_DEFAULT_COMPRESS_TYPE FZ_ZLIB
-
-#else
-#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
-#define GAME_MAX_COMPRESS_TYPE FZ_PLAIN
-#define GAME_DEFAULT_COMPRESS_TYPE FZ_PLAIN
-
-#endif
-
-//
-
#define GEN_BOOL(name, value, sclass, scateg, slevel, to_client, \
short_help, extra_help, func, _default) \
{name, sclass, to_client, short_help, extra_help, SSET_BOOL, \
Index: server/savegame.c
===
--- server/savegame.c (revision 14152)
+++ server/savegame.c (working copy)
@@ -3720,6 +3720,26 @@
game.info.diplomacy = secfile_lookup_int_default(file, GAME_DEFAULT_DIPLOMACY,
game.diplomacy);
+game.info.save_compress_level
+ = secfile_lookup_int_default(file, GAME_DEFAULT_COMPRESS_LEVEL,
+ game.compress_level);
+game.info.save_compress_type
+ = secfile_lookup_int_default(file, GAME_DEFAULT_COMPRESS_TYPE,
+ game.compress_type);
+#ifndef HAVE_LIBBZ2
+if (game.info.save_compress_type == FZ_BZIP2) {
+ game.info.save_compress_type = GAME_DEFAULT_COMPRESS_TYPE;
+}
+#endif
+#ifndef HAVE_LIBZ
+if (game.info.save_compress_type == FZ_ZLIB) {
+ game.info.save_compress_type = GAME_DEFAULT_COMPRESS_TYPE;
+}
+#endif
+if (game.info.save_compress_type == FZ_PLAIN) {
+ game.info.save_compress_level = 0;
+}
+
sz_strlcpy(game.save_name,
secfile_lookup_str_default(file, GAME_DEFAULT_SAVE_NAME,
game.save_name));
@@ -4329,6 +4349,9 @@
/* Write civstyle for compatibility with old servers */
secfile_insert_int(file, 2, game.civstyle);
secfile_insert_int(file, game.info.save_nturns, game.save_nturns);
+ secfile_insert_int(file,
+ game.info.save_compress_level, game.compress_level);
+ secfile_insert_int(file, game.info.save_compress_type, game.compress_type);
secfile_insert_str(file, game.save_name, game.save_name);
secfile_insert_int(file, game.info.aifill, game.aifill);
secfile_insert_bool(file, game.scorelog, game.scorelog);
Index: common/game.h
===
--- common/game.h (revision 14152)
+++ common/game.h (working copy)
@@ -346,6 +346,24 @@
#define GAME_MIN_COMPRESS_LEVEL 1
#define GAME_MAX_COMPRESS_LEVEL 9
+#if defined(HAVE_LIBBZ2)
+#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
+#define GAME_MAX_COMPRESS_TYPE FZ_BZIP2
+#define GAME_DEFAULT_COMPRESS_TYPE FZ_BZIP2
+
+#elif defined(HAVE_LIBZ)
+#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
+#define GAME_MAX_COMPRESS_TYPE FZ_ZLIB
+#define GAME_DEFAULT_COMPRESS_TYPE FZ_ZLIB
+
+#else
+#define GAME_MIN_COMPRESS_TYPE FZ_PLAIN
+#define GAME_MAX_COMPRESS_TYPE FZ_PLAIN
+#define GAME_DEFAULT_COMPRESS_TYPE FZ_PLAIN
+
+#endif
+
+
#define GAME_DEFAULT_ALLOWED_CITY_NAMES 1
#define GAME_MIN_ALLOWED_CITY_NAMES 0
#define GAME_MAX_ALLOWED_CITY_NAMES 3
Index: server/savegame.c
===
--- server/savegame.c (revision 14152)
+++ server/savegame.c (working copy)
@@ -3731,6 +3731,13 @@
game.info.diplomacy = secfile_lookup_int_default(file, GAME_DEFAULT_DIPLOMACY,
[Freeciv-Dev] (PR#39957) multiple bugs in HACK handling
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39957 [book - Mon Dec 10 16:22:28 2007]: We ameliorated this situation somewhat for warserver by introducing/modifying the cmdlevels to: [...] What's the difference between ADMIN and CTRL access levels? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#8737) mapview centering error caused by panel resize
URL: http://bugs.freeciv.org/Ticket/Display.html?id=8737 [wsimpson - Fri Dec 07 10:58:13 2007]: Christian Knoke wrote: A vertical resize could be avoided if you move the minimap to the top. I don't understand this comment. The minimap is already on the top here. True, though that is configurable. It makes sense to split the lines, there is plenty of vertical space. Problem is if the number of lines is not constant then that causes whatever is below to be shifted up or down and that is slow as well. Marko already had some recent code to add an extra line for SDL. That whole function could be re-thought a bit for all clients! Formatting of the text should really be up to the GUI and not enforced by the common code. Although line height is constant and having a fixed number of lines is a reasonable limitation, character width is likely not to be constant and requiring a specific width is not viable. Then again we have one proposed patch which instituted a line wrap...which would again cause the number of lines to vary, creating a vertical resize problem. I stand by my claim that the proper solution is that the widget should auto-resize to be larger but never to be smaller. I find it hard to believe GTK cannot be easily configured for this, though vasco seemed to think that was the case and that intercepting the signal was the only solution. Even if this were done there might still be some translation issues as there is no real upper bound on how long a line might be. An alternative might be to embed this widget into a scrollable frame. Then if it exceeds the size rather than resizing the container it will just add scrollbars. Not perfect but surely better than the current system. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39937) [wishlist] civil war message takes you to capital
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39937
[EMAIL PROTECTED] - Sat Dec 01 05:12:21 2007]:
when a country is split by civil war (after you capture their capital),
you are given a message in the 'messages' tab. it would be great if
clicking this took you to the capital you juts captured (so you can see
where it is), like the warnings about improvments being completed.
Easily done.
-jason
Index: server/citytools.c
===
--- server/citytools.c (revision 14109)
+++ server/citytools.c (working copy)
@@ -1214,6 +1214,7 @@
struct player *pplayer = unit_owner(punit);
struct player *cplayer = city_owner(pcity);
bv_player saw_entering;
+ struct tile *pcity_tile = pcity-tile;
/* If not at war, may peacefully enter city. Or, if we cannot occupy
* the city, this unit entering will not trigger the effects below. */
@@ -1272,7 +1273,7 @@
pcity-name, pplayer-name);
remove_city(pcity);
if (do_civil_war) {
- civil_war(cplayer);
+ civil_war(cplayer, pcity_tile);
}
return;
}
@@ -1349,7 +1350,7 @@
send_player_info(pplayer, pplayer); /* Update techs */
if (do_civil_war) {
-civil_war(cplayer);
+civil_war(cplayer, pcity_tile);
}
}
Index: server/plrhand.c
===
--- server/plrhand.c (revision 14109)
+++ server/plrhand.c (working copy)
@@ -1656,8 +1656,11 @@
ensures that each side gets roughly half, which ones is still
determined randomly.
- Kris Bubendorfer
+
+ ptile is the trigger tile that is sent to clients with notification.
+ may be NULL.
***/
-void civil_war(struct player *pplayer)
+void civil_war(struct player *pplayer, struct tile *ptile)
{
int i, j;
struct player *cplayer;
@@ -1685,7 +1688,7 @@
freelog(LOG_VERBOSE,
%s's nation is thrust into civil war, created AI player %s,
pplayer-name, cplayer-name);
- notify_player(pplayer, NULL, E_CIVIL_WAR,
+ notify_player(pplayer, ptile, E_CIVIL_WAR,
_(Your nation is thrust into civil war,
%s is declared the leader of the rebel states.),
cplayer-name);
@@ -1719,7 +1722,7 @@
resolve_unit_stacks(pplayer, cplayer, FALSE);
- notify_player(NULL, NULL, E_CIVIL_WAR,
+ notify_player(NULL, ptile, E_CIVIL_WAR,
_(The capture of %s's capital and the destruction
of the empire's administrative\n
structures have sparked a civil war.
Index: server/plrhand.h
===
--- server/plrhand.h (revision 14109)
+++ server/plrhand.h (working copy)
@@ -99,7 +99,7 @@
} shuffled_players_iterate_end
bool civil_war_triggered(struct player *pplayer);
-void civil_war(struct player *pplayer);
+void civil_war(struct player *pplayer, struct tile *ptile);
void update_players_after_alliance_breakup(struct player* pplayer,
struct player* pplayer2);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39602) quickselect doesn't like the selection of many units
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39602 Your last patch looks like it does what it says it does. And I agree the current code is broken (modifying a unit list inside the list iterator is a no-no, that's what iterate_safe is for, but even with iterate_safe the behavior is broken as it just selected different units repeatedly). What I question is why you'd want the behavior to be that way when there are multiple units selected. Say I have 5 units on 5 different tiles selected...what use would be a quickselect that gives me 5 different land units, one per tile? I thought the purpose of quickselect was to give just ONE unit for quick action in multiplayer games. In that context I would think the key_quickselect action should just pick one unit on one tile to bring into focus. The question then becomes (when the battlegroup spans multiple tiles), which tile to choose. I'm no expect on multiplayer freeciv but I'd think the tile nearest the center of the screen would be the most likely to be the one the player wants. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#30483) 2.1.0b2/Windows Mouse goto with Air units causes client crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=30483 Is this still a problem? Or have these goto bugs been fixed? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 [wsimpson - Sat Nov 17 15:47:54 2007]: As I reported, folks are trying to use goto to explore. That is, they *want* to cheat. I included specific references. Please read and think before pontificating. Okay, although you specifically said in effect, this is really a cheat. But since cheating this way is not possible, can we close this ticket? (resolved/not-a-bug) -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39808) Use $sysconfdir for ggz config dirs in relevant Makefiles.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39808
I'm pretty sure this patch is correct from freeciv's end but the ggz.m4
file may still need some tweaking. I'm not sure if the ggzdconfdir that
it sets should use ${sysconfdir} (allowing a make-time override, which
would be rather bad in most situations since the conf dir depends on
ggzd which is not moving) rather than setting the value directly.
Jordi, is this sufficient for your needs (as committed in S2_1) or do we
need some other fix?
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39909) BUG: leader gender ignored in diplomat/spy dialog
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39909 [wsimpson - Sun Nov 25 18:14:27 2007]: Sir, the diplomat is waiting for your command Sir, the spy is waiting for your command Problematic. Using Sir and Ma'am does not jive well with all governments. But there is no form-of-address identifier in the government ruleset to cover this either. For 2.1 the best fix may just be removing the Sir, part (easily adapted with PO files which become fuzzy). For the development branch maybe we should add such a field to the governments.ruleset. Sir/Ma'am, Sire/, Comrade/Comrade, etc. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39919) freeze on Haiku (formaly openbeos)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39919 Can you kill it with a SEGV and get a backtrace? Or run within gdb? And yeah, disabling sound might be wise...sound really shouldn't crash though. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39849) strcasestr warning
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39849 [EMAIL PROTECTED] - Tue Nov 27 17:48:50 2007]: On 27/11/2007, Marko Lindqvist wrote: Now I got this same error in Ubuntu system. It seems that user has to define _GNU_SOURCE for __USE_GNU to be defined. No idea how it always gets set at configure time. Patch to define it both configure and compile time. This *can't* be the right fix. First of all, why is configure finding the function when it can't be found by gcc later? Secondly, _GNU_SOURCE? Is this a real define or just something internal to glibc? Why would strcasestr not be presented to the user by default as the manual indicated? Honestly this looks like a glibc bug. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39917) Diplomacy model bug: War as default relation for (previously) uncontacted allies of allies
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39917 [per - Tue Nov 27 07:08:39 2007]: There are two ways to fix this: - When you first meet an ally of your ally, the default state is cease-fire (brokered by your ally), and perhaps an offer of peace. - Or, when your ally allies someone you haven't met, you automatically meet this player, too, if yo have not already, and become in peace relation to it. (Peace brokered by your ally.) Let me know which one you prefer, and I can make a patch. The former seems more stable. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39808) Use $sysconfdir in relevant Makefiles.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39808
[jordi - Mon Oct 29 11:17:56 2007]:
data/Makefile.am installs GGZ stuff in the wrong place.
Attached patch should fix it.
Actually it should be installed in $ggzdconfdir which is provided by
AC_GGZ_SERVER (which isn't, but should be, called in configure).
Strangely though $ggzdconfdir defaults to $prefix/etc instead of to
$sysconfdir. Trying to get an explanation of that one from josef.
This patch does the initial fixes however (the ggz.m4 changes parallel
fixes already made in ggz).
-jason
Index: m4/ggz.m4
===
--- m4/ggz.m4 (revision 14077)
+++ m4/ggz.m4 (working copy)
@@ -999,6 +999,7 @@
AC_GGZ_GGZDMOD([ggz_server=yes], [ggz_server=no])
fi
if test $ggz_server = yes; then
+ AC_GGZ_SERVER
AC_DEFINE(GGZ_SERVER, 1, [Server support for GGZ])
else
if test $try_ggz_server = yes; then
Index: data/Makefile.am
===
--- data/Makefile.am (revision 14077)
+++ data/Makefile.am (working copy)
@@ -85,8 +85,8 @@
if GGZ_SERVER
ggzroom_DATA = civserver.room
-ggzroomdir = ${prefix}/etc/ggzd/rooms/
+ggzroomdir = ${ggzdconfdir}/rooms/
ggzgame_DATA = civserver.dsc
-ggzgamedir = ${prefix}/etc/ggzd/games/
+ggzgamedir = ${ggzdconfdir}/games/
endif
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39914) Freeciv Crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39914 [guest - Mon Nov 26 16:13:28 2007]: hi, freeciv client crashes too often after about 5-6 turns. sometimes says connection to server lost on a localhost game. Attached a bug report. thanks What platform are you using? What version of Freeciv? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39722) gcc-4.2 -O2 compile fails as predicted
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39722
Indeed, this is officially a gcc bug, explained in 39459 in more detail.
https://bugzilla.novell.com/show_bug.cgi?id=300410
Nonetheless I see no problem with working around it (as 39459 did). In
general we should strive to remove pointer-to-int casts like this as
they seem to be an ongoing problem.
The attached patch removes the (bad) assumption that CMA_NONE is -1,
changes CMA_NONE and CMA_CUSTOM to be positive (it doesn't use the
cmafec_preset_num value as this is variable), and adds an assertion to
trigger if there's a problem. I will commit to all branches (without
the assertion for 2.1).
-jason
Index: client/gui-gtk-2.0/cityrep.c
===
--- client/gui-gtk-2.0/cityrep.c (revision 14078)
+++ client/gui-gtk-2.0/cityrep.c (working copy)
@@ -52,9 +52,11 @@
#include cityrep.h
#define NEG_VAL(x) ((x)0 ? (x) : (-x))
-#define CMA_NONE (-1)
-#define CMA_CUSTOM (-2)
+/* Some versions of gcc have problems with negative values here (PR#39722). */
+#define CMA_NONE (1)
+#define CMA_CUSTOM (10001)
+
enum city_operation_type {
CO_CHANGE, CO_LAST, CO_NEXT, CO_FIRST, CO_NONE
};
@@ -542,12 +544,18 @@
gtk_menu_item_set_submenu(parent_item, menu);
if (change_cma) {
-for (i = -1; i cmafec_preset_num(); i++) {
- w = (i == -1 ? gtk_menu_item_new_with_label(_(none))
- : gtk_menu_item_new_with_label(cmafec_preset_get_descr(i)));
+w = gtk_menu_item_new_with_label(_(none));
+gtk_menu_shell_append(GTK_MENU_SHELL(menu), w);
+g_signal_connect(w, activate, G_CALLBACK(select_cma_callback),
+ GINT_TO_POINTER(CMA_NONE));
+assert(GPOINTER_TO_INT(GINT_TO_POINTER(CMA_NONE)) == CMA_NONE);
+
+for (i = 0; i cmafec_preset_num(); i++) {
+ w = gtk_menu_item_new_with_label(cmafec_preset_get_descr(i));
gtk_menu_shell_append(GTK_MENU_SHELL(menu), w);
g_signal_connect(w, activate, G_CALLBACK(select_cma_callback),
GINT_TO_POINTER(i));
+ assert(GPOINTER_TO_INT(GINT_TO_POINTER(i)) == i);
}
} else {
/* search for a none */
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39722) Change CMA by F1 panel don't work (gcc-4.2 specific bug)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39722 I'm going to commit a fix for this (why not) but I'd like more details. What platform are you using? Are you really saying that GINT_TO_POINTER is not reversible for negative numbers on your platform? If that's the case we need to audit a lot more users I think...and would need to complain to the glib people to get the macro to barf when given a negative. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39880) Right click GUI and Lepoard
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39880 [EMAIL PROTECTED] - Thu Nov 22 12:32:32 2007]: On Nov 22, 2007 12:54 PM, Daniel Markstedt [EMAIL PROTECTED] wrote: I have been running the game in OS X and on BootCamp Windows XP. In Leopard it first has to run X11 (which I do know is not your guys's problem). But on a Mac it looks wrong. The attached file is a pic. of what it looks like in Leopard. I have not changed the pic. The arrows are really cyan. This looks like a bug in the theme and/or theme engine. After the game has started, try going to GameLocal OptionsTheme and change to another theme in the dropdown. I can confirm that this had happened on Mac OS X for me as well, don't know what made it look like that. It also happens when you run it on Linux under Xvnc, but works good otherwise. I run the vnc server with Xvnc4 :0 -PasswordFile .vnc/passwd ( you need to run vncpasswd first, and launch an xterm on that display) Looks to me like the freeciv theme just doesn't set the colors for these scrollbuttons, causing them to take the default color which on mac is that bizarre cyan. Someone on linux with a bit of spare time could try to change the default theme and see if those sliders follow the style of your chosen theme. If true it should be easy for the theme author to fix. The other possibility is that the GTK theme engine is just buggy on mac... -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39883) Gtk2 client tends to flake out after a while
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39883 [EMAIL PROTECTED] - Thu Nov 22 18:54:08 Playing a full game through with a memory leak program enabled (valgrind works here but is too slow for a full game) would be very revealing I think. There is a fair amount of error reportage on the client's stderr. This seems to be disappointingly normal for this Linux system -- there are some errors that show up for every X program -- but perhaps some of them may be diagnostic; I haven't attempted to see if any of them are correlated with the reported symptoms. I could dig deeper. You could send the stderr reports and we could glance through them. Most likely nothing useful will be there though. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39885) Picks same nation twice from civil war list from same host nation
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39885 It doesn't look the same as 17436. From split_player() player_set_nation(cplayer, pick_a_nation(civilwar_nations, TRUE, FALSE, NOT_A_BARBARIAN)); The FALSE indicates that the is_available flag is to be ignored thus allowing any nation that has no player to be chosen. Yet I don't see how a nation chosen through civil war can avoid having pnation-player set. Will look at this in more detail later. Perhaps a debug command for triggering civil war would be useful. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39837) Happiness in big empires
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39837 [guest - Mon Nov 05 15:18:53 2007]: Hi Freeciv Team I'm just wondering if it is a feature or really a bug. Plying freeciv 2.1 for some days and found a difference in the happiness to the previous encountered game behavior. Right now I am ruling with a republic, and the rules tell me that I have 4 content players in each city up to a level of 13 cities. If I cross that limit I have 3 content and 1 unhappy. And now comes the bug (or new feature?), if I cross that limit again with 27 cities, then I have 2 content and 2 unhappy workers. Is this wanted? Pretty sure it is the intended behavior, yes. IIRC the setting is called empire_size_inc and gives 1 extra unhappy citizen for each (in this case) 13 cities. What do the rules (docs) say? Something different? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39838) Dollar symbol
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39838 [dmarks - Mon Nov 19 22:13:55 2007]: Replaces dollar symbol in economy icon with gold coin symbol borrowed from gui-sdl theme Human by Hogne Hasjkold. Aren't these small graphics all mapped from SVG files? It should be easy enough to find a free SVG dollar sign... -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39875) default theme scroll bar thumbs are hard to see
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39875 From being too small? They should be remade as SVG and rendered at a couple different sizes. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39870) unithand routines misnamed handle_* and real_*
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39870 [wsimpson - Sun Nov 18 01:56:44 2007]: Whether by history or mistake, some functions have a leading handle_ that are not actually network packet routines. Another has leading real_ This makes reading the code more difficult, as it is hard to discern where the calls are generated. bool handle_unit_move_request void handle_unit_activity_request static void handle_unit_activity_request_targeted static void handle_unit_activity_request_base void real_unit_change_homecity This is a historical coincidence (used as a lazy means of implementing actions then spread far and wide after the precedent was set) and would be a good target for fixing. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 [wsimpson - Sat Oct 27 09:22:54 2007]: I'm trying to understand the goto problem reports, and one common thread seems to be that folks are trying to use goto to explore. Then, they complain that it won't goto an unknown location (PR#15629), or the trireme sinks, or the unit doesn't handle dangerous paths (PR#39697), or the unit chooses suboptimal paths as they change during the goto (PR#13348), or problems flying across unknown territory, or whatever. In effect, this is really a cheat! They are trying to get the server to confirm information about places they don't know, or select good paths to places that are obscured by fog-of-war. No it's not. Client-side goto (which is what the user uses that shows the path to be taken) knows only what the client knows and this does not include anything more than what is shown. Unless there's a specific bug cheating is not possible; your words show you clearly don't understand how client-side goto works. What actually happens is that client-side goto assumes unknown tiles are generic, non-dangerous, base-move-level tiles. This means your triremes and airplanes will happily goto over them and sink or whatever. I propose that whenever the goto is destined to an unknown location, the cursor change to explore (or X or something) and the turns disappear. The explore action should have a direction, and a destination. Hiding the estimated number of turns in such situations is an option. But it's not a perfect fix as there are many instances where you want to do goto with ships or goto just one tile into the unknown and you really would want to see the number of turns. It could zig-zag for optimal exploration coverage (which it should be doing for AI units, anyway). Doing a goto into/through the unknown is not actually an explore. Zig-zag is an option (previous versions of goto/pf have tricked the search routine into taking diagonals) but again it's not a perfect solution as many times you will want to take the shortest/safest route possible. And of course you can always zig-zag yourself using waypoints. The server would have to select a new path every turn (which it should be doing for AI units, anyway). That is server goto. Quite the opposite of client goto. And yes that is what's used for AI units. Changing over from server to client goto was quite a step forward (only with client goto can the path to be taken be shown) and this isn't something that should be reverted. Also server goto is potentially buggy and tends to cheat. The orders list would be simplified, using the technique currently used for multi-part path selection. (What, you didn't know that the current code allows a goto, followed by a road, followed by another goto, etc? Seems overly complicated, and undocumented, but it's in there) Undocumented, yes. Incomplete, yes. But if you want more complex client goto (such as connect) that shows the path to be taken (highly desirable for road-building and one of the most oft-requested features before we implemented it) then this is the way it has to be done. It's also not overly complicated; the code was actually simplified to make orders work that way. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39818) 2.1.0 multiple bugs from same savegame, plus suggestions
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39818 [EMAIL PROTECTED] - Thu Nov 01 13:27:58 2007]: Ok, I made that one reproducable, too. End turn Save Game Leave Load last saved game Open city dialog of Ibadan - crash Thats really easy to follow. You will see immediatly whats going on. Ibadan was destroyed some turns ago, but it shows up on the map (which is correct). But when my borders expand over the destroyed city, the program thinks it is my city. Is this bug still present? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39858) middle click on unexplored territory causes SDL crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39858 You're overreacting. [wsimpson - Wed Nov 14 23:58:10 2007]: Jason Dorje Short wrote: SDL client, but it probably happens on any client. If the text.c function gets called for an unknown tile then ptile-terrain is NULL. No, it doesn't!!! Which you would have known had you bothered to check!!! That's a *BUG* in the SDL client!!! Perhaps, but fixing bugs like that should take second precedence to fixing crashes. And SDL client patches are in general outside of my scope, whereas the text.c code I am intimately familiar with. Furthermore, I've been told for many months not to add new translated strings to 2.1. That's a mixed bag. You should not add or change text that is going to be seen by users and confuse them. Adding an untranslated string to replace a crash is a different story - I'm quite sure users would rather see garbage text than see a crash. Worse, this length of text is completely out of scale for the popup! Works for me. Text formatting is an issue however. Worst, you stuck it before the debug data, instead of next to the rest of the terrain text, ruining *all* existing clients to fix a bug in SDL. Other clients don't show the popup in the unknown-tile case so behavior is unchanged for them. Finally, you did it to all branches, without waiting for review. This is justified for a simple crash-fix patch. I'm immediately replacing your patch, to at least use an existing string, and not screw up the entire project on a commonly seen tile just days before another release. Naturally I have no objections to a better fix. But fixing the SDL client bug itself would be best Yeah. I still don't think the text.c function should crash if given a bad tile though. And as a player I don't know if no popup is better than a semi-informative one that might be of (small) use to new players. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39867) freeciv 2.1.0 crashes when I conquer a city with paratroopers.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39867 [guest - Thu Nov 15 10:24:17 2007]: Hi, When I conquer a city using the Q option of my paratrooper, freeciv crashes :/ It doesn't If I simply go into the city with my para. What client are you using? Can you provide (attach) a savegame that lets us reproduce the crash? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39858) middle click for terrain info on unexplored territory causes crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39858
[wsimpson - Wed Nov 14 11:28:11 2007]:
In GTK2 for 2.1 -- just tested (again) -- the unknown tile does *not*
popup
the info box. That's the correct solution! It's a client problem
This patch fixes text.c to give a better info text. Not popping up the
window at all is also a solution but I see no problem with showing some
descriptive unknown-tile text either.
-jason
Index: client/text.c
===
--- client/text.c (revision 13944)
+++ client/text.c (working copy)
@@ -29,6 +29,7 @@
#include map.h
#include unitlist.h
+#include climap.h
#include climisc.h
#include civclient.h
@@ -94,6 +95,13 @@
static struct astring str = ASTRING_INIT;
astr_clear(str);
+ if (client_tile_get_known(ptile) == TILE_UNKNOWN) {
+/* Sanity check for clicking on unknown tiles. */
+astr_add(str, _(Unknown tile:\n
+ you must explore this tile to\n
+ gain information about it.));
+return str.str;
+ }
#ifdef DEBUG
astr_add_line(str, _(Location: (%d, %d) [%d]),
ptile-x, ptile-y, ptile-continent);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39857) attempt to bribe barbarian causes crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39857 [guest - Mon Nov 12 11:30:43 2007]: If the diplomat in the city attempts to subvert the barbarian legion with a bribe of 100 gold the game will crash. #0 0x0812f8b2 in diplomat_bribe_yes_callback (pWidget=0x93ee968) at diplomat_dialog.c:1311 #1 0x0816e020 in widget_pressed_action (pWidget=0x93ee968) at widget.c:402 #2 0x081387e1 in main_mouse_button_down_handler (pButtonEvent=0x8298d9c, pData=0x0) at gui_main.c:331 #3 0x081392b8 in gui_event_loop (pData=0x0, loop_action=0, key_down_handler=0x813851f main_key_down_handler, key_up_handler=0x8138785 main_key_up_handler, mouse_button_down_handler=0x81387a0 main_mouse_button_down_handler, mouse_button_up_handler=0x8138856 main_mouse_button_up_handler, mouse_motion_handler=0x81388c7 main_mouse_motion_handler) at gui_main.c:700 #4 0x0813996e in ui_main (argc=1, argv=0xbfbd4bf4) at gui_main.c:1000 #5 0x08050945 in main (argc=1, argv=0xbfbd4bf4) at civclient.c:380 (gdb) p pIncite_Dlg $1 = (struct small_diplomat_dialog *) 0x0 Seems the dialog has already been destroyed when the callback is triggered. This is a gui-sdl problem. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39391) Warnings in lua code
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39391 On 6/10/07, Per I. Mathisen [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39391 cc1: warnings being treated as errors ltable.c: In function ‘luaH_mainposition’: ltable.c:108: warning: cast from pointer to integer of different size ltable.c:110: warning: cast from pointer to integer of different size make[5]: *** [ltable.o] Error 1 make[5]: Leaving directory `/home/devel/freeciv/dependencies/lua/src' How should we fix these? Modify lua code in repository, or try to upgrade it to a more recent lua version? Would upgrading help? Anyone tried compiling a more recent lua with all the -W parameters we use? What version of gcc/platform are you using? I don't get these errors... -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39360) 2.1.0b4 civclient usability changed for worse
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39360 [s1kevin - Fri Apr 27 03:19:38 2007]: Usability dramatically decreased with 2.1.0b4. After creating a new game, I changed the worklist immediately to settlers, settlers, settlers, settlers, warriors, settlers, warriors, coinage. Works fine for me. Also, I created a new worklist, added items to it, then changed the name of the worklist. Once the name changed, my items disappeared from the worklist. :-( Works fine for me. When I click save options in the UI, it does not save work lists, and it seems it also doesn't want to save CMA's. Works fine for me. Users are not able to turn off production views in ISOTrident or amplio. I haven't tried the other tile sets. Works fine for me. I'm closing this report. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39357) 2.1.0b4: CRASH when trying to edit global worklists
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39357 [s1kevin - Wed Apr 25 02:43:53 2007]: Freeciv crashed when I tried to create a worklist. I had just loaded a saved game from 2.1.0b3, attempted to add a worklist (knowing that there were none), then FC crashed. Without a backtrace this will be very hard to track down. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39328) Reproducible Crash When Changing Tech Goal (2.1.0-b4 and SVN Head)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39328 The current code is clearly wrong. The va_arg may be implemented as a pointer rather than an inline array and so passing it multiple times to vsnprintf will generate garbage results on some platforms while working on others. Nothing I've read indicates that va_start can be called multiple times within the same function, though. If this is not guaranteed it is possible there is some platform that does not support it. The alternative is to use va_copy (a C99 add-on); however, since I notice we already use duplicate va_start calls elsewhere we might as well keep it like that for now. So I'm applying the patch as-is. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39330) Crash When Sharing Vision By Treaty (SVN Head)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39330 This is a tough bug. Looks to me like this is at the heart of a deeper problem where shared vision does not correctly handle vision layers or seen_count. Perhaps someday it would be appropriate to go through and rewrite shared vision so that it physically shares all vision sources between targets rather than sharing tiles directly. For the immediate bug, the problem is that a player tile is being marked as known (in map_set_known most likely) but the terrain for that tile is not being set (remaining NULL). Offhand I cannot see how this can happen. really_give_tile_info_from_player_to_player is very suspicious however. Is there really no way to reproduce this? Best bet might be to add some more assertions in for now. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39340) 2.1.0-beta3 - connected islands
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39340 Send us one or more rc files (particularly mapseed but also number of players) to reproduce it. Delving into the mapgen code is a very tricky business however. -jason ___ Freeciv-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39342) 2.1.0-beta4 border vs. fog of war
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39342 Not drawing borders under FOW is an interesting solution. If someone will make a patch for it we can test it out and see if it's playable. That would mean owner information for fogged tiles would not be sent to the client (probably in maphand.c), and the drawing code would need to be changed slightly to not draw borders when either of the tiles involved is fogged (in tilespec.c). -jason ___ Freeciv-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39330) Re: (PR#39335) Re: Fix for PR#39330
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39330 On 4/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39330 Jason Short wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39335 Attached to this message is a patch to fix the issue reported in PR#39330. Basically, the problem seems to be that cities can see unknown terrain, and this is considered acceptable and normal. But, in at least one place in the code that possibility is overlooked. In a player's view of a tile, the terrain ptr may be NULL (indicating it is unknown). Attempts to reference a member, such as 'type', of such a NULL ptr obviously results in a segfault. Good catch but the bug is deeper. We do NEED to know the terrain type here since the tile is being sent as TILE_KNOWN_FOGGED. Can you find a way to reproduce the problem and figure out why a known tile has unknown terrain type? That should not be possible. Well, the patch can be easily be modified to send 'TILE_UNKNOWN' instead, for the case when the tile is seen by a city, but unknown. A *seen* tile is allowed to be *unknown* according to a comment in server/maphand.c, starting at line 810 on the SVN head revision, which I quote here: A tile can be known but not seen. In this case the tile should be marked as TILE_UNKNOWN in the player tile, NOT as TILE_KNOWN_FOGGED. This isn't an error in the network code - it's an error in whatever code marked the plrtile as TILE_KNOWN_FOGGED yet didn't set the terrain. The vision code *has* changed recently so there is a reasonable chance of errors of this type. If we're able to reproduce it I can probably track it down next week, but if you can find the error yourself that would naturally be even better. / Return whether the player can see the tile. Seeing a tile means you have vision of it now (as opposed to knowing a tile which means you've seen it before). Note that a tile can be seen but not known (currently this only happens when a city is founded with some unknown tiles in its radius); in this case the tile is unknown (but map_get_seen will still return TRUE). / Is this in dispute? No, not in dispute. What is a bit tricky is that map_get_seen can return TRUE for unknown tiles: this is a low-level function that should only be used in a few places. P.S. Send future reports to the bug tracker. I *did* send the *report* to the tracker. Are you asking me to only send future *patches* for open/new tickets to the tracker and not the list? Do you want me to create a new ticket for each patch, like you apparently did to respond to my earlier message? You sent the report to the tracker then sent the patch to the list. I erronously made a new report which I merged into the old once when I realized it already existed (hence the ugly subject line). Simply responding to the email from the bug tracker (with PR# in the subject) is generally sufficient for any reply. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39332) lt.po is broken! (S2_1)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39332 On 4/10/07, Egor Vyscrebentsov [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39332 Good daytime! branches/S2_1 Revision: 12914 `make dist` failed due to: lt.po:9412: number of format specifications in 'msgid' and 'msgstr' does not match Therefore snapshot building does not work... So I ask Andrius Stikonas to fix lt.po as soon as possible. PS. All po files are regenerated during `make dist` so line number may differ. Problem lines: #. TRANS: Republic of the Polish #: client/text.c:1095 #, c-format msgid %s of the %s msgstr .; PPS. `msgfmt -c lt.po` shows all problems. I don't have development access right now but when I see errors/warnings like this I usually just mark the string as fuzzy and move on. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39335) Re: Fix for PR#39330
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39335 On 4/10/07, Eric McDonald [EMAIL PROTECTED] wrote: Hi, Attached to this message is a patch to fix the issue reported in PR#39330. Basically, the problem seems to be that cities can see unknown terrain, and this is considered acceptable and normal. But, in at least one place in the code that possibility is overlooked. In a player's view of a tile, the terrain ptr may be NULL (indicating it is unknown). Attempts to reference a member, such as 'type', of such a NULL ptr obviously results in a segfault. Good catch but the bug is deeper. We do NEED to know the terrain type here since the tile is being sent as TILE_KNOWN_FOGGED. Can you find a way to reproduce the problem and figure out why a known tile has unknown terrain type? That should not be possible. P.S. Send future reports to the bug tracker. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39317) Server crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39317 Can you reproduce this? What were you doing when it happened? Can you send a full backtrace? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (no subject)
[EMAIL PROTECTED] wrote: Hello. I just joined this list, and I did a quick skim thruogh the last few months archives. Please forgive me if I'm bringing up stuff thats already been dealth with. I've been trying to build freeciv under windows using MinGW/MSys for the past week or so. I had success doing this a couple years ago, but I hadn't played with it since. I ran into problems when it tried to link civserver.exe. If I ran autogen.sh normally, and then make I got this at the link step for civserver: The win32 client IS basically unmaintained. However your problem is in the bootstrap, nothing to do with client issues. What are you passing to freeciv on the configure (or autogen) line? It sounds like you are using --with-included-gettext. Do not do this. (The included gettext should be scrapped but it is very tedious to figure out what can safely be gotten rid of and what can't.) -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#35908) ocean madness
URL: http://bugs.freeciv.org/Ticket/Display.html?id=35908 Here is an updated patch for the crazy ocean graphics. Apply the patch and drop ocean.spec (attached) and ocean.png (from http://bugs.freeciv.org/Ticket/Attachment/182418/126789/ocean.png - earlier in the ticket) into data/amplio/. It works with blending. There are remaining problems but I believe they are all in the ocean.png file. This is for demo only right now but I feel pretty strongly this is the best way to go so hopefully I can get it cleaned up and the important parts committed pretty soon. -jason ocean.spec Description: Binary data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#35908) ocean madness
URL: http://bugs.freeciv.org/Ticket/Display.html?id=35908 [EMAIL PROTECTED] - Thu Feb 15 00:49:39 2007]: Hi, this is Eleazar. OK, i don't fully understand how your terrain engine works, but i believe, i can offer a solution that will work more simply. This idea would also easily support additional ocean terrains if needed. I made a mock-up of your system just by erasing some of the graphics in the current coasts and fiddling with the tilespec. See screenshot: http://bugs.freeciv.org/Ticket/Attachment/182574/127309/ocean_flat.png And amplio tarball: http://bugs.freeciv.org/Ticket/Attachment/182575/127314/amplio.tgz Problem is this basically forces you to give up blending for ocean graphics. You can still use cell graphics for ocean/deep borders (which I don't use) but you can't use blending along the coastlines - the reason being that such blending has to take place both between ocean and land (where the 'green' ocean1 graphic has to be used, now replaced) and between ocean and ocean (where it would have to use the base graphic). This could...maybe...be solved by using per-layer blending settings. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#35708) [Patch] Triremes cannot enter Deep Ocean
URL: http://bugs.freeciv.org/Ticket/Display.html?id=35708
[EMAIL PROTECTED] - Sun Feb 11 13:57:16 2007]:
Untested patch to limit Triremes to Ocean tiles. Applies on top of
Deep Ocean patch #34265.
Also, Triremes do not get move bonus from Nuclear Power.
Here is a more complicated spur-of-the-moment patch, it includes the
trireme limitation and 34265, as well as removing all the
trireme-specific code (much of which is already deprecated with the
removal of dangerous tiles).
-jason
Index: version.in
===
--- version.in (revision 12631)
+++ version.in (working copy)
@@ -24,4 +24,4 @@
# - Avoid adding a new manditory capbility to the development branch for
# as long as possible. We want to maintain network compatibility with
# the stable branch for as long as possible.
-FREECIV_NETWORK_CAPSTRING(+Freeciv.Devel.2007.Jan.21)
+FREECIV_NETWORK_CAPSTRING(+Freeciv.Devel.2007.Feb.12)
Index: doc/README.effects
===
--- doc/README.effects (revision 12631)
+++ doc/README.effects (working copy)
@@ -120,9 +120,6 @@
No_Anarchy
No period of anarchy between government changes.
-No_Sink_Deep
-Triremes no longer sink when on dangerous seas.
-
Nuke_Proof
City is nuke proof.
Index: server/ruleset.c
===
--- server/ruleset.c (revision 12631)
+++ server/ruleset.c (working copy)
@@ -1014,19 +1014,6 @@
free(def_vblist);
}
- /* highseas loss pct */
- def_vblist = secfile_lookup_int_vec(file, vet_levels_default,
- veteran_system.veteran_highseas_loss_pct);
- for (i = 0; i vet_levels_default; i++) {
-game.trireme_loss_chance[i] = def_vblist[i];
- }
- for (; i MAX_VET_LEVELS; i++) {
-game.trireme_loss_chance[i] = 50; /* default */
- }
- if (def_vblist) {
-free(def_vblist);
- }
-
/* move bonus */
def_vblist = secfile_lookup_int_vec(file, vet_levels_default,
veteran_system.veteran_move_bonus);
@@ -3205,8 +3192,6 @@
{
struct packet_ruleset_game misc_p;
- memcpy(misc_p.trireme_loss_chance, game.trireme_loss_chance,
- sizeof(game.trireme_loss_chance));
memcpy(misc_p.work_veteran_chance, game.work_veteran_chance,
sizeof(game.work_veteran_chance));
memcpy(misc_p.veteran_chance, game.veteran_chance,
Index: server/unithand.c
===
--- server/unithand.c (revision 12631)
+++ server/unithand.c (working copy)
@@ -951,10 +951,6 @@
notify_player(unit_owner(punit), src_tile, E_BAD_COMMAND,
_(%s can only move into your own zone of control.),
unit_type(punit)-name);
- } else if (reason == MR_TRIREME) {
-notify_player(unit_owner(punit), src_tile, E_BAD_COMMAND,
- _(%s cannot move that far from the coast line.),
- unit_type(punit)-name);
}
return FALSE;
}
Index: data/amplio/terrain2.spec
===
--- data/amplio/terrain2.spec (revision 12631)
+++ data/amplio/terrain2.spec (working copy)
@@ -144,76 +144,113 @@
tiles = { row, column,tag
; ocean cell sprites. See doc/README.graphics
- 0, 0, t.ocean_cell_u000
- 0, 2, t.ocean_cell_u100
- 0, 4, t.ocean_cell_u010
- 0, 6, t.ocean_cell_u110
- 0, 8, t.ocean_cell_u001
- 0, 10, t.ocean_cell_u101
- 0, 12, t.ocean_cell_u011
- 0, 14, t.ocean_cell_u111
+ 0, 0, t.l0.ocean_cell_u000
+ 0, 2, t.l0.ocean_cell_u100
+ 0, 4, t.l0.ocean_cell_u010
+ 0, 6, t.l0.ocean_cell_u110
+ 0, 8, t.l0.ocean_cell_u001
+ 0, 10, t.l0.ocean_cell_u101
+ 0, 12, t.l0.ocean_cell_u011
+ 0, 14, t.l0.ocean_cell_u111
- 1, 0, t.ocean_cell_d000
- 1, 2, t.ocean_cell_d100
- 1, 4, t.ocean_cell_d010
- 1, 6, t.ocean_cell_d110
- 1, 8, t.ocean_cell_d001
- 1, 10, t.ocean_cell_d101
- 1, 12, t.ocean_cell_d011
- 1, 14, t.ocean_cell_d111
+ 1, 0, t.l0.ocean_cell_d000
+ 1, 2, t.l0.ocean_cell_d100
+ 1, 4, t.l0.ocean_cell_d010
+ 1, 6, t.l0.ocean_cell_d110
+ 1, 8, t.l0.ocean_cell_d001
+ 1, 10, t.l0.ocean_cell_d101
+ 1, 12, t.l0.ocean_cell_d011
+ 1, 14, t.l0.ocean_cell_d111
- 2, 0, t.ocean_cell_l000
- 2, 2, t.ocean_cell_l100
- 2, 4, t.ocean_cell_l010
- 2, 6, t.ocean_cell_l110
- 2, 8, t.ocean_cell_l001
- 2, 10, t.ocean_cell_l101
- 2, 12, t.ocean_cell_l011
- 2, 14, t.ocean_cell_l111
+ 2, 0, t.l0.ocean_cell_l000
+ 2, 2, t.l0.ocean_cell_l100
+ 2, 4, t.l0.ocean_cell_l010
+ 2, 6, t.l0.ocean_cell_l110
+ 2, 8, t.l0.ocean_cell_l001
+ 2, 10, t.l0.ocean_cell_l101
+ 2, 12, t.l0.ocean_cell_l011
+ 2, 14, t.l0.ocean_cell_l111
- 2, 1, t.ocean_cell_r000
- 2, 3, t.ocean_cell_r100
- 2, 5, t.ocean_cell_r010
- 2, 7, t.ocean_cell_r110
- 2, 9, t.ocean_cell_r001
- 2, 11, t.ocean_cell_r101
- 2, 13, t.ocean_cell_r011
- 2, 15, t.ocean_cell_r111
+ 2, 1, t.l0.ocean_cell_r000
+ 2, 3, t.l0.ocean_cell_r100
+ 2, 5, t.l0.ocean_cell_r010
+ 2, 7,
[Freeciv-Dev] (PR#34265) [Patch] Deep ocean
URL: http://bugs.freeciv.org/Ticket/Display.html?id=34265
This patch 'fixes' the drawing problems for amplio with deep ocean.
These problems were several. First, as the comment says in
amplio.tilespec, drawing it like this is a hack. We basically overlay
coast on top of the actual ocean drawing, so that in the bottom layer
ocean and deep-ocean are drawn (with an appropriate border tile) and in
the next layer up coast and deep-ocean are drawn (with an appropriate
border tile).
Two bugs kept this from working. The first is that there is no way to
have 2 layers use the same match style for the same terrain, because the
layer number isn't a part of the sprite name. This patch fixes that by
adding the layer number (only for these boolean-matched corner cells
though).
The second is that the layers were being reversed! The coast has to be
drawn on *top* of the deep-ocean graphics or we always get ocean
overwriting the pretty coastlines. To work around this (and it too is
UGLY) I added a new terrain parameter, is_reversed. If this is set then
the 2 (or however many) layers are simply drawn in reverse order for
that terrain.
This patch has to be used with Daniel's terrain2.png (attached earlier
in the patch). Even so there are still problems. Because the ocean
encroaches onto the deep-ocean tiles (since ocean is only matched
against coastline, NOT against deep ocean), narrow areas of deep ocean
(often seen along the poles) look VERY bad.
Also, as a final comment, I think that ocean isn't deep enough on
average. With a trireme in an average map you can go pretty much anywhere.
-jason
Index: data/amplio/terrain2.spec
===
--- data/amplio/terrain2.spec (revision 12631)
+++ data/amplio/terrain2.spec (working copy)
@@ -144,76 +144,113 @@
tiles = { row, column,tag
; ocean cell sprites. See doc/README.graphics
- 0, 0, t.ocean_cell_u000
- 0, 2, t.ocean_cell_u100
- 0, 4, t.ocean_cell_u010
- 0, 6, t.ocean_cell_u110
- 0, 8, t.ocean_cell_u001
- 0, 10, t.ocean_cell_u101
- 0, 12, t.ocean_cell_u011
- 0, 14, t.ocean_cell_u111
+ 0, 0, t.l0.ocean_cell_u000
+ 0, 2, t.l0.ocean_cell_u100
+ 0, 4, t.l0.ocean_cell_u010
+ 0, 6, t.l0.ocean_cell_u110
+ 0, 8, t.l0.ocean_cell_u001
+ 0, 10, t.l0.ocean_cell_u101
+ 0, 12, t.l0.ocean_cell_u011
+ 0, 14, t.l0.ocean_cell_u111
- 1, 0, t.ocean_cell_d000
- 1, 2, t.ocean_cell_d100
- 1, 4, t.ocean_cell_d010
- 1, 6, t.ocean_cell_d110
- 1, 8, t.ocean_cell_d001
- 1, 10, t.ocean_cell_d101
- 1, 12, t.ocean_cell_d011
- 1, 14, t.ocean_cell_d111
+ 1, 0, t.l0.ocean_cell_d000
+ 1, 2, t.l0.ocean_cell_d100
+ 1, 4, t.l0.ocean_cell_d010
+ 1, 6, t.l0.ocean_cell_d110
+ 1, 8, t.l0.ocean_cell_d001
+ 1, 10, t.l0.ocean_cell_d101
+ 1, 12, t.l0.ocean_cell_d011
+ 1, 14, t.l0.ocean_cell_d111
- 2, 0, t.ocean_cell_l000
- 2, 2, t.ocean_cell_l100
- 2, 4, t.ocean_cell_l010
- 2, 6, t.ocean_cell_l110
- 2, 8, t.ocean_cell_l001
- 2, 10, t.ocean_cell_l101
- 2, 12, t.ocean_cell_l011
- 2, 14, t.ocean_cell_l111
+ 2, 0, t.l0.ocean_cell_l000
+ 2, 2, t.l0.ocean_cell_l100
+ 2, 4, t.l0.ocean_cell_l010
+ 2, 6, t.l0.ocean_cell_l110
+ 2, 8, t.l0.ocean_cell_l001
+ 2, 10, t.l0.ocean_cell_l101
+ 2, 12, t.l0.ocean_cell_l011
+ 2, 14, t.l0.ocean_cell_l111
- 2, 1, t.ocean_cell_r000
- 2, 3, t.ocean_cell_r100
- 2, 5, t.ocean_cell_r010
- 2, 7, t.ocean_cell_r110
- 2, 9, t.ocean_cell_r001
- 2, 11, t.ocean_cell_r101
- 2, 13, t.ocean_cell_r011
- 2, 15, t.ocean_cell_r111
+ 2, 1, t.l0.ocean_cell_r000
+ 2, 3, t.l0.ocean_cell_r100
+ 2, 5, t.l0.ocean_cell_r010
+ 2, 7, t.l0.ocean_cell_r110
+ 2, 9, t.l0.ocean_cell_r001
+ 2, 11, t.l0.ocean_cell_r101
+ 2, 13, t.l0.ocean_cell_r011
+ 2, 15, t.l0.ocean_cell_r111
+; deep ocean coasts.
+ 0, 1, t.l0.deep_cell_u000
+ 6, 2, t.l0.deep_cell_u100
+ 6, 4, t.l0.deep_cell_u010
+ 6, 6, t.l0.deep_cell_u110
+ 6, 8, t.l0.deep_cell_u001
+ 6, 10, t.l0.deep_cell_u101
+ 6, 12, t.l0.deep_cell_u011
+ 6, 14, t.l0.deep_cell_u111
+
+ 0, 1, t.l0.deep_cell_d000
+ 7, 2, t.l0.deep_cell_d100
+ 7, 4, t.l0.deep_cell_d010
+ 7, 6, t.l0.deep_cell_d110
+ 7, 8, t.l0.deep_cell_d001
+ 7, 10, t.l0.deep_cell_d101
+ 7, 12, t.l0.deep_cell_d011
+ 7, 14, t.l0.deep_cell_d111
+
+ 0, 1, t.l0.deep_cell_l000
+ 8, 2, t.l0.deep_cell_l100
+ 8, 4, t.l0.deep_cell_l010
+ 8, 6, t.l0.deep_cell_l110
+ 8, 8, t.l0.deep_cell_l001
+ 8, 10, t.l0.deep_cell_l101
+ 8, 12, t.l0.deep_cell_l011
+ 8, 14, t.l0.deep_cell_l111
+
+ 0, 1, t.l0.deep_cell_r000
+ 8, 3, t.l0.deep_cell_r100
+ 8, 5, t.l0.deep_cell_r010
+ 8, 7, t.l0.deep_cell_r110
+ 8, 9, t.l0.deep_cell_r001
+ 8, 11, t.l0.deep_cell_r101
+ 8, 13, t.l0.deep_cell_r011
+ 8, 15, t.l0.deep_cell_r111
+
; Deep Ocean sprites.
- 3, 0, t.deep_cell_u000
- 3, 2, t.deep_cell_u100
- 3, 4, t.deep_cell_u010
- 3, 6, t.deep_cell_u110
- 3, 8, t.deep_cell_u001
- 3, 10, t.deep_cell_u101
- 3, 12, t.deep_cell_u011
- 3, 14, t.deep_cell_u111
+ 3, 0, t.l1.deep_cell_u000
+ 3, 2, t.l1.deep_cell_u100
+
[Freeciv-Dev] (PR#35866) avoid sprite placement crash
URL: http://bugs.freeciv.org/Ticket/Display.html?id=35866
If no sprite is available (possible in some tilesets) nothing should be
drawn. Instead the code in question here crashes (because of doing
mod-0 math).
This simple patch fixes it. For 2.1 and development branches - I will
commit immediately.
-jason
Index: client/tilespec.c
===
--- client/tilespec.c (revision 12631)
+++ client/tilespec.c (working copy)
@@ -3575,18 +3575,21 @@
int count = sprite_vector_size(draw-layer[l].base);
int ox = draw-layer[l].offset_x, oy = draw-layer[l].offset_y;
-/* Pseudo-random reproducable algorithm to pick a sprite. */
-#define LARGE_PRIME 10007
-#define SMALL_PRIME 1009
-assert(count SMALL_PRIME);
-assert((int)(LARGE_PRIME * MAP_INDEX_SIZE) 0);
-count = ((ptile-index
- * LARGE_PRIME) % SMALL_PRIME) % count;
-if (draw-layer[l].is_tall) {
- ox += FULL_TILE_X_OFFSET;
- oy += FULL_TILE_Y_OFFSET;
+if (count 0) {
+ /* Pseudo-random reproducable algorithm to pick a sprite. */
+ const int LARGE_PRIME = 10007;
+ const int SMALL_PRIME = 1009;
+
+ assert(count SMALL_PRIME);
+ assert((int)(LARGE_PRIME * MAP_INDEX_SIZE) 0);
+ count = ((ptile-index
+ * LARGE_PRIME) % SMALL_PRIME) % count;
+ if (draw-layer[l].is_tall) {
+ ox += FULL_TILE_X_OFFSET;
+ oy += FULL_TILE_Y_OFFSET;
+ }
+ ADD_SPRITE(draw-layer[l].base.p[count], TRUE, ox, oy);
}
-ADD_SPRITE(draw-layer[l].base.p[count], TRUE, ox, oy);
} else {
int match_type = draw-layer[l].match_type;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Releases
I know I haven't done any work lately, but since nobody has yet taken over my job of making releases I suppose I had best get back to it. The next step for 2.1 is another beta release. It's been an absurd 6 months since the last one. Also, it looks like 2.0 has enough fixes to justify a 2.0.9 release. This should also be easy to do - the main things to be done are updating of news (see NEWS-2.0.9 on freeciv wikia) and the ChangeLog. Hopefully these can both be done tomorrow (Sunday). Anyone who objects, speak up now. Anyone who can assist, be around on IRC. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
