Re: [Freeciv-Dev] (PR#40407) Wishlist for Freeciv
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40407 On Wed, Aug 13, 2008 at 1:01 AM, Nicolas R. Wadhwani [EMAIL PROTECTED] wrote: This get_best_defender function comes up with quite a lot of odd results that are puzzling me as a former payciv gamer, no matter if this feature here is implemented or not. For example it lets me kill non military units before any strong unit in a city if I attack with something rediculus strong like an howitzer. Once the non military units are gone and you continue attacking with the strong units it lets the howitzer sink an aircraft carrier before a marines unit which is... well just imagine if you'd read this in an history book about the battle of Iwo Jima... Maybe there should be another option letting the get_best_defender function return the strongest units of the same type (ground/naval/air) first just like the payciv city attacks were handled? The get_best_defender() function does have some odd quirks, but most of all the problem is that it does not make a difference between the case where you would lose your entire stack if the defender dies, and the case where you don't. In the former case, a tiny improvement of our chances to survive are worth risking the neck of even the most expensive unit, but in the latter case this is not so. One thing that surprises the players the most, I think, is that Settlers are often chosen to defend cities. This is because they have a huge amount of hit points compared to other early game units, and the function to pick the defender does not care that it costs a population point to lose it. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40436) Cities not refreshed when crossing Empire_Size_Step
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40436 If, during a turn, conquering or founding a city causes the empire to grow and every city to get an extra unhappy citizen due to Empire_Size_Step, it appears that the client's cities are not refreshed immediately; the unhappiness shows up when performing subsequent actions on the city, such as moving workers around or changing specialists. So those actions can appear to increase unhappiness, which is confusing. Saving, quitting, and restoring the savegame causes all cities to be up-to-date. (I think hitting turn done may have this effect also, but I haven't checked.) I guess the server needs to send city updates to client(s) when an Empire_Size_Step boundary is crossed, or something like that -- I haven't investigated the code. Seen in 2.1.4 and 2.1.6 (and one previous version I can't remember). (I idly wonder whether a message when the unhappiness penalty grows might not be a bad idea. I was rather confused why my empire was suddenly in uproar after moving from 2.0.x to 2.1.x.) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40420) Editing mode allows adding units/cities to dead player
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40420
[EMAIL PROTECTED] - Sat Aug 09 23:00:44 2008]:
Or it could bring the dead player back to life...could be desirable
for scenario editing but is a bit more work to code I'm sure.
As far as I can see, all that is needed is to set
pplayer-is_alive to TRUE, and send the player info.
At least, I observed no immediate ill effects when
I added code to do this when units or cities are
created for already dead players (patch attached).
--
信じてくれ！あの死体が動くのを自分の目で見たよ。
diff --git a/server/edithand.c b/server/edithand.c
index 6cae087..8f72fc3 100644
--- a/server/edithand.c
+++ b/server/edithand.c
@@ -429,6 +429,11 @@ void handle_edit_unit_create(struct connection *pc, int owner,
return;
}
+ if (count 0 !pplayer-is_alive) {
+pplayer-is_alive = TRUE;
+send_player_info(pplayer, NULL);
+ }
+
/* FIXME: Make this more general? */
coastal = is_sailing_unittype(punittype);
@@ -559,6 +564,11 @@ void handle_edit_city_create(struct connection *pc,
return;
}
+ if (!pplayer-is_alive) {
+pplayer-is_alive = TRUE;
+send_player_info(pplayer, NULL);
+ }
+
conn_list_do_buffer(game.est_connections);
map_show_tile(pplayer, ptile);
create_city(pplayer, ptile, city_name_suggestion(pplayer, ptile));
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40431) [Patch] SDL-client: Use get_base_by_gui_type()
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40431
2008/8/12 Marko Lindqvist:
Use get_base_by_gui_type() instead of hardcoded base type index.
- Fixed compile
- ML
diff -Nurd -X.diff_ignore freeciv/client/gui-sdl/menu.c
freeciv/client/gui-sdl/menu.c
--- freeciv/client/gui-sdl/menu.c 2008-08-13 15:42:16.0 +0300
+++ freeciv/client/gui-sdl/menu.c 2008-08-14 00:56:50.0 +0300
@@ -1005,6 +1005,7 @@
struct tile *pTile = pUnit-tile;
struct city *pCity = tile_city(pTile);
struct terrain *pTerrain = tile_terrain(pTile);
+ struct base_type *pbase;
if (!counter) {
local_show(ID_UNIT_ORDER_GOTO);
@@ -1160,7 +1161,8 @@
set_wflag(pOrder_Transform_Button, WF_HIDDEN);
}
- if (!pCity can_unit_do_activity_base(pUnit, BASE_FORTRESS)) {
+ pbase = get_base_by_gui_type(BASE_GUI_FORTRESS, pUnit, pUnit-tile);
+ if (!pCity pbase) {
local_show(ID_UNIT_ORDER_FORTRESS);
} else {
local_hide(ID_UNIT_ORDER_FORTRESS);
@@ -1172,7 +1174,8 @@
local_hide(ID_UNIT_ORDER_FORTIFY);
}
- if (!pCity can_unit_do_activity_base(pUnit, BASE_AIRBASE)) {
+ pbase = get_base_by_gui_type(BASE_GUI_AIRBASE, pUnit, pUnit-tile);
+ if (!pCity pbase) {
local_show(ID_UNIT_ORDER_AIRBASE);
} else {
local_hide(ID_UNIT_ORDER_AIRBASE);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40435) Fortress borders claiming broken
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40435
2008/8/13 Marko Lindqvist [EMAIL PROTECTED]:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40435
Border claiming code is mess. It uses vision sites on player maps and
fails to keep things in sync. Result is that players can even see
borders differently after fortress is conquered (no idea how server
side works in that case...)
Initial border claiming for new fortress seems to claim somewhat
random tiles around the fortress.
Main problem seemed to be that sites were never added to list of
vision sites to check each turn, so borders never changed from initial
value. Attached patch fixes that. Also, only visible tiles were inside
borders, leading to funny effects when units moved around (borders
moving around as units saw different tiles, to the extend that their
vision was completely separated from rest of the nation). Changed that
so that not everything inside borders need to be seen, but must be
known.
- ML
diff -Nurd -X.diff_ignore freeciv/common/vision.c freeciv/common/vision.c
--- freeciv/common/vision.c 2008-08-12 19:08:20.0 +0300
+++ freeciv/common/vision.c 2008-08-14 01:26:14.0 +0300
@@ -86,6 +86,12 @@
return;
}
assert(psite-ref_count == 0);
+
+
+ if (psite-identity 0) {
+/* This is base, not city */
+site_list_unlink(psite-owner-sites, psite);
+ }
free(psite);
}
@@ -100,6 +106,7 @@
psite-identity = identity;
psite-location = location;
psite-owner = owner;
+
return psite;
}
@@ -113,13 +120,15 @@
psite-size = pcity-size;
sz_strlcpy(psite-name, city_name(pcity));
+
return psite;
}
/
Build basic vision_site structure based on military base on tile.
/
-struct vision_site *create_vision_site_from_base(struct tile *ptile)
+struct vision_site *create_vision_site_from_base(struct tile *ptile,
+ struct player *owner)
{
struct vision_site *psite;
struct base_type *pbase;
@@ -130,11 +139,13 @@
return NULL;
}
- psite = create_vision_site(-base_number(pbase) - 1, ptile, ptile-owner);
+ psite = create_vision_site(-base_number(pbase) - 1, ptile, owner);
psite-size = 0;
psite-border_radius_sq = game.info.borders_sq;
sz_strlcpy(psite-name, base_name_translation(pbase));
+ site_list_append(owner-sites, psite);
+
return psite;
}
diff -Nurd -X.diff_ignore freeciv/common/vision.h freeciv/common/vision.h
--- freeciv/common/vision.h 2008-08-12 19:08:20.0 +0300
+++ freeciv/common/vision.h 2008-08-14 01:26:08.0 +0300
@@ -134,7 +134,8 @@
struct vision_site *create_vision_site(int identity, struct tile *location,
struct player *owner);
struct vision_site *create_vision_site_from_city(const struct city *pcity);
-struct vision_site *create_vision_site_from_base(struct tile *ptile);
+struct vision_site *create_vision_site_from_base(struct tile *ptile,
+ struct player *owner);
void update_vision_site_from_city(struct vision_site *psite,
const struct city *pcity);
void copy_vision_site(struct vision_site *dest, struct vision_site *src);
diff -Nurd -X.diff_ignore freeciv/server/maphand.c freeciv/server/maphand.c
--- freeciv/server/maphand.c2008-08-12 19:08:20.0 +0300
+++ freeciv/server/maphand.c2008-08-14 01:27:08.0 +0300
@@ -1589,7 +1589,7 @@
if (NULL != pcity) {
psite = create_vision_site_from_city(pcity);
} else {
-psite = create_vision_site_from_base(ptile);
+psite = create_vision_site_from_base(ptile, powner);
}
change_playertile_site(playsite, psite);
}
@@ -1733,7 +1733,7 @@
continue;
}
-if (!map_is_known_and_seen(dtile, powner, V_MAIN)) {
+if (!map_is_known(dtile, powner)) {
/* without city_reveal_tiles option */
continue;
}
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40356) Multiple bases on same tile
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40356 2008/7/3 Jason Dorje Short: It sounds like 1 base per tile is a lot easier to implement. Until there's a concrete need to break that barrier I wouldn't trouble yourself with generalizing it to multiple per tile. As Madeline pointed out, it should be possible to build even fortress airbase to same tile. This is actualyl more important than big number of different bases so patchset I'm currently working on uses one bit/base. Main obstacle are vision/border claiming sites, which cuurent code identifies simply by the tile they are at. I think it's acceptable for shortterm versions to make hard rule that only one such base can be in each tile. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40437) [Editor] Some more read-only tile properties
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40437
Patch adds 5 read-only tile properties: x, y, nat_x, nat_y,
and continent. Illustrates the best case of code duplication
elimination using the property editor framework. :)
--
それだけか？拡張しやすいでしょうね。
diff --git a/client/gui-gtk-2.0/editprop.c b/client/gui-gtk-2.0/editprop.c
index b32e471..e8b2c8f 100644
--- a/client/gui-gtk-2.0/editprop.c
+++ b/client/gui-gtk-2.0/editprop.c
@@ -221,6 +221,11 @@ static struct propval *propstate_get_value(struct propstate *ps);
/
enum object_property_ids {
OPID_TILE_IMAGE,
+ OPID_TILE_X,
+ OPID_TILE_Y,
+ OPID_TILE_NAT_X,
+ OPID_TILE_NAT_Y,
+ OPID_TILE_CONTINENT,
OPID_TILE_ADDRESS,
OPID_TILE_TERRAIN,
OPID_TILE_INDEX,
@@ -1101,6 +1106,21 @@ static struct propval *objbind_get_value_from_object(struct objbind *ob,
case OPID_TILE_INDEX:
pv-data.v_int = tile_index(ptile);
break;
+case OPID_TILE_X:
+ pv-data.v_int = ptile-x;
+ break;
+case OPID_TILE_Y:
+ pv-data.v_int = ptile-y;
+ break;
+case OPID_TILE_NAT_X:
+ pv-data.v_int = ptile-nat_x;
+ break;
+case OPID_TILE_NAT_Y:
+ pv-data.v_int = ptile-nat_y;
+ break;
+case OPID_TILE_CONTINENT:
+ pv-data.v_int = ptile-continent;
+ break;
case OPID_TILE_SPECIALS:
pv-data.v_bv_special = tile_specials(ptile);
break;
@@ -1994,6 +2014,11 @@ static void objprop_setup_widget(struct objprop *op)
case OPID_TILE_ADDRESS:
case OPID_TILE_INDEX:
+ case OPID_TILE_X:
+ case OPID_TILE_Y:
+ case OPID_TILE_NAT_X:
+ case OPID_TILE_NAT_Y:
+ case OPID_TILE_CONTINENT:
case OPID_TILE_TERRAIN:
case OPID_TILE_RESOURCE:
case OPID_TILE_XY:
@@ -2164,6 +2189,11 @@ static void objprop_refresh_widget(struct objprop *op,
break;
case OPID_TILE_INDEX:
+ case OPID_TILE_X:
+ case OPID_TILE_Y:
+ case OPID_TILE_NAT_X:
+ case OPID_TILE_NAT_Y:
+ case OPID_TILE_CONTINENT:
case OPID_UNIT_ID:
case OPID_CITY_ID:
label = objprop_get_child_widget(op, value-label);
@@ -2931,7 +2961,21 @@ static void property_page_setup_objprops(struct property_page *pp)
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_STRING);
ADDPROP(OPID_TILE_INDEX, _(Index),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
-ADDPROP(OPID_TILE_XY, _(X,Y),
+ADDPROP(OPID_TILE_X, Q_(?coordinate:X),
+OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
+ADDPROP(OPID_TILE_Y, Q_(?coordinate:Y),
+OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
+/* TRANS: The coordinate X in native coordinates.
+ * The freeciv coordinate system is described in doc/HACKING. */
+ADDPROP(OPID_TILE_NAT_X, _(NAT_X),
+OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
+/* TRANS: The coordinate Y in native coordinates.
+ * The freeciv coordinate system is described in doc/HACKING. */
+ADDPROP(OPID_TILE_NAT_Y, _(NAT_Y),
+OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
+ADDPROP(OPID_TILE_CONTINENT, _(Continent),
+OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
+ADDPROP(OPID_TILE_XY, Q_(?coordinates:X,Y),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_STRING);
ADDPROP(OPID_TILE_SPECIALS, _(Specials), OPF_IN_LISTVIEW
| OPF_HAS_WIDGET | OPF_EDITABLE, VALTYPE_BV_SPECIAL);
@@ -2946,7 +2990,7 @@ static void property_page_setup_objprops(struct property_page *pp)
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_STRING);
ADDPROP(OPID_UNIT_ID, _(ID),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
-ADDPROP(OPID_UNIT_XY, _(X,Y),
+ADDPROP(OPID_UNIT_XY, Q_(?coordinates:X,Y),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_STRING);
ADDPROP(OPID_UNIT_MOVES_LEFT, _(Moves Left),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET | OPF_EDITABLE, VALTYPE_INT);
@@ -2961,7 +3005,7 @@ static void property_page_setup_objprops(struct property_page *pp)
OPF_HAS_WIDGET, VALTYPE_STRING);
ADDPROP(OPID_CITY_ID, _(ID),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_INT);
-ADDPROP(OPID_CITY_XY, _(X,Y),
+ADDPROP(OPID_CITY_XY, Q_(?coordinates:X,Y),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET, VALTYPE_STRING);
ADDPROP(OPID_CITY_SIZE, _(Size),
OPF_IN_LISTVIEW | OPF_HAS_WIDGET | OPF_EDITABLE, VALTYPE_INT);
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[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#40438) [Patch] IPv6: LAN announcements
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40438
This patch adds IPv6 LAN announcement multicasting. Commandline
parameters control if LAN announcements are done using IPv4 or IPv6 or
not at all.
You need to enable IPv6 support at configure time to use this.
- ML
diff -Nurd -X.diff_ignore freeciv/client/civclient.c freeciv/client/civclient.c
--- freeciv/client/civclient.c 2008-06-24 01:37:58.0 +0300
+++ freeciv/client/civclient.c 2008-08-14 03:56:50.0 +0300
@@ -90,6 +90,7 @@
int server_port = -1;
bool auto_connect = FALSE; /* TRUE = skip Connect to Freeciv Server dialog */
bool in_ggz = FALSE;
+enum announce_type announce;
struct civclient client;
@@ -231,6 +232,8 @@
i = 1;
+ announce = ANNOUNCE_DEFAULT;
+
while (i argc) {
if (ui_separator) {
argv[1 + ui_options] = argv[i];
@@ -238,6 +241,7 @@
} else if (is_option(--help, argv[i])) {
fc_fprintf(stderr, _(Usage: %s [option ...]\n
Valid options are:\n), argv[0]);
+ fc_fprintf(stderr, _( -A, --Announce PROTO\tAnnounce game in LAN using
protocol PROTO (IPv4/IPv6/none)\n));
fc_fprintf(stderr, _( -a, --autoconnect\tSkip connect dialog\n));
#ifdef DEBUG
fc_fprintf(stderr, _( -d, --debug NUM\tSet debug log level (0 to 4,
@@ -321,6 +325,20 @@
sz_strlcpy(tileset_name, option);
free(option);
user_tileset = TRUE;
+} else if ((option = get_option_malloc(--Announce, argv, i, argc))) {
+ if (!strcasecmp(option, ipv4)) {
+announce = ANNOUNCE_IPV4;
+ } else if (!strcasecmp(option, none)) {
+announce = ANNOUNCE_NONE;
+#ifdef IPV6_SUPPORT
+ } else if(!strcasecmp(option, ipv6)) {
+announce = ANNOUNCE_IPV6;
+#endif /* IPv6 support */
+ } else {
+fc_fprintf(stderr, _(Invalid announce protocol \%s\.\n), option);
+exit(EXIT_FAILURE);
+ }
+ free(option);
} else if (is_option(--, argv[i])) {
ui_separator = TRUE;
} else {
diff -Nurd -X.diff_ignore freeciv/client/servers.c freeciv/client/servers.c
--- freeciv/client/servers.c2008-07-31 23:27:49.0 +0300
+++ freeciv/client/servers.c2008-08-14 04:14:45.0 +0300
@@ -96,6 +96,8 @@
} meta;
};
+extern enum announce_type announce;
+
/**
The server sends a stream in a registry 'ini' type format.
Read it using secfile functions and fill the server_list structs.
@@ -538,15 +540,35 @@
#else /* HAVE_WINSOCK */
char buffer[MAX_LEN_PACKET];
#endif /* HAVE_WINSOCK */
- struct ip_mreq mreq;
+ struct ip_mreq mreq4;
const char *group;
size_t size;
+ int family;
+
+#ifdef IPV6_SUPPORT
+ struct ipv6_mreq mreq6;
+#endif
+
#ifndef HAVE_WINSOCK
unsigned char ttl;
#endif
+ if (announce == ANNOUNCE_NONE) {
+/* Succeeded in doing nothing */
+return TRUE;
+ }
+
+#ifdef IPV6_SUPPORT
+ if (announce == ANNOUNCE_IPV6) {
+family = AF_INET6;
+ } else
+#endif
+ {
+family = AF_INET;
+ }
+
/* Create a socket for broadcasting to servers. */
- if ((sock = socket(AF_INET, SOCK_DGRAM, 0)) 0) {
+ if ((sock = socket(family, SOCK_DGRAM, 0)) 0) {
freelog(LOG_ERROR, socket failed: %s, mystrerror());
return FALSE;
}
@@ -557,11 +579,23 @@
}
/* Set the UDP Multicast group IP address. */
- group = get_multicast_group();
+ group = get_multicast_group(announce == ANNOUNCE_IPV6);
memset(addr, 0, sizeof(addr));
- addr.saddr_in4.sin_family = AF_INET;
- addr.saddr_in4.sin_addr.s_addr = inet_addr(get_multicast_group());
- addr.saddr_in4.sin_port = htons(SERVER_LAN_PORT);
+
+#ifndef IPV6_SUPPORT
+ {
+inet_aton(group, addr.saddr_in4.sin_addr);
+#else /* IPv6 support */
+ if (family == AF_INET6) {
+addr.saddr.sa_family = AF_INET6;
+inet_pton(AF_INET6, group, addr.saddr_in6.sin6_addr);
+addr.saddr_in6.sin6_port = htons(SERVER_LAN_PORT);
+ } else {
+inet_pton(AF_INET, group, addr.saddr_in4.sin_addr);
+#endif /* IPv6 support */
+addr.saddr.sa_family = AF_INET;
+addr.saddr_in4.sin_port = htons(SERVER_LAN_PORT);
+ }
/* this setsockopt call fails on Windows 98, so we stick with the default
* value of 1 on Windows, which should be fine in most cases */
@@ -573,7 +607,7 @@
freelog(LOG_ERROR, setsockopt failed: %s, mystrerror());
return FALSE;
}
-#endif
+#endif /* HAVE_WINSOCK */
if (setsockopt(sock, SOL_SOCKET, SO_BROADCAST, (const char*)opt,
sizeof(opt))) {
@@ -587,7 +621,7 @@
if (sendto(sock, buffer, size, 0, addr.saddr,
- sockaddr_size(addr)) 0) {
+ sockaddr_size(addr)) 0) {
/* This can happen when there's no network connection - it should
* give an in-game message. */
freelog(LOG_ERROR, lanserver scan sendto failed: %s, mystrerror());
@@ -599,7 +633,7 @@
my_closesocket(sock);
/* Create a socket for listening for server packets. */
- if ((scan-sock
