[Freeciv-Dev] (PR#40328) Fwd: City List on SDL client
http://bugs.freeciv.org/Ticket/Display.html?id=40328 >
> [cproc - So 13. Jul 2008, 00:10:21]:
>
> 2008/6/26 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> >
> > http://bugs.freeciv.org/Ticket/Display.html?id=40328 >
> >
> > This transaction appears to have no content
> >
> >
> >
> > Attached are screenshots of the city list view (F1) in the SDL
>client showing at various stages in the game. As the number of
>cities you own increases the area used for actually showing the
>city list decreases, until after you have around 60 or so cities,
>you can't see any of them.
> >
> >
> >
> > Version information:
> >
> > Built on PCLinuxOS from source. I first used 2.1.4 and the problem
>was there. I switched to 2.1.5 and the problem remains.
> >
>
> Patch attached.
>
>
The patch was for S2_1. Patch for S2_2 and trunk attached to this
message. Committed to S2_1 (r14997), S2_2 (r14998) and trunk (r14999).
Index: client/gui-sdl/cityrep.c
===
--- client/gui-sdl/cityrep.c (revision 14997)
+++ client/gui-sdl/cityrep.c (working copy)
@@ -281,7 +281,7 @@
pBuf->action = popup_citydlg_from_city_report_callback;
set_wstate(pBuf, FC_WS_NORMAL);
pBuf->data.city = pCity;
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf , WF_HIDDEN);
}
hh = pBuf->size.h;
@@ -294,7 +294,7 @@
pStr->style |= SF_CENTER;
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -304,7 +304,7 @@
/* --- */
pBuf = create_checkbox(pWindow->dst,
cma_is_city_under_agent(pCity, NULL), WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -320,7 +320,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_OVERVIEW_LAND);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -334,7 +334,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_FOOD_SURPLUS);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -362,7 +362,7 @@
}
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -376,7 +376,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_TRADE);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -389,7 +389,7 @@
pStr->style |= SF_CENTER;
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -403,7 +403,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_GOLD);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -417,7 +417,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_SCIENCE);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -431,7 +431,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_LUX);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -446,7 +446,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_PROD);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -459,7 +459,7 @@
pStr->style |= SF_CENTER;
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-if(count > 9 * COL) {
+if(count > 13 * COL) {
set_wflag(pBuf, WF_HIDDEN);
}
hh = MAX(hh, pBuf->size.h);
@@ -474,7 +474,7 @@
pStr->fgcol = *get_game_colorRGB(COLOR_THEME_CITYDLG_SUPPORT);
pBuf = create_iconlabel(NULL, pWindow->dst, pStr,
WF_RESTORE_BACKGROUND);
-i
Re: [Freeciv-Dev] (PR#40375) [Editor] Property editor basic framework
http://bugs.freeciv.org/Ticket/Display.html?id=40375 > Marko Lindqvist wrote: > 2008/7/14 Madeline Book: >> Since there is a maximum of 255 packet types > > Is this likely to be problem in 2.2.x lifetime? If yes, we should > change packet type size to 16 bits as soon as possible. We can break > network compatibility now, but definitely not after 2.2.0 has been > released. > It would seem wise to change it now as there's is no downside to it. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40377) Merge normal_player_count() and player_count_no_barbarians()
http://bugs.freeciv.org/Ticket/Display.html?id=40377 >
Functions normal_player_count() and player_count_no_barbarians() do
exactly same thing. Attached patch removes
player_count_no_barbarians()
- ML
diff -Nurd -X.diff_ignore freeciv/ai/aicity.c freeciv/ai/aicity.c
--- freeciv/ai/aicity.c 2008-06-26 23:22:30.0 +0300
+++ freeciv/ai/aicity.c 2008-07-14 23:32:51.0 +0300
@@ -795,7 +795,7 @@
{
int v = 0;
int cities[REQ_RANGE_LAST];
- int nplayers = player_count_no_barbarians();
+ int nplayers = normal_player_count();
struct ai_data *ai = ai_data_get(pplayer);
bool capital = is_capital(pcity);
bool can_build = TRUE;
diff -Nurd -X.diff_ignore freeciv/server/citytools.c freeciv/server/citytools.c
--- freeciv/server/citytools.c 2008-07-03 02:25:58.0 +0300
+++ freeciv/server/citytools.c 2008-07-14 23:35:27.0 +0300
@@ -1305,7 +1305,7 @@
if (is_capital(pcity)
&& city_list_size(cplayer->cities) >= game.info.civilwarsize
&& game.info.civilwarsize < GAME_MAX_CIVILWARSIZE
- && player_count_no_barbarians() < MAX_NUM_PLAYERS
+ && normal_player_count() < MAX_NUM_PLAYERS
&& civil_war_triggered(cplayer)) {
try_civil_war = TRUE;
}
diff -Nurd -X.diff_ignore freeciv/server/meta.c freeciv/server/meta.c
--- freeciv/server/meta.c 2008-06-24 22:39:48.0 +0300
+++ freeciv/server/meta.c 2008-07-14 23:40:34.0 +0300
@@ -52,7 +52,9 @@
#include "timing.h"
#include "version.h"
+/* server */
#include "console.h"
+#include "plrhand.h"
#include "srv_main.h"
#include "meta.h"
@@ -272,7 +274,7 @@
s = end_of_strn(s, &rest);
/* NOTE: send info for ALL players or none at all. */
-if (player_count_no_barbarians() == 0) {
+if (normal_player_count() == 0) {
mystrlcpy(s, "dropplrs=1&", rest);
s = end_of_strn(s, &rest);
} else {
diff -Nurd -X.diff_ignore freeciv/server/sernet.c freeciv/server/sernet.c
--- freeciv/server/sernet.c 2008-06-28 17:49:11.0 +0300
+++ freeciv/server/sernet.c 2008-07-14 23:33:11.0 +0300
@@ -1209,7 +1209,7 @@
}
my_snprintf(players, sizeof(players), "%d",
- player_count_no_barbarians());
+ normal_player_count());
my_snprintf(port, sizeof(port), "%d",
srvarg.port );
diff -Nurd -X.diff_ignore freeciv/server/srv_main.c freeciv/server/srv_main.c
--- freeciv/server/srv_main.c 2008-07-07 19:04:55.0 +0300
+++ freeciv/server/srv_main.c 2008-07-14 23:31:38.0 +0300
@@ -1119,14 +1119,6 @@
}
/**
-...
-**/
-int player_count_no_barbarians(void)
-{
- return player_count() - server.nbarbarians;
-}
-
-/**
Returns 0 if connection should be closed (because the clients was
rejected). Returns 1 else.
**/
diff -Nurd -X.diff_ignore freeciv/server/srv_main.h freeciv/server/srv_main.h
--- freeciv/server/srv_main.h 2008-05-06 03:59:25.0 +0300
+++ freeciv/server/srv_main.h 2008-07-14 23:31:47.0 +0300
@@ -96,7 +96,6 @@
void identity_number_release(int id);
void identity_number_reserve(int id);
int identity_number(void);
-int player_count_no_barbarians(void);
void server_game_init(void);
void server_game_free(void);
void aifill(int amount);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40375) [Editor] Property editor basic framework
http://bugs.freeciv.org/Ticket/Display.html?id=40375 > > [EMAIL PROTECTED] - Mon Jul 14 16:59:15 2008]: > > All this sounds very promising! Do you already know how list of known > techs will be edited? Current method is definitely not intuitive (if > it still exist at all) My plan is to make a third panel to the right of the properties panel in the property editor window, which will contain a listview used to view/edit complex property values (i.e. arrays, bitvectors, etc.). Each complex property will have its own store that will be swapped into the listview when a button is pressed to the right of the property name/value in the properties panel. As for the the particular case of a player's known techs, this could be implemented as a property of a player object, or as a property of a team. This is not so difficult once the framework it in place. I would mention in passing that I don't agree with having the 'struct player_research research' field in 'struct team'. I believe it should stay in 'struct player', the reason being that pooled team research (the reason I assume that the 'research' field was moved to the team) is not a good gameplay option because it distorts the science discovery rate too much. It is also much easier to implement pooled team research from separate player research in a team, than it is to implement separate player research in a team from pooled team research data. The goal of the "team" concept should be to allow fixed, before hand agreed upon alliances of players, not as a form of multi-control (more than one connection controlling a player at the same time, which might be interesting too, though I digress ;)). Of course this should probably be in a different ticket, and I am open to arguments against this position. > > Since there is a maximum of 255 packet types > > Is this likely to be problem in 2.2.x lifetime? If yes, we should > change packet type size to 16 bits as soon as possible. We can break > network compatibility now, but definitely not after 2.2.0 has been > released. Actually having a large PACKET_EDIT_ for each object seems to me to be an acceptable format for property editing (but for example it would inefficient for the paint-style tools). So I don't see a large problem due to the 255 packet type limit at the moment. What could be useful with another byte for the packet type, is to be able to put packets into categories based on that first byte. This could be used for example to simplify the tests in server_packet_input. But it's not really necessary, just something that came to me right now as I was typing. :) -- 治療がない病気なのです。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40376) ai_unit_new_role() assert
http://bugs.freeciv.org/Ticket/Display.html?id=40376 > assert(!unit_has_orders(punit) || task == AIUNIT_NONE) seems to be failing sometimes (I have logging for the situations when it would fail in my public server but assert itself is disabled) It seems that unit is marked as being under human control, but player is under AI control. Maybe bug is in how player is aitoggled under AI Control. Backtrace: 4: 2.1.5-c2/server/civserver(ai_unit_new_role+0x7b) 5: 2.1.5-c2/server/civserver 6: 2.1.5-c2/server/civserver(ai_manage_units+0xc2) 7: 2.1.5-c2/server/civserver(ai_do_first_activities+0x3c) - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40375) [Editor] Property editor basic framework
http://bugs.freeciv.org/Ticket/Display.html?id=40375 > All this sounds very promising! Do you already know how list of known techs will be edited? Current method is definitely not intuitive (if it still exist at all) 2008/7/14 Madeline Book: > > Since there is a maximum of 255 packet types Is this likely to be problem in 2.2.x lifetime? If yes, we should change packet type size to 16 bits as soon as possible. We can break network compatibility now, but definitely not after 2.2.0 has been released. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40341) Saving games fails silently on Windows Vista
http://bugs.freeciv.org/Ticket/Display.html?id=40341 > > [cproc - Sa 12. Jul 2008, 17:57:34]: > > The savegames shouldn't be stored in the game directory anyway, as Jason > pointed out in PR#39582. The attached patch makes them be stored in the > user's home directory by the internal server, like on the other platforms. > patch committed to S2_0 (r14993), S2_1 (r14994), S2_2 (r14995) and trunk (r14996) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40297) WSAEINPROGRESS not handled for metaserver connect
http://bugs.freeciv.org/Ticket/Display.html?id=40297 > > [book - So 13. Jul 2008, 20:31:04]: > > I was confused today on the forums about this issue; ticket > is still open but the patch has been commited already. > > So I am just recording here that this patch has been committed > to S2_1 (r14837), S2_2 (r14838) and trunk (r14839). > Sorry, forgot to update the ticket. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40349) "else" clauses in Makefile.am conditionals
http://bugs.freeciv.org/Ticket/Display.html?id=40349 > 2008/7/13 Daniel Markstedt: > >> [EMAIL PROTECTED] - Tue Jul 01 20:47:26 2008]: >> >> 2008/7/1 Marko Lindqvist: >> > 2008/7/1 Jason Dorje Short: >> > >> >> "make dist" assumes all conditionals pass to find out what needs > to be >> >> distributed. >> > >> > I believe "make dist" collects files from both "conditional pass" >> > and "conditional fails" possibilities. >> >> In the case of ftwl-directory, I suspect that old automake is not >> properly handling conditionally built library (even though it's in >> "conditional pass" branch) and subsequently not adding source files it >> would require. >> >> Attached patch removes conditionality from library and makes entering >> to the directory in the first place conditional instead. Conditional >> subdirs are already used in other places. >> This works for me (automake 1.10.1) at least. I can compile both >> ftwl-client and other clients, and 'make dist' adds ftwl-files no >> matter which client is enabled from configure. > > I cannot currently test this patch, as configuring S2_0 with --enable- > ftwl fails both with and without it. The last messages are: > > checking for unistd.h... yes > configure: error: bad value yes for --enable-ftwl Try --enable-ftwl=x11 or --enable-ftwl=sdl Please test also 'make dist' when ftwl is *not* selected as client at configure time. 'make dist' should make full tarball, no matter the configure time selections. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
