Re: [Freeciv-Dev] (PR#40167) Client crash on scenario load
http://bugs.freeciv.org/Ticket/Display.html?id=40167 >
2008/3/29 Marko Lindqvist:
>
> On 24/03/2008, Marko Lindqvist wrote:
>>
>> With #40166 fixing server crash, scenario load now ends to client
>> crash.
>
> Actually, this is not limited to scenario load. Same happens quite
> often for any savegame load. (scenario load crashes always, otherwise
> I don't know exact limitations to reproducibility) Loading savegame
> via commandline parameter "-f" - or otherwise before client connects -
> might be required for crash to happen.
After long debugging sessions I found out reason for guaranteed scenario crash.
Scenario games miss thawing of tile send, meaning that no tiles is
ever (not even for another game) sent from server after scenario load.
Fix attached.
- ML
diff -Nurd -X.diff_ignore freeciv/server/savegame.c freeciv/server/savegame.c
--- freeciv/server/savegame.c 2008-06-11 00:33:46.0 +0300
+++ freeciv/server/savegame.c 2008-06-16 07:23:50.0 +0300
@@ -223,6 +223,8 @@
static void set_savegame_special(bv_special *specials,
char ch, const enum tile_special_type *index);
+static void game_load_internal(struct section_file *file);
+
/***
This returns an ascii hex value of the given half-byte of the binary
integer. See ascii_hex2bin().
@@ -3746,6 +3748,20 @@
***/
void game_load(struct section_file *file)
{
+ bool was_send_city_suppressed = send_city_suppression(TRUE);
+ bool was_send_tile_suppressed = send_tile_suppression(TRUE);
+
+ game_load_internal(file);
+
+ send_tile_suppression(was_send_tile_suppressed);
+ send_city_suppression(was_send_city_suppressed);
+}
+
+/***
+ Real game_load function.
+***/
+static void game_load_internal(struct section_file *file)
+{
int i, k;
enum server_states tmp_server_state;
RANDOM_STATE rstate;
@@ -3753,8 +3769,6 @@
int improvement_order_size = 0;
int technology_order_size = 0;
int civstyle = 0;
- bool was_send_city_suppressed = send_city_suppression(TRUE);
- bool was_send_tile_suppressed = send_tile_suppression(TRUE);
char **improvement_order = NULL;
char **technology_order = NULL;
enum tile_special_type *special_order = NULL;
@@ -4437,9 +4451,6 @@
if (!game.info.is_new_game) {
set_myrand_state(rstate);
}
-
- send_tile_suppression(was_send_tile_suppressed);
- send_city_suppression(was_send_city_suppressed);
}
/***
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40283) [Patch] Skip base specials in tile_special_type_iterate
http://bugs.freeciv.org/Ticket/Display.html?id=40283 > > [EMAIL PROTECTED] - Sun Jun 15 23:02:28 2008]: > > 2008/6/16 Madeline Book: > > I have also written the code with the future feature > > of more than one base type being allowed per tile in > > mind. This should be possible (since indeed it was > > allowed to have a fortress and an airbase on the same > > tile before), but I will start a new ticket for this > > issue later. > > You mean that since they have been stored as separate bits (and not > as id number), it would have been possible to have them independently > in same tile. I don't think it has ever been really possible for > player. Fortress and airbase have replaced each other. I think this is > correct behavior. Do you have some good use-case where multiple bases > should exist in same tile? In warserver (i.e. 2.0) games it sometimes happens that a city on one island is 11 tiles (real distance) from a city on another island and there is only one tile beside the first city that is 10 tiles away from the second city. Now the player would like the send fighters between the two cities (either to attack or to transfer them somewhere) or paradrop, both of which are limited to 10 tiles away. The usual trick in that case is to build a fortress+airbase on the tile that is 10 tiles away and have some defenders protect the fighters there. This is much faster and safer than say using some transport+engineers to terraform ocean into land and build a city 9 tiles away. It doesn't happen often, but it does happen. Anyway I'm sure many players would cry if they found out that suddenly you are not allowed to build a fortress and an airbase on the same tile. ;) > Note that even with just one base/tile main reason I have not pushed > gen-base code in faster is memory and disk space (savegame) usage. > There will be player num (FoW, what players believe)) + 1 (truth) base > maps. If you allow multiple bases in the same tile, you need one > bit/tile/basetype. With just one base/tile you can have > 2^(bits/tile)-1 base types. I even consider adding just one more > base type in next version by using those specials bits we have > been using until now. Let's assume there can be a maximum of 8 base types. Taking the worst possible case of a 256x256 tile map with 32 players in it means we have 33 maps of 65536 tiles or 2162688 tiles total for the server to keep track of (or to be stored in the savegame). Now if we allowed multiple base types on the same tile we need a byte (8 bits) per tile to keep track of which bases are on a tile, giving 2162688 total bytes used to keep track of this information. If we allow only one base type per tile at a time, then we need 3 bits per tile (lg(8)), or 811008 bytes total. So in the worst possible case for our 8 base types of which only one type can exist at a tile at a time, the server saves not more than one and a half megabytes of memory. I would think that this would be a very small portion compared to its total memory use (which, for example in the worst case above, would probably be a few 100 megabytes). As for savegames, the saving would probably be a bit more considering that the data is saved in a human editable format. But I assume a server would also have much more disk space (at least compared to RAM) and that the savegames would be compressed. So the saving is not that useful in the first place. Therefore, in my opinion, the advantages due to space savings and the configurability of base types does not out-weigh the disadvantage of losing a gameplay ability (which from the vast majority of users' points of view would look like it was removed for no obvious reason). But there is a somewhat deeper problem that I have noticed now; if we were to decide that multiple base types were allowed to exist on a tile at the same time, then something would need to be done about S_PILLAGE_BASE and related code. We would need a new mechanism to encode the "activity target" in the pillage activity both as entered in the client and handled at the server. :( Finally, for far, far future considerations, if ever specials are generalized to be fully loaded from rulesets, I assume that military bases could be merged into this ruleset type. Then since most special types can coexist on a tile, we would once again have multiple base types allowed on a tile at the same time. -- ちょっと長くなりましたね。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40254) [PATCH] Cancel AI mode when attaching to aifill player.
http://bugs.freeciv.org/Ticket/Display.html?id=40254 >
2008/6/5 Marko Lindqvist:
> 2008/5/30 Madeline Book:
>>
>> When a user connected to a server with some
>> AI players created by aifill, they were attached
>> to an existing AI player but AI mode was not
>> reset. So when the game started the player's
>> units moved on their own. This patch fixes that
>> problem by cancelling AI mode in the attached
>> player if AI mode is on and the server is in
>> the pregame state.
>
> I looked this problem too when I were working with the connectdialog
> problems (still unsure what to do with the remaining patch I have)
Now I can post it here. This requires send_chat_printf() patch from #40284.
- ML
diff -Nurd -X.diff_ignore freeciv/client/gui-gtk-2.0/pages.c freeciv/client/gui-gtk-2.0/pages.c
--- freeciv/client/gui-gtk-2.0/pages.c 2008-06-16 05:00:22.0 +0300
+++ freeciv/client/gui-gtk-2.0/pages.c 2008-06-16 05:00:35.0 +0300
@@ -1000,14 +1000,23 @@
static void take_callback(GtkWidget *w, gpointer data)
{
if (NULL != client.conn.playing) {
-if (!client.conn.playing->ai.control) {
- /* Make sure player reverts to AI control. This is much more neat,
- * and hides the ugly double username in the name list because
- * the player username equals the connection username. */
- send_chat_printf("/aitoggle \"%s\"", player_name(client.conn.playing));
+const char *name = player_name(client.conn.playing);
+
+if (client_is_observer()) {
+ if (client.conn.playing->ai.control) {
+send_chat_printf("/aitoggle \"%s\"", name);
+ }
+ send_chat_printf("/take \"%s\"", name);
+} else {
+ if (!client.conn.playing->ai.control) {
+/* Make sure player reverts to AI control. This is much more neat,
+ * and hides the ugly double username in the name list because
+ * the player username equals the connection username. */
+send_chat_printf("/aitoggle \"%s\"", name);
+ }
+ send_chat("/detach");
+ send_chat("/observe");
}
-send_chat("/detach");
-send_chat("/observe");
} else if (!client.conn.observer) {
send_chat("/observe");
} else {
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40234) [Patch] Start button sensitivity
http://bugs.freeciv.org/Ticket/Display.html?id=40234 >
2008/5/8 Marko Lindqvist:
>
> 2008/5/8 Madeline Book:
>>
>> > [cazfi - Wed May 07 21:59:32 2008]:
>> >
>> > GTK-2
>> >
>> > Current Start button sensitivity checks against global observer, but
>> > observer attached to player cannot start game either.
>>
>> The start button should also not be sensitive for detached
>> connections (not observer and not attached to a player).
>
> Fixed that one.
>
> I also found out that "Pick Nation" is sometimes used to create new
> player (without nations selection) and sometimes to select nation for
> existing player. Now button text changes accordingly.
> Sensitivity of the "Take Player"/"Pick Nation" adjusted fixing two bugs:
> - "Pick Nation" is not sensitive for observers.* (S2_1 only, as in
> S2_2 and TRUNK observer seems to have full control over nation
> selection...)
> - "Take Player" is always available for detached connections
- Updated S2_2/TRUNK version that uses new client_has_player() -function.
- ML
diff -Nurd -X.diff_ignore freeciv/client/civclient.c freeciv/client/civclient.c
--- freeciv/client/civclient.c 2008-06-16 01:02:16.0 +0300
+++ freeciv/client/civclient.c 2008-06-16 04:49:56.0 +0300
@@ -741,14 +741,22 @@
}
/**
- Returns TRUE if the client can issue orders (such as giving unit
+ Returns TRUE iff the client can control player.
+**/
+bool can_client_control(void)
+{
+ return (NULL != client.conn.playing
+ && !client_is_observer());
+}
+
+/**
+ Returns TRUE iff the client can issue orders (such as giving unit
commands). This function should be called each time before allowing the
user to give an order.
**/
bool can_client_issue_orders(void)
{
- return (NULL != client.conn.playing
- && !client_is_observer()
+ return (can_client_control()
&& C_S_RUNNING == client_state());
}
diff -Nurd -X.diff_ignore freeciv/client/civclient.h freeciv/client/civclient.h
--- freeciv/client/civclient.h 2008-06-16 01:02:16.0 +0300
+++ freeciv/client/civclient.h 2008-06-16 04:49:56.0 +0300
@@ -81,6 +81,7 @@
void set_seconds_to_turndone(double seconds);
int get_seconds_to_turndone(void);
double real_timer_callback(void);
+bool can_client_control(void);
bool can_client_issue_orders(void);
bool can_client_change_view(void);
bool can_meet_with_player(const struct player *pplayer);
diff -Nurd -X.diff_ignore freeciv/client/gui-gtk-2.0/gui_main.c freeciv/client/gui-gtk-2.0/gui_main.c
--- freeciv/client/gui-gtk-2.0/gui_main.c 2008-06-16 01:02:16.0 +0300
+++ freeciv/client/gui-gtk-2.0/gui_main.c 2008-06-16 04:51:35.0 +0300
@@ -1586,14 +1586,25 @@
} else {
gtk_stockbutton_set_label(ready_button, _("_Start"));
}
- gtk_widget_set_sensitive(ready_button, (NULL != client.conn.playing));
- gtk_stockbutton_set_label(nation_button, _("Pick _Nation"));
- if (NULL == client.conn.playing) {
+ /* Sensitive only if client can control player */
+ gtk_widget_set_sensitive(ready_button, can_client_control());
+
+ if (!client_has_player()) {
+/* Nation button will attach to player */
+gtk_stockbutton_set_label(nation_button, _("_Take Player"));
+gtk_widget_set_sensitive(nation_button, TRUE);
+ } else {
+/* Nation button will go to Nation selection */
+gtk_stockbutton_set_label(nation_button, _("Pick _Nation"));
+
+/* Sensitive iff client can select nation.
+ * FIXME: Observer can always select nations? */
gtk_widget_set_sensitive(nation_button, game.info.is_new_game);
+ /* && can_client_control()); */
}
- if (NULL != client.conn.playing || !client.conn.observer) {
+ if (!client_is_observer()) {
gtk_stockbutton_set_label(take_button, _("_Observe"));
} else {
gtk_stockbutton_set_label(take_button, _("Do not _observe"));
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40280) [Patch] Renamed player_invention_is_ready
http://bugs.freeciv.org/Ticket/Display.html?id=40280 > 2008/6/15 Madeline Book: > > This gave me another idea along the same lines: PREREQS_KNOWN. I were worried this would turn out too long, but in the end I'm quite happy with it. In addition to this change, I moved word "GOAL" before modifier "PREREQS_KNOWN" or "UNKNOWN" in reqtree parts. > It could also apply to player_invention_reachable() making it > bool player_invention_prereqs_known(player, tech). There 'reachable' = 'ever reachable'. - ML PlayerInventionReachable_40280-2.diff.bz2 Description: BZip2 compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40285) [Patch] log_set_callback() returns old callback
http://bugs.freeciv.org/Ticket/Display.html?id=40285 >
$subject
Minor change to make it easier to add extra debug functionality; to
chain log callbacks.
My public server uses this to attach handler to store backtraces
about all LOG_FATAL and LOG_ERROR messages.
- ML
diff -Nurd -X.diff_ignore freeciv/utility/log.c freeciv/utility/log.c
--- freeciv/utility/log.c 2007-11-28 02:28:14.0 +0200
+++ freeciv/utility/log.c 2008-05-08 15:18:56.0 +0300
@@ -203,9 +203,13 @@
/**
Adjust the callback function after initial log_init().
**/
-void log_set_callback(log_callback_fn callback)
+log_callback_fn log_set_callback(log_callback_fn callback)
{
- log_callback=callback;
+ log_callback_fn old = log_callback;
+
+ log_callback = callback;
+
+ return old;
}
/**
diff -Nurd -X.diff_ignore freeciv/utility/log.h freeciv/utility/log.h
--- freeciv/utility/log.h 2007-03-05 19:13:42.0 +0200
+++ freeciv/utility/log.h 2008-05-08 15:19:11.0 +0300
@@ -55,7 +55,7 @@
void log_init(const char *filename, int initial_level,
log_callback_fn callback);
void log_set_level(int level);
-void log_set_callback(log_callback_fn callback);
+log_callback_fn log_set_callback(log_callback_fn callback);
void real_freelog(int level, const char *message, ...)
fc__attribute((__format__ (__printf__, 2, 3)));
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40278) [Patch] Dangerous danger tweaking
http://bugs.freeciv.org/Ticket/Display.html?id=40278 >
2008/6/15 Marko Lindqvist:
>
> Cleanup to function providing us "dangerous danger" -logmessages,
> assess_danger()
>
> - Danger is always positive in this function. Made danger counter
> unsigned to make one more bit usable
> - Moved overflow avoidance before overflow may cause its nasty effects
> - Added comments
> - Named danger types (enum) instead of numerical constants 0-5
> - Changed Wall value assessing to consider only land-thread not ignoring
> walls
- Last one was bad change. Reverted
- Fixed very unlikely division by zero crash
- ML
diff -Nurd -X.diff_ignore freeciv/ai/advmilitary.c freeciv/ai/advmilitary.c
--- freeciv/ai/advmilitary.c 2008-02-04 08:53:36.0 +0200
+++ freeciv/ai/advmilitary.c 2008-06-16 02:54:27.0 +0300
@@ -431,7 +431,7 @@
that can whack us, so let's build something that can defend against
him. If danger is urgent and overwhelming, danger is 200+, if it is
only overwhelming, set it depending on danger. If it is underwhelming,
- set it to 100 pluss urgency.
+ set it to 100 plus urgency.
This algorithm is very strange. But I created it by nesting up
Syela's convoluted if ... else logic, and it seems to work. -- Per
@@ -473,11 +473,23 @@
FIXME: Due to the nature of assess_distance, a city will only be
afraid of a boat laden with enemies if it stands on the coast (i.e.
is directly reachable by this boat).
+
+ FIXME: CPU cycles are spent to determine all danger types, but
+ only DANGER_WALL and DANGER_LAND are ever used.
***/
+enum danger_type {
+ DANGER_ALL, /* All but nuclear danger */
+ DANGER_LAND, /* Land danger that can be countered with Walls */
+ DANGER_SEA,
+ DANGER_AIR,
+ DANGER_NUKE,
+ DANGER_LAST };
+
static unsigned int assess_danger(struct city *pcity)
{
int i;
- int danger[5], defender;
+ unsigned int danger[DANGER_LAST];
+ int defender;
struct player *pplayer = city_owner(pcity);
bool pikemen = FALSE;
unsigned int urgency = 0;
@@ -570,20 +582,23 @@
vulnerability *= vulnerability; /* positive feedback */
if (!igwall) {
-danger[1] += vulnerability * move_rate / MAX(dist, 1); /* walls */
+/* walls */
+danger[DANGER_LAND] += vulnerability * move_rate / MAX(dist, 1);
} else if (is_sailing_unit(punit)) {
-danger[2] += vulnerability * move_rate / MAX(dist, 1); /* coastal */
+/* coastal */
+danger[DANGER_SEA] += vulnerability * move_rate / MAX(dist, 1);
} else if (is_air_unit(punit) && !unit_has_type_flag(punit, F_NUCLEAR)) {
-danger[3] += vulnerability * move_rate / MAX(dist, 1); /* SAM */
+/* SAM */
+danger[DANGER_AIR] += vulnerability * move_rate / MAX(dist, 1);
}
if (uclass_has_flag(unit_class(punit), UCF_MISSILE)) {
/* SDI */
-danger[4] += vulnerability * move_rate / MAX(move_rate, dist);
+danger[DANGER_NUKE] += vulnerability * move_rate / MAX(move_rate, dist);
}
if (!unit_has_type_flag(punit, F_NUCLEAR)) {
/* only SDI helps against NUCLEAR */
vulnerability = dangerfunct(vulnerability, move_rate, dist);
-danger[0] += vulnerability;
+danger[DANGER_ALL] += vulnerability;
if (igwall) {
igwall_threat += vulnerability;
}
@@ -591,23 +606,27 @@
} unit_list_iterate_end;
} players_iterate_end;
- if (igwall_threat == 0) {
-pcity->ai.wallvalue = 90;
- } else {
-pcity->ai.wallvalue = (danger[0] * 9 - igwall_threat * 8)
- * 10 / (danger[0]);
- }
-
/* Watch out for integer overflows */
- for (i = 0; i < 5; i++) {
-if (danger[i] < 0 || danger[i] > 1<<24) {
+ for (i = 0; i < DANGER_LAST; i++) {
+if (danger[i] < 0 || danger[i] > 1 << 25) {
/* I hope never to see this! */
freelog(LOG_ERROR, "Dangerous danger[%d] (%d) in %s. Beware of "
"overflow.", i, danger[i], city_name(pcity));
- danger[i] = danger[i]>>2; /* reduce danger of overflow */
+ danger[i] = danger[i] >> 2; /* reduce probability of overflow */
}
}
+ if (igwall_threat == 0) {
+pcity->ai.wallvalue = 90;
+ } else if (danger[DANGER_ALL]) {
+pcity->ai.wallvalue = (danger[DANGER_ALL] * 9 - igwall_threat * 8)
+ * 10 / (danger[DANGER_ALL]);
+ } else {
+/* No danger.
+ * This is half of the wallvalue of what danger 1 would produce. */
+pcity->ai.wallvalue = 5;
+ }
+
if (pcity->ai.grave_danger != 0) {
/* really, REALLY urgent to defend */
urgency += 10;
@@ -615,20 +634,22 @@
/* HACK: This needs changing if multiple improvements provide
* this effect. */
+ /* FIXME: Check attacker type and protect against that. Now
+ * always assess land danger and builds any defend bonus as result. */
defender = ai_find_source_building(pplayer, E
[Freeciv-Dev] (PR#40284) [Patch] send_chat_printf()
http://bugs.freeciv.org/Ticket/Display.html?id=40284 >
This patch adds function send_chat_printf() for handling building of
messages. Used where appropriate (saves about 50 lines of code)
- ML
diff -Nurd -X.diff_ignore freeciv/client/chatline_common.c
freeciv/client/chatline_common.c
--- freeciv/client/chatline_common.c2008-03-08 16:13:03.0 +0200
+++ freeciv/client/chatline_common.c2008-06-16 00:58:37.0 +0300
@@ -67,6 +67,24 @@
dsend_packet_chat_msg_req(&client.conn, message);
}
+/**
+ Send the message as a chat to the server. Message is constructed
+ in printf style.
+**/
+void send_chat_printf(const char *format, ...)
+{
+ char msg[50];
+ int maxlen = sizeof(msg);
+
+ va_list ap;
+ va_start(ap, format);
+ my_vsnprintf(msg, maxlen, format, ap);
+ msg[maxlen] = '\0'; /* Make sure there is always ending zero */
+ send_chat(msg);
+ va_end(ap);
+}
+
+
static int frozen_level = 0;
/**
diff -Nurd -X.diff_ignore freeciv/client/chatline_common.h
freeciv/client/chatline_common.h
--- freeciv/client/chatline_common.h2008-02-04 08:53:36.0 +0200
+++ freeciv/client/chatline_common.h2008-06-16 00:58:37.0 +0300
@@ -16,6 +16,8 @@
#include "shared.h"/* bool type */
void send_chat(const char *message);
+void send_chat_printf(const char *format, ...)
+ fc__attribute((__format__ (__printf__, 1, 2)));
void chatline_common_init(void);
void chatline_common_done(void);
diff -Nurd -X.diff_ignore freeciv/client/connectdlg_common.c
freeciv/client/connectdlg_common.c
--- freeciv/client/connectdlg_common.c 2008-03-08 16:13:03.0 +0200
+++ freeciv/client/connectdlg_common.c 2008-06-16 01:38:46.0 +0300
@@ -183,7 +183,7 @@
#if !defined(HAVE_WORKING_FORK) && !defined(WIN32_NATIVE)
/* Can't do much without fork */
return FALSE;
-#else
+#else /* HAVE_WORKING_FORK || WIN32_NATIVE */
char buf[512];
int connect_tries = 0;
# ifdef WIN32_NATIVE
@@ -196,7 +196,7 @@
char cmdline3[512];
char logcmdline[512];
char scriptcmdline[512];
-# endif
+# endif /* WIN32_NATIVE */
/* only one server (forked from this client) shall be running at a time */
/* This also resets client_has_hack. */
@@ -275,7 +275,7 @@
* Calling exit here is dangerous due to X11 problems (async replies) */
_exit(1);
}
-# else
+# else /* HAVE_WORKING_FORK */
# ifdef WIN32_NATIVE
if (logfile) {
loghandle = CreateFile(logfile, GENERIC_WRITE,
@@ -326,8 +326,8 @@
server_process = pi.hProcess;
-# endif
-# endif
+# endif /* WIN32_NATIVE */
+# endif /* HAVE_WORKING_FORK */
/* a reasonable number of tries */
while (connect_to_server(user_name, "localhost", internal_server_port,
@@ -338,8 +338,8 @@
if (waitpid(server_pid, NULL, WNOHANG) != 0) {
break;
}
-#endif
-#endif
+#endif /* WIN32_NATIVE */
+#endif /* HAVE_WORKING_FORK */
if (connect_tries++ > NUMBER_OF_TRIES) {
break;
}
@@ -373,16 +373,15 @@
* has sufficient permissions to do so (it doesn't have HACK access yet) it
* is safe enough. Note that if you load a savegame the topology will be
* set but then overwritten during the load. */
- my_snprintf(buf, sizeof(buf), "/set topology %d",
- (TF_WRAPX
- | ((tileset_is_isometric(tileset)
- && tileset_hex_height(tileset) == 0) ? TF_ISO : 0)
- | ((tileset_hex_width(tileset) != 0
- || tileset_hex_height(tileset) != 0) ? TF_HEX : 0)));
- send_chat(buf);
+ send_chat_printf("/set topology %d",
+ (TF_WRAPX
+| ((tileset_is_isometric(tileset)
+&& tileset_hex_height(tileset) == 0) ? TF_ISO : 0)
+| ((tileset_hex_width(tileset) != 0
+|| tileset_hex_height(tileset) != 0) ? TF_HEX : 0)));
return TRUE;
-#endif
+#endif /* HAVE_WORKING_FORK || WIN32_NATIVE */
}
/*
@@ -488,13 +487,9 @@
*/
void send_start_saved_game(void)
{
- char buf[MAX_LEN_MSG];
-
send_chat("/set timeout 0");
send_chat("/set autotoggle 1");
- my_snprintf(buf, sizeof(buf), "/take \"%s\" \"%s\"",
- user_name, leader_name);
- send_chat(buf);
+ send_chat_printf("/take \"%s\" \"%s\"", user_name, leader_name);
send_chat("/start");
}
@@ -503,15 +498,11 @@
*/
void send_save_game(char *filename)
{
- char message[MAX_LEN_MSG];
-
if (filename) {
-my_snprintf(message, MAX_LEN_MSG, "/save %s", filename);
+send_chat_printf("/save %s", filename);
} else {
-my_snprint
Re: [Freeciv-Dev] (PR#40283) [Patch] Skip base specials in tile_special_type_iterate
http://bugs.freeciv.org/Ticket/Display.html?id=40283 > 2008/6/16 Madeline Book: > I have also written the code with the future feature > of more than one base type being allowed per tile in > mind. This should be possible (since indeed it was > allowed to have a fortress and an airbase on the same > tile before), but I will start a new ticket for this > issue later. You mean that since they have been stored as separate bits (and not as id number), it would have been possible to have them independently in same tile. I don't think it has ever been really possible for player. Fortress and airbase have replaced each other. I think this is correct behavior. Do you have some good use-case where multiple bases should exist in same tile? Note that even with just one base/tile main reason I have not pushed gen-base code in faster is memory and disk space (savegame) usage. There will be player num (FoW, what players believe)) + 1 (truth) base maps. If you allow multiple bases in the same tile, you need one bit/tile/basetype. With just one base/tile you can have 2^(bits/tile)-1 base types. I even consider adding just one more base type in next version by using those specials bits we have been using until now. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40283) [Patch] Skip base specials in tile_special_type_iterate
http://bugs.freeciv.org/Ticket/Display.html?id=40283 >
Attached patch makes tile_special_type_iterate skip
over S_FORTRESS and S_AIRBASE in order to facilitate
the transition of base types out of specials (as
mentioned in PR#40184).
Any code that depended on the base special values
being in the iteration has also been updated; there
should be no change in behaviour if I have not made
any mistakes.
In the future when bases really are removed from
enum tile_special_type, all of the added base/special
transition code can be made inert by simply having
base_get_tile_special_type always return S_LAST.
I have also written the code with the future feature
of more than one base type being allowed per tile in
mind. This should be possible (since indeed it was
allowed to have a fortress and an airbase on the same
tile before), but I will start a new ticket for this
issue later.
--
よろしくやるのは気持ちいいですね
diff --git a/client/packhand.c b/client/packhand.c
index c97bc71..9a900fe 100644
--- a/client/packhand.c
+++ b/client/packhand.c
@@ -2242,6 +2242,24 @@ void handle_tile_info(struct packet_tile_info *packet)
}
} tile_special_type_iterate_end;
+ base_type_iterate(pbase) {
+int spe = base_get_tile_special_type(pbase);
+if (!(0 <= spe && spe < S_LAST)) {
+ continue;
+}
+if (packet->special[spe]) {
+ if (!tile_has_base(ptile, pbase)) {
+tile_add_base(ptile, pbase);
+tile_changed = TRUE;
+ }
+} else {
+ if (tile_has_base(ptile, pbase)) {
+tile_remove_base(ptile, pbase);
+tile_changed = TRUE;
+ }
+}
+ } base_type_iterate_end;
+
tile_changed = tile_changed || (tile_resource(ptile) != presource);
/* always called after setting terrain */
diff --git a/common/base.c b/common/base.c
index 884bd22..bb3f8e0 100644
--- a/common/base.c
+++ b/common/base.c
@@ -265,3 +265,29 @@ struct base_type *get_base_by_gui_type(enum base_gui_type type,
return NULL;
}
+
+/**
+ Returns the value from enum tile_special_type that corresponds to this
+ base type or S_LAST if no such value exists.
+
+ NB: This function should only be used temporarily while the old "special"
+ base code is transitioned to the new generalized bases. Once S_FORTRESS
+ and S_AIRBASE are removed from specials, this function should also be
+ removed.
+**/
+int base_get_tile_special_type(const struct base_type *pbase)
+{
+ if (!pbase) {
+return S_LAST;
+ }
+
+ if (base_number(pbase) == BASE_FORTRESS) {
+return S_FORTRESS;
+ }
+
+ if (base_number(pbase) == BASE_AIRBASE) {
+return S_AIRBASE;
+ }
+
+ return S_LAST;
+}
diff --git a/common/base.h b/common/base.h
index ba38a5c..a6e5f3c 100644
--- a/common/base.h
+++ b/common/base.h
@@ -66,7 +66,11 @@ Base_type_id base_index(const struct base_type *pbase);
Base_type_id base_number(const struct base_type *pbase);
struct base_type *base_by_number(const Base_type_id id);
+
+/* Compatibility functions for the old "special"
+ * type bases which are being phased out. */
struct base_type *base_of_bv_special(bv_special spe);
+int base_get_tile_special_type(const struct base_type *pbase);
const char *base_rule_name(const struct base_type *pbase);
const char *base_name_translation(struct base_type *pbase);
diff --git a/common/terrain.c b/common/terrain.c
index d7d4e6f..eec85f5 100644
--- a/common/terrain.c
+++ b/common/terrain.c
@@ -547,6 +547,7 @@ static const char *tile_special_type_names[] =
/
enum tile_special_type find_special_by_rule_name(const char *name)
{
+ int spe;
assert(ARRAY_SIZE(tile_special_type_names) == S_LAST);
tile_special_type_iterate(i) {
@@ -555,6 +556,16 @@ enum tile_special_type find_special_by_rule_name(const char *name)
}
} tile_special_type_iterate_end;
+ base_type_iterate(pbase) {
+spe = base_get_tile_special_type(pbase);
+if (!(0 <= spe && spe < S_LAST)) {
+ continue;
+}
+if (0 == strcmp(tile_special_type_names[spe], name)) {
+ return spe;
+}
+ } base_type_iterate_end;
+
return S_LAST;
}
diff --git a/common/terrain.h b/common/terrain.h
index 7e80403..8fdfe0f 100644
--- a/common/terrain.h
+++ b/common/terrain.h
@@ -55,13 +55,19 @@ extern enum tile_special_type infrastructure_specials[];
BV_DEFINE(bv_special, S_LAST_PLUS);
-#define tile_special_type_iterate(special)\
-{ \
- enum tile_special_type special = 0; \
- for (; special < S_LAST; special++) {
-
-#define tile_special_type_iterate_end \
- } \
+/* NB: This does not include S_FORTRESS and S_AIRBASE.
+ * You must use base_type_iterate and related accessors
+ * in base.h for those. */
+#define tile_special_type_iterate(special
[Freeciv-Dev] (PR#40280) [Patch] Renamed player_invention_is_ready
http://bugs.freeciv.org/Ticket/Display.html?id=40280 > > [EMAIL PROTECTED] - Sun Jun 15 19:07:47 2008]: > > Actually, HAS_PREREQS sounds like technology that has prereqs > defined, not one that somebody has prereqs researched for. Yes that ambiguity is a little annoying. :/ > How about PREREQS_OK? This gave me another idea along the same lines: PREREQS_KNOWN. It could also apply to player_invention_reachable() making it bool player_invention_prereqs_known(player, tech). - 面白くなっています。続きましょう！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40280) [Patch] Renamed player_invention_is_ready
http://bugs.freeciv.org/Ticket/Display.html?id=40280 > > [EMAIL PROTECTED] - Sun Jun 15 14:01:02 2008]: > > Discussion about this started in #38372. > > Attached patch renames: > > TECH_REACHABLE -> TECH_PREREQS > COLOR_REQTREE_REACHABLE -> COLOR_REQTREE_PREREQS > COLOR_REQTREE_REACHABLE_GOAL -> COLOR_REQTREE_PREREQS_GOAL If the goal is to make the names more intuitive from the point of view of an English speaker, then in my opinion "HAS_PREREQS" (or maybe even "HAVE" to implicitly indicate that it is I/you/we the player that has the pre- requisites) would be a little clearer than just "PREREQS". Otherwise, I agree with the other changes and think they improve the readability especially for people reading that part of the code for the first time. -- だからいいと思います。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40280) [Patch] Renamed player_invention_is_ready
http://bugs.freeciv.org/Ticket/Display.html?id=40280 > 2008/6/15 Madeline Book: > If the goal is to make the names more intuitive from the > point of view of an English speaker, then in my opinion > "HAS_PREREQS" (or maybe even "HAVE" to implicitly > indicate that it is I/you/we the player that has the pre- > requisites) would be a little clearer than just "PREREQS". In some cases it refers to his tech, sometimes to mine. These are used both client and server side. How about PREREQS_OK? Actually, HAS_PREREQS sounds like technology that has prereqs defined, not one that somebody has prereqs researched for. As always, I very much prefer native speakers (or others speaking fluent English) to tell me how to name things. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40282) Re: Patch: CMA fix when loading saved game
http://bugs.freeciv.org/Ticket/Display.html?id=40282 >
> 2008/6/10 Patrick Smith:
>> Hi,
>>
>> The attached patch seems to fix some CMA problems when loading a saved game.
>> The city report still indicates fairly random CMA choices for cities, but
>> some messages about the governor being confused seem to have disappeared,
>> and I can now set the governor as I wish after loading a game, which wasn't
>> always possible before.
Your patch was a bit too hackish. For example, it handled only first
connection client made. If client reconnects to same or another
server, your fix was not used at all.
Based on your comments about the actual problem and its reasons, I
wrote a bit different patch. It is attached to this email. Can you
test if it fixes the problems. (This version is written against TRUNK,
I don't know if it applies cleanly to other branches)
- ML
diff -Nurd -X.diff_ignore freeciv/client/agents/cma_core.c
freeciv/client/agents/cma_core.c
--- freeciv/client/agents/cma_core.c2008-03-10 20:08:04.0 +0200
+++ freeciv/client/agents/cma_core.c2008-06-15 20:17:12.0 +0300
@@ -48,6 +48,8 @@
#include "cma_core.h"
+static bool cma_frozen;
+
/*
* The CMA is an agent. The CMA will subscribe itself to all city
* events. So if a city changes the callback function city_changed is
@@ -362,6 +364,10 @@
bool handled;
int i, city_id = pcity->id;
+ if (cma_frozen) {
+return;
+ }
+
freelog(HANDLE_CITY_LOG_LEVEL,
"handle_city(city %d=\"%s\") pos=(%d,%d) owner=%s",
pcity->id,
@@ -505,13 +511,14 @@
...
*/
bool cma_apply_result(struct city *pcity,
-const struct cm_result *const result)
+ const struct cm_result *const result)
{
assert(!cma_is_city_under_agent(pcity, NULL));
if (result->found_a_valid) {
return apply_result_on_server(pcity, result);
- } else
+ } else {
return TRUE; /* */
+ }
}
/
@@ -635,3 +642,25 @@
attr_city_set(attr, city_id, SAVED_PARAMETER_SIZE, buffer);
}
+
+/**
+ Freeze CMA not to act while cities have inconsistent state.
+**/
+void cma_freeze(void)
+{
+ cma_frozen = TRUE;
+}
+
+/**
+ Thaw CMA when cities reach consistent state.
+**/
+void cma_thaw(void)
+{
+ cma_frozen = FALSE;
+
+ cities_iterate(pcity) {
+if (cma_is_city_under_agent(pcity, NULL)) {
+ city_changed(pcity->id);
+}
+ } cities_iterate_end;
+}
diff -Nurd -X.diff_ignore freeciv/client/agents/cma_core.h
freeciv/client/agents/cma_core.h
--- freeciv/client/agents/cma_core.h2007-08-04 18:38:37.0 +0300
+++ freeciv/client/agents/cma_core.h2008-06-15 20:18:20.0 +0300
@@ -37,6 +37,10 @@
*/
void cma_init(void);
+/* Freeze cma for the time cities have inconsistent state */
+void cma_freeze(void);
+void cma_thaw(void);
+
/* Change the actual city setting. */
bool cma_apply_result(struct city *pcity,
const struct cm_result *const result);
diff -Nurd -X.diff_ignore freeciv/client/packhand.c freeciv/client/packhand.c
--- freeciv/client/packhand.c 2008-05-13 13:26:10.0 +0300
+++ freeciv/client/packhand.c 2008-06-15 20:27:01.0 +0300
@@ -18,16 +18,19 @@
#include
#include
+/* utility */
#include "capability.h"
#include "capstr.h"
-#include "events.h"
#include "fcintl.h"
+#include "log.h"
+#include "mem.h"
+
+/* common */
+#include "events.h"
#include "game.h"
#include "government.h"
#include "idex.h"
-#include "log.h"
#include "map.h"
-#include "mem.h"
#include "nation.h"
#include "packets.h"
#include "player.h"
@@ -38,7 +41,7 @@
#include "unitlist.h"
#include "worklist.h"
-#include "agents.h"
+/* client */
#include "attribute.h"
#include "audio.h"
#include "chatline_g.h"
@@ -70,6 +73,10 @@
#include "tilespec.h"
#include "wldlg_g.h"
+/* agents */
+#include "agents.h"
+#include "cma_core.h"
+
#include "packhand.h"
static void city_packet_common(struct city *pcity, struct tile *pcenter,
@@ -1061,6 +1068,9 @@
{
freelog(LOG_DEBUG, "handle_begin_turn()");
+ /* Cities are guaranteed to be in consistent state. */
+ cma_thaw();
+
/* probably duplicate insurance */
update_client_state(C_S_RUNNING);
@@ -2433,6 +2443,9 @@
{
int i;
+ /* Cities will have inconsistent state until told otherwise */
+ cma_freeze();
+
update_client_state(C_S_PREPARING);
ruleset_data_free();
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40282) Re: Patch: CMA fix when loading saved game
http://bugs.freeciv.org/Ticket/Display.html?id=40282 > Forwarding to tracker so patch is not ignored and lost. 2008/6/10 Patrick Smith: > Hi, > > The attached patch seems to fix some CMA problems when loading a saved game. > The city report still indicates fairly random CMA choices for cities, but > some messages about the governor being confused seem to have disappeared, > and I can now set the governor as I wish after loading a game, which wasn't > always possible before. Do you have instructions how to reliably reproduce the problem? It would be great if you have savegame from which this is reproducible. Of course, due to nature of the problem, this might be hard to get. It would require savegame which can be loaded ok, but would, when saved and reloaded again, produce the buggy behavior. - ML patch Description: Binary data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40281) [Patch] Fix winsock compiler warning
http://bugs.freeciv.org/Ticket/Display.html?id=40281 >
$subject
- ML
diff -Nurd -X.diff_ignore freeciv/server/sernet.c freeciv/server/sernet.c
--- freeciv/server/sernet.c 2008-05-04 16:48:09.0 +0300
+++ freeciv/server/sernet.c 2008-06-15 19:43:41.0 +0300
@@ -1127,7 +1127,11 @@
/
static void send_lanserver_response(void)
{
+#ifndef HAVE_WINSOCK
unsigned char buffer[MAX_LEN_PACKET];
+#else /* HAVE_WINSOCK */
+ char buffer[MAX_LEN_PACKET];
+#endif /* HAVE_WINSOCK */
char hostname[512];
char port[256];
char version[256];
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40280) [Patch] Renamed player_invention_is_ready
http://bugs.freeciv.org/Ticket/Display.html?id=40280 > Discussion about this started in #38372. Attached patch renames: player_invention_is_ready() -> player_invention_reachable() TECH_REACHABLE -> TECH_PREREQS COLOR_REQTREE_REACHABLE_GOAL -> COLOR_REQTREE_PREREQS_GOAL COLOR_REQTREE_UNREACHABLE_GOAL -> COLOR_REQTREE_UNKNOWN_GOAL COLOR_REQTREE_REACHABLE -> COLOR_REQTREE_PREREQS COLOR_REQTREE_UNREACHABLE -> COLOR_REQTREE_UNKNOWN and similar reqtree color changes for tilespec format and adds new reqtree color for really unreachable techs. - ML PlayerInventionReachable.diff.bz2 Description: BZip2 compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40279) [Patch] Disabled military bases
http://bugs.freeciv.org/Ticket/Display.html?id=40279 >
Current military base code requires exactly two bases defined. Civ1
ruleset should have no airbase. Currently used attempt to disable
airbase from civ1 rules does not work.
Attached patch adds 'disabled' field to military base definitions.
Disabled bases cannot be built.
- ML
diff -Nurd -X.diff_ignore freeciv/common/base.c freeciv/common/base.c
--- freeciv/common/base.c 2007-11-27 21:57:32.0 +0200
+++ freeciv/common/base.c 2008-06-15 15:13:25.0 +0300
@@ -108,6 +108,11 @@
return FALSE;
}
+ if (pbase->disabled) {
+/* Base type not in game */
+return FALSE;
+ }
+
return are_reqs_active(unit_owner(punit), NULL, NULL, ptile,
unit_type(punit), NULL, NULL, &pbase->reqs,
RPT_CERTAIN);
diff -Nurd -X.diff_ignore freeciv/common/base.h freeciv/common/base.h
--- freeciv/common/base.h 2007-08-06 16:41:57.0 +0300
+++ freeciv/common/base.h 2008-06-15 15:06:52.0 +0300
@@ -47,6 +47,7 @@
struct base_type {
Base_type_id item_number;
+ bool disabled;
struct name_translation name;
char graphic_str[MAX_LEN_NAME];
char graphic_alt[MAX_LEN_NAME];
diff -Nurd -X.diff_ignore freeciv/data/civ1/terrain.ruleset
freeciv/data/civ1/terrain.ruleset
--- freeciv/data/civ1/terrain.ruleset 2008-06-14 18:24:47.0 +0300
+++ freeciv/data/civ1/terrain.ruleset 2008-06-15 15:10:32.0 +0300
@@ -1729,6 +1729,9 @@
; [fortress] and [airbase].
;
; name= Name of the base type.
+; disabled= Not really in game. This field will be removed
+; in future versions when number of
+; bases defined is adjustable.
; graphic = tag specifing preferred graphic
; graphic_alt = tag for alternate garphic if preferred graphic is
not
; present. Can use eg "-" for no alternate graphic.
@@ -1764,12 +1767,15 @@
[airbase]
name = _("Airbase")
+disabled = 1
graphic = "base.airbase"
graphic_alt = "-"
activity_gfx = "unit.airbase"
reqs =
{ "type", "name", "range"
- "Tech", "Never", "Player"
+ "Tech", "Radio", "Player"
+ "TerrainClass", "Land", "Local"
+ "UnitFlag", "Airbase", "Local"
}
gui_type = "Airbase"
build_time = 3
diff -Nurd -X.diff_ignore freeciv/data/civ2/terrain.ruleset
freeciv/data/civ2/terrain.ruleset
--- freeciv/data/civ2/terrain.ruleset 2008-06-14 18:24:47.0 +0300
+++ freeciv/data/civ2/terrain.ruleset 2008-06-15 15:11:09.0 +0300
@@ -1766,6 +1766,9 @@
; [fortress] and [airbase].
;
; name= Name of the base type.
+; disabled= Not really in game. This field will be removed
+; in future versions when number of
+; bases defined is adjustable.
; graphic = tag specifing preferred graphic
; graphic_alt = tag for alternate garphic if preferred graphic is
not
; present. Can use eg "-" for no alternate graphic.
diff -Nurd -X.diff_ignore freeciv/data/default/terrain.ruleset
freeciv/data/default/terrain.ruleset
--- freeciv/data/default/terrain.ruleset2008-06-14 18:24:47.0
+0300
+++ freeciv/data/default/terrain.ruleset2008-06-15 15:10:41.0
+0300
@@ -1883,6 +1883,9 @@
; [fortress] and [airbase].
;
; name= Name of the base type.
+; disabled= Not really in game. This field will be removed
+; in future versions when number of
+; bases defined is adjustable.
; graphic = tag specifing preferred graphic
; graphic_alt = tag for alternate garphic if preferred graphic is
not
; present. Can use eg "-" for no alternate graphic.
diff -Nurd -X.diff_ignore freeciv/server/ruleset.c freeciv/server/ruleset.c
--- freeciv/server/ruleset.c2008-05-06 03:59:25.0 +0300
+++ freeciv/server/ruleset.c2008-06-15 15:11:47.0 +0300
@@ -1954,6 +1954,9 @@
section = "unknown";
}
+pbase->disabled = secfile_lookup_bool_default(file, FALSE,
+ "%s.disabled", section);
+
sz_strlcpy(pbase->graphic_str,
secfile_lookup_str_default(file, "-", "%s.graphic", section));
sz_strlcpy(pbase->graphic_alt,
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#38372) [Bug] AI tries to trade unreachable techs
http://bugs.freeciv.org/Ticket/Display.html?id=38372 > 2008/6/13 Marko Lindqvist: > > 2007/3/18 Marko Lindqvist: >> >> 1: Treaty: The White Horde can't have tech Asian Architecture > > Per's patch updated for S2_2. Committed to TRUNK (r14758) and S2_2 (r14759). S2_1 will wait until 2.1.5 has been released. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] 2.1.5
On Sat, 07 Jun 2008 02:47:35 +0900, Marko Lindqvist <[EMAIL PROTECTED]> wrote: > 2008/6/6 Madeline Book: >> What might be nice is to release 2.1.5 so it can be used >> for the first 2.1.x longturn game (which will probably start in a week >> or two), > > Then I suggest that we postpone 2.1.5 one week, if that's possible > for Daniel. I should have time for looking into the gcc 4.3 problem > early next week. > I'm planning to tag 2.1.5 in about 12 h (when I wake up in the morning.) ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
