[Freeciv-Dev] changing RT user
In 1995, somebody added me to the RT users. I've changed email, and my subscription to this list was updated (last year), but it doesn't seem to have updated the RT entry. Could somebody fix it? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#14236) Error: choose_random_tech
http://bugs.freeciv.org/Ticket/Display.html?id=14236 > This can probably be closed. The message is gone from the source, and all the places the function is called check for A_UNSET now. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39364) 2.1.0b4 crash on opening scenarios screen
http://bugs.freeciv.org/Ticket/Display.html?id=39364 > Recently compiled on iMacG5 with MacOS 10.3.9 and MacPorts. export LDFLAGS="-L/opt/local/lib" export CPPFLAGS="-I/opt/local/include" export CC="gcc -no-cpp-precomp" ./configure --disable-nls --enable-client=gtk2 --prefix=/Users/wastrel/freeciv-test make ... Making all in scenario /usr/bin/gzip --best -c british-isles-85x80-v2.80.sav > british-isles-85x80-v2.80.sav.gz /usr/bin/gzip --best -c earth-160x90-v2.sav > earth-160x90-v2.sav.gz /usr/bin/gzip --best -c earth-80x50-v2.sav > earth-80x50-v2.sav.gz /usr/bin/gzip --best -c europe-200x100-v2.sav > europe-200x100-v2.sav.gz /usr/bin/gzip --best -c hagworld-120x60-v1.2.sav > hagworld-120x60-v1.2.sav.gz /usr/bin/gzip --best -c iberian-peninsula-136x100-v1.0.sav > iberian-peninsula-136x100-v1.0.sav.gz /usr/bin/gzip --best -c tutorial.sav > tutorial.sav.gz ... Invoked with ./civ, main screen, click scenario button. Reproducible. === Date/Time: 2007-05-05 14:00:03 -0400 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: civclient Path:/Users/wastrel/Projects/freeciv-2.1.0-beta4/client/civclient Version: ??? (???) PID: 1425 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x01df003c Thread 0 Crashed: 0 libSystem.B.dylib 0x90007220 strlen + 0x20 1 libglib-2.0.0.dylib 0x012e3094 g_strdup + 0x20 2 libgobject-2.0.0.dylib 0x01133524 value_collect_string + 0x40 3 libgtk-x11-2.0.0.dylib 0x0163fc78 gtk_list_store_set_valist_internal + 0x390 4 libgtk-x11-2.0.0.dylib 0x0163ff08 gtk_list_store_set_valist + 0x17c 5 libgtk-x11-2.0.0.dylib 0x0163ffd4 gtk_list_store_set + 0x4c 6 civclient 0x000b16a8 update_scenario_page + 0x12c (pages.c:1841) 7 civclient 0x000b2430 set_client_page + 0x100 (pages.c:2166) 8 civclient 0x000ad154 start_scenario_callback + 0x18 (pages.c:106) 9 libgobject-2.0.0.dylib 0x0110f964 g_closure_invoke + 0x130 10 libgobject-2.0.0.dylib 0x01124100 signal_emit_unlocked_R + 0x8e8 11 libgobject-2.0.0.dylib 0x01123374 g_signal_emit_valist + 0x760 12 libgobject-2.0.0.dylib 0x01123614 g_signal_emit + 0x28 13 libgtk-x11-2.0.0.dylib 0x015161bc gtk_button_clicked + 0xd0 14 libgtk-x11-2.0.0.dylib 0x01517d24 gtk_real_button_released + 0x6c 15 libgobject-2.0.0.dylib 0x0110f964 g_closure_invoke + 0x130 16 libgobject-2.0.0.dylib 0x01123d58 signal_emit_unlocked_R + 0x540 17 libgobject-2.0.0.dylib 0x01123374 g_signal_emit_valist + 0x760 18 libgobject-2.0.0.dylib 0x01123614 g_signal_emit + 0x28 19 libgtk-x11-2.0.0.dylib 0x015160d8 gtk_button_released + 0xd0 20 libgtk-x11-2.0.0.dylib 0x015179c8 gtk_button_button_release + 0x3c 21 libgtk-x11-2.0.0.dylib 0x01648aa8 _gtk_marshal_BOOLEAN__BOXED + 0x124 22 libgobject-2.0.0.dylib 0x0110f964 g_closure_invoke + 0x130 23 libgobject-2.0.0.dylib 0x011242e0 signal_emit_unlocked_R + 0xac8 24 libgobject-2.0.0.dylib 0x011233b4 g_signal_emit_valist + 0x7a0 25 libgobject-2.0.0.dylib 0x01123614 g_signal_emit + 0x28 26 libgtk-x11-2.0.0.dylib 0x017fe908 gtk_widget_event_internal + 0x370 27 libgtk-x11-2.0.0.dylib 0x017fe1f4 gtk_widget_event + 0x150 28 libgtk-x11-2.0.0.dylib 0x01646864 gtk_propagate_event + 0x328 29 libgtk-x11-2.0.0.dylib 0x01644bcc gtk_main_do_event + 0x49c 30 libgdk-x11-2.0.0.dylib 0x010576c4 gdk_event_dispatch + 0xc0 31 libglib-2.0.0.dylib 0x012c93c4 g_main_dispatch + 0x1ac 32 libglib-2.0.0.dylib 0x012ca724 g_main_context_dispatch + 0x98 33 libglib-2.0.0.dylib 0x012cabd4 g_main_context_iterate + 0x430 34 libglib-2.0.0.dylib 0x012cb3a8 g_main_loop_run + 0x360 35 libgtk-x11-2.0.0.dylib 0x01643d50 gtk_main + 0x140 36 civclient 0x000a77a0 ui_main + 0x4ec (gui_main.c:1361) 37 civclient 0x6c44 main + 0x788 (civclient.c:360) 38 civclient 0x1fe8 _start + 0x188 (crt.c:267) 39 dyld0x8fe1a31c _dyld_start + 0x64 PPC Thread State: srr0: 0x90007220 srr1: 0x0200f030vrsave: 0x cr: 0x28242244 xer: 0x lr: 0x012e3094 ctr: 0x90007200 r0: 0x012e3094 r1: 0xbfffe370 r2: 0x011334e4 r3: 0x01df0038 r4: 0x r5: 0xfefefeff r6: 0x80808080 r7: 0xbfffe600 r8: 0x01bc1670 r9: 0x01df003c r10: 0x r11: 0x0133659c r12: 0x90007200 r13: 0xbfffe900 r14: 0x013362e8 r15: 0x01143820 r16: 0xbfffe810 r17: 0x01b3fb50 r18: 0x013362e0 r19: 0x00561de0 r20: 0xbfffe7f8 r21: 0x007c9088 r22: 0x013362e8 r23: 0x r24: 0x0017ed6c r25: 0x01b406e0 r26: 0xbfffe640 r27: 0x01bc0f10 r28: 0x r29: 0x01bc13a0 r30: 0x01df003c r31: 0x0163f900 Binary Images Description: 0x1000 -0xe civclient ./client/civclient 0x564000 - 0x565f
[Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 > Recent (2006 May 2) MacOS compile of freeciv-2.1.0-beta4.tar.bz2. This is a very obscure error, and likely not worth fixing before release, unless a new beta is produced. It should be fixed in any subsequent 2.1.n release. Reproduce using the default.ruleset: 1. Save just before hitting a hut, or building/naming a city, or whatever. 2. Hit the hut (or whatever), and note result. 3. Quit, and load the saved game. 4. Do the same action again, and note the different result. 5. Quit, and load the saved game. 6. Do the same action again, and note the same result as the reload. 7. Repeating seems to confirm the latter result. Correctly saving/restoring the seed state is essential to testing. Note that civ1 and civ2 did not save the state, and that was a common cheat method (reload for a different result). However, civ3 does this correctly and is highly reproducible. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 >
Daniel Doran wrote:
> http://bugs.freeciv.org/Ticket/Display.html?id=39365 >
>
> I have never experienced any other behavior from Freeciv. freeciv-1.x
> versions on Win and Linux exhibited the precise behavior described.
>
"Never" is an overstatement. Turns out, the bug was introduced in the
past couple of years
in savegame.c
at player_load()
/* Add techs from game and nation, but ignore game.info.tech. */
init_tech(plr);
/* We used to call give_initial_techs here, but that shouldn't be
* necessary. The savegame should already mark those techs as known.
* give_initial_techs will crash if the nation is unset. */
That change was probably OK, but other changes conspired to cause the
problem here:
in techtools.c
at init_tech()
if (choose_goal_tech(plr) == A_UNSET) {
choose_random_tech(plr);
}
Now, I'm not sure this is a good idea. After all, this is init_tech
(called only when the server is started and when a player is loaded),
so BY DEFINITION the goal should be A_UNSET at this point!
In this case, it's about to get set from the saved game, so there is no
need to assign a random one. Only the other call (when starting the
server) needs the random tech.
Amazingly enough, this is related to my very first bug 14236 report
back in 2005!
The complete fix is to more carefully analyze how things are initialized
and used, but that's more than I'm willing to do today
===
However, the quick fix is to duplicate the rstate at the end of the load,
and that's simple enough:
--- ../savegame.c Tue Mar 20 22:22:54 2007
+++ server/savegame.c Thu May 10 13:23:39 2007
@@ -3398,6 +3398,7 @@
{
int i, k, id;
enum server_states tmp_server_state;
+ RANDOM_STATE rstate;
char *savefile_options;
const char *string;
char** improvement_order = NULL;
@@ -3799,7 +3800,6 @@
2) if it is saved. */
if (section_file_lookup(file, "random.index_J")
&& secfile_lookup_bool_default(file, TRUE, "game.save_random")) {
-RANDOM_STATE rstate;
rstate.j = secfile_lookup_int(file,"random.index_J");
rstate.k = secfile_lookup_int(file,"random.index_K");
rstate.x = secfile_lookup_int(file,"random.index_X");
@@ -3822,6 +3822,7 @@
* be needed later during the load. */
if (tmp_server_state == RUN_GAME_STATE) {
init_game_seed();
+ rstate = get_myrand_state();
}
}
@@ -4010,6 +4011,12 @@
players_iterate(pplayer) {
calc_civ_score(pplayer);
} players_iterate_end;
+
+ /* Restore saved game state, just in case various initialization code
+ * inexplicably altered the previously existing state. */
+ if (!game.info.is_new_game) {
+set_myrand_state(rstate);
+ }
}
/***
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39367) 2.1.0b4 nation trivial errors
http://bugs.freeciv.org/Ticket/Display.html?id=39367 > So, in debugging my other recent reports, I tried verbose logging, and found a fair number of things were logged. Here's a sampling, most seem to be spelling or capitalization errors. 3: Civil war nation aborigines for nation Australian not defined. 3: Civil war nation newzealand for nation British not defined. 3: Civil war nation phoenecian for nation Carthaginian not defined. 3: Civil war nation venezuelan for nation Colombian not defined. 3: Civil war nation venezuelan for nation Cuban not defined. 3: Civil war nation byzantium for nation Greek not defined. 3: Civil war nation newzealand for nation Maori not defined. 3: Civil war nation lithuaninan for nation Soviet not defined. 3: Civil war nation venezuelan for nation Spanish not defined. 3: Nation Venezuela: government Fundamentalism not found 3: Civil war nation southafrican for nation Zulu not defined. The Venezuela nation exists! 3: Unused entries in file data/default/nations.ruleset: 3: unused entry: nation_barbarian.is_observer 3: unused entry: nation_bosnia.ciwilwar_nations 3: unused entry: nation_bosnia.ciwilwar_nations,1 3: unused entry: nation_texan.conflicting_nations 3: unused entry: nation_texan.conflicting_nations,1 That's probably civil instead of ciwil! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] changing RT user
William Allen Simpson wrote: > In 1995, somebody added me to the RT users. I've changed email, and my > subscription to this list was updated (last year), but it doesn't seem to > have updated the RT entry. Could somebody fix it? > I've finally been able to login and change the password (something in the setup took time to propagate), and I've filed a few minor bug reports for 2.1.0b4. And even proposed an easy patch for one. But I'm looking at http://freeciv.wikia.com/wiki/TODO-2.1 and http://bugs.freeciv.org/Ticket/Display.html?id=12957 and trying to understand what really needs to be done to get this out the door, so that more interesting things can be added in the future releases? It's been 2 years for 2.1. Isn't it time to winnow down the list of things to finish? Many of the items listed have to do with presentation, themes, help, etc. Maybe these have always been problems, and can be put off until 2.2? I've tested by hand a couple of times up to Republic without using any automation, and reported the few errors that I've found. Most of the serious errors seem to be related to end of game features. Rather hard to test. I presume the Goto bugs are absolutely required to fix? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 > Well, the simple fix worked running only the server under gdb (just load and quit), but when the client does the load, more randomness occurs. So far, I've not been able to get the client to talk to the server under gdb. (heavy sigh) Help? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 >
Jason Dorje Short wrote:
> There is a whole sequence of tickets devoted to this bug. It is a
> well-known bug but no progress toward fixing it has been made in quite
> some time. The problem is the sequence of random calls in the reload is
> different than it was before the continuation after the game was saved.
>
I searched subjects for "random" and "seed" -- didn't find other reports,
or at least didn't seem on topic. Could we make this the master ticket?
Like was done for gotos?
> Making a log of all random calls and comparing them could help point
> toward fixes.
>
Locally, I added a LOG_VERBOSE call with line numbers; found one problem,
so far. Could be LOG_DEBUG instead, should this be added to the source?
--- rand.h Sun Feb 18 23:01:44 2007
+++ freeciv-2.1.0-beta4/utility/rand.h Thu May 10 10:43:42 2007
@@ -26,7 +26,11 @@
bool is_init;/* initially 0 for static storage */
} RANDOM_STATE;
-RANDOM_TYPE myrand(RANDOM_TYPE size);
+#define myrand(vsize) myrand_debug((vsize), "myrand", \
+__LINE__, __FILE__)
+
+RANDOM_TYPE myrand_debug(RANDOM_TYPE size,
+ const char *called_as, int line, const char *file);
void mysrand(RANDOM_TYPE seed);
bool myrand_is_init(void);
--- rand.c Sun Feb 18 23:01:44 2007
+++ freeciv-2.1.0-beta4/utility/rand.c Thu May 10 12:15:01 2007
@@ -77,13 +77,16 @@
directly representable in type RANDOM_TYPE, so we do instead:
divisor = MAX_UINT32/size
*/
-RANDOM_TYPE myrand(RANDOM_TYPE size)
+RANDOM_TYPE myrand_debug(RANDOM_TYPE size,
+const char *called_as, int line, const char *file)
{
RANDOM_TYPE new_rand, divisor, max;
int bailout = 0;
assert(rand_state.is_init);
-
+ freelog(LOG_VERBOSE, "%s(%lu) at line %d of %s",
+ called_as, (unsigned long)size, line, file);
+
if (size > 1) {
divisor = MAX_UINT32 / size;
max = size * divisor - 1;
@@ -108,7 +111,7 @@
rand_state.v[rand_state.x] = new_rand;
if (++bailout > 1) {
- freelog(LOG_ERROR, "Bailout in myrand(%u)", size);
+ freelog(LOG_ERROR, "Bailout in myrand(%lu)", (unsigned long)size);
new_rand = 0;
break;
}
@@ -180,6 +183,7 @@
void set_myrand_state(RANDOM_STATE state)
{
rand_state = state;
+ freelog(LOG_VERBOSE, "set_myrand_state");
}
/*
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 >
I ended up with even more random debugging (attached patch), and solved
the problems, or at least several of them.
Also found an uninitialized founder_boat along the way.
My solution to the problems is entirely in savegame.c, saving enough
information to handle various turn counters and such that continue
throughout the game. I presume these were just oversights by the
original coder(s).
The ai_manage_buildings initialization routine seems to need to be run
after loading the cities, I'm not sure exactly where in the restore it
belongs, so added it at the end.
Finally, (as I posted before) restoring the random pool a second time
at the very end of the load, as there are several initialization
routines that inexplicably randomize some variables -- just before the
actual values are restored from the file. Eventually, it probably
would be better to rethink them, or how those tasks are organized.
--- ../rand.h Sun Feb 18 23:01:44 2007
+++ utility/rand.h Sun May 13 07:54:52 2007
@@ -26,7 +26,11 @@
bool is_init;/* initially 0 for static storage */
} RANDOM_STATE;
-RANDOM_TYPE myrand(RANDOM_TYPE size);
+#define myrand(vsize) myrand_debug((vsize), "myrand", \
+__LINE__, __FILE__)
+
+RANDOM_TYPE myrand_debug(RANDOM_TYPE size,
+ const char *called_as, int line, const char *file);
void mysrand(RANDOM_TYPE seed);
bool myrand_is_init(void);
--- ../rand.c Sun Feb 18 23:01:44 2007
+++ utility/rand.c Sun May 13 08:56:56 2007
@@ -77,13 +77,14 @@
directly representable in type RANDOM_TYPE, so we do instead:
divisor = MAX_UINT32/size
*/
-RANDOM_TYPE myrand(RANDOM_TYPE size)
+RANDOM_TYPE myrand_debug(RANDOM_TYPE size,
+const char *called_as, int line, const char *file)
{
RANDOM_TYPE new_rand, divisor, max;
int bailout = 0;
assert(rand_state.is_init);
-
+
if (size > 1) {
divisor = MAX_UINT32 / size;
max = size * divisor - 1;
@@ -108,7 +109,8 @@
rand_state.v[rand_state.x] = new_rand;
if (++bailout > 1) {
- freelog(LOG_ERROR, "Bailout in myrand(%u)", size);
+ freelog(LOG_ERROR, "%s(%lu) = %lu bailout at line %d of %s",
+ called_as, (unsigned long)size, (unsigned long)new_rand, line,
file);
new_rand = 0;
break;
}
@@ -122,6 +124,8 @@
}
/* freelog(LOG_DEBUG, "rand(%u) = %u", size, new_rand); */
+ freelog(LOG_VERBOSE, "%s(%lu) = %lu at line %d of %s",
+ called_as, (unsigned long)size, (unsigned long)new_rand, line,
file);
return new_rand;
}
@@ -170,6 +174,16 @@
*/
RANDOM_STATE get_myrand_state(void)
{
+ int i;
+ freelog(LOG_VERBOSE, "get_myrand_state J=%d K=%d X=%d",
+rand_state.j, rand_state.k, rand_state.x);
+ for (i = 0; i < 8; i++) {
+freelog(LOG_VERBOSE, "get_myrand_state %d, %08x %08x %08x %08x %08x %08x
%08x",
+ i, rand_state.v[7 * i],
+ rand_state.v[7 * i + 1], rand_state.v[7 * i + 2],
+ rand_state.v[7 * i + 3], rand_state.v[7 * i + 4],
+ rand_state.v[7 * i + 5], rand_state.v[7 * i + 6]);
+ }
return rand_state;
}
@@ -179,7 +193,17 @@
*/
void set_myrand_state(RANDOM_STATE state)
{
+ int i;
rand_state = state;
+ freelog(LOG_VERBOSE, "set_myrand_state J=%d K=%d X=%d",
+rand_state.j, rand_state.k, rand_state.x);
+ for (i = 0; i < 8; i++) {
+freelog(LOG_VERBOSE, "set_myrand_state %d, %08x %08x %08x %08x %08x %08x
%08x",
+ i, rand_state.v[7 * i],
+ rand_state.v[7 * i + 1], rand_state.v[7 * i + 2],
+ rand_state.v[7 * i + 3], rand_state.v[7 * i + 4],
+ rand_state.v[7 * i + 5], rand_state.v[7 * i + 6]);
+ }
}
/*
--- ../city.c Tue Mar 20 22:23:07 2007
+++ common/city.c Sun May 13 15:11:33 2007
@@ -2451,6 +2451,7 @@
pcity->server.needs_arrange = FALSE;
pcity->server.vision = NULL; /* No vision. */
+ pcity->ai.founder_boat = FALSE;
pcity->ai.founder_want = 0; /* calculating this is really expensive */
pcity->ai.next_founder_want_recalc = 0; /* turns to recalc found_want */
pcity->ai.trade_want = 1; /* we always want some */
--- ../savegame.c Tue Mar 20 22:22:54 2007
+++ server/savegame.c Sun May 13 14:07:18 2007
@@ -2464,6 +2464,19 @@
pcity->ai.urgency = secfile_lookup_int_default(file, 0,
"player%d.c%d.ai.urgency", plrno, i);
+/* avoid myrand recalculations on subsequent reload. */
+pcity->ai.next_recalc = secfile_lookup_int_default(file, 0,
+ "player%d.c%d.ai.building_turn", plrno, i);
+
+/* avoid myrand and expensive recalculat
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 >
Those patches were against the 2.1.0b4 source, here's the savegame.c
patch against current revision 12954.
Untested. It compiles.
--- ../savegame.c Thu May 3 12:42:30 2007
+++ server/savegame.c Sun May 13 16:17:45 2007
@@ -2512,6 +2512,19 @@
pcity->ai.urgency = secfile_lookup_int_default(file, 0,
"player%d.c%d.ai.urgency", plrno, i);
+/* avoid myrand recalculations on subsequent reload. */
+pcity->ai.next_recalc = secfile_lookup_int_default(file, 0,
+ "player%d.c%d.ai.building_turn", plrno, i);
+
+/* avoid myrand and expensive recalculations on subsequent reload. */
+pcity->ai.next_founder_want_recalc = secfile_lookup_int_default(file, 0,
+ "player%d.c%d.ai.founder_turn", plrno, i);
+pcity->ai.founder_want = secfile_lookup_int_default(file, 0,
+ "player%d.c%d.ai.founder_want", plrno, i);
+pcity->ai.founder_boat = secfile_lookup_bool_default(file,
+ (pcity->ai.founder_want < 0),
+ "player%d.c%d.ai.founder_boat", plrno, i);
+
tile_set_city(pcity->tile, pcity);
city_list_append(plr->cities, pcity);
@@ -3254,6 +3267,18 @@
/* FIXME: remove this when the urgency is properly recalculated. */
secfile_insert_int(file, pcity->ai.urgency,
"player%d.c%d.ai.urgency", plrno, i);
+
+/* avoid myrand recalculations on subsequent reload. */
+secfile_insert_int(file, pcity->ai.next_recalc,
+ "player%d.c%d.ai.building_turn", plrno, i);
+
+/* avoid myrand and expensive recalculations on subsequent reload. */
+secfile_insert_int(file, pcity->ai.next_founder_want_recalc,
+ "player%d.c%d.ai.founder_turn", plrno, i);
+secfile_insert_int(file, pcity->ai.founder_want,
+ "player%d.c%d.ai.founder_want", plrno, i);
+secfile_insert_bool(file, pcity->ai.founder_boat,
+ "player%d.c%d.ai.founder_boat", plrno, i);
}
city_list_iterate_end;
@@ -3480,6 +3505,7 @@
{
int i, k, id;
enum server_states tmp_server_state;
+ RANDOM_STATE rstate;
char *savefile_options;
const char *string;
char** improvement_order = NULL;
@@ -3874,7 +3900,6 @@
2) if it is saved. */
if (section_file_lookup(file, "random.index_J")
&& secfile_lookup_bool_default(file, TRUE, "game.save_random")) {
-RANDOM_STATE rstate;
rstate.j = secfile_lookup_int(file,"random.index_J");
rstate.k = secfile_lookup_int(file,"random.index_K");
rstate.x = secfile_lookup_int(file,"random.index_X");
@@ -3897,6 +3922,7 @@
* be needed later during the load. */
if (tmp_server_state == RUN_GAME_STATE) {
init_game_seed();
+ rstate = get_myrand_state();
}
}
@@ -4076,6 +4102,24 @@
players_iterate(pplayer) {
calc_civ_score(pplayer);
} players_iterate_end;
+
+ /* Recalculate the potential buildings for each city.
+ * Has caused some problems with game random state. */
+ players_iterate(pplayer) {
+bool saved_ai_control = pplayer->ai.control;
+
+/* Recalculate for all players. */
+pplayer->ai.control = FALSE;
+ai_manage_buildings(pplayer);
+
+pplayer->ai.control = saved_ai_control;
+ } players_iterate_end;
+
+ /* Restore game random state, just in case various initialization code
+ * inexplicably altered the previously existing state. */
+ if (!game.info.is_new_game) {
+set_myrand_state(rstate);
+ }
}
/***
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 >
Those patches were against the 2.1.0b4 source, here's the rand.c
patch against current revision 12954, better conforming to your
recent formatting.
--- ../rand.c Sun May 13 16:05:47 2007
+++ utility/rand.c Sun May 13 16:33:20 2007
@@ -86,9 +86,6 @@
assert(rand_state.is_init);
- freelog(LOG_RAND, "%s(%lu) at line %d of %s",
- called_as, (unsigned long)size, line, file);
-
if (size > 1) {
divisor = MAX_UINT32 / size;
max = size * divisor - 1;
@@ -113,7 +110,8 @@
rand_state.v[rand_state.x] = new_rand;
if (++bailout > 1) {
- freelog(LOG_ERROR, "Bailout in myrand(%lu)", (unsigned long)size);
+ freelog(LOG_ERROR, "%s(%lu) = %lu bailout at line %d of %s",
+ called_as, (unsigned long)size, (unsigned long)new_rand, line,
file);
new_rand = 0;
break;
}
@@ -126,7 +124,8 @@
new_rand = 0;
}
- freelog(LOG_RAND, "myrand(%lu) = %lu", (unsigned long)size, (unsigned
long)new_rand);
+ freelog(LOG_RAND, "%s(%lu) = %lu at line %d of %s",
+ called_as, (unsigned long)size, (unsigned long)new_rand, line,
file);
return new_rand;
}
@@ -175,6 +174,18 @@
*/
RANDOM_STATE get_myrand_state(void)
{
+ int i;
+
+ freelog(LOG_RAND, "get_myrand_state J=%d K=%d X=%d",
+rand_state.j, rand_state.k, rand_state.x);
+ for (i = 0; i < 8; i++) {
+freelog(LOG_RAND, "get_myrand_state %d, %08x %08x %08x %08x %08x %08x
%08x",
+ i, rand_state.v[7 * i],
+ rand_state.v[7 * i + 1], rand_state.v[7 * i + 2],
+ rand_state.v[7 * i + 3], rand_state.v[7 * i + 4],
+ rand_state.v[7 * i + 5], rand_state.v[7 * i + 6]);
+ }
+
return rand_state;
}
@@ -184,8 +195,19 @@
*/
void set_myrand_state(RANDOM_STATE state)
{
- freelog(LOG_RAND, "set_myrand_state");
+ int i;
+
rand_state = state;
+
+ freelog(LOG_RAND, "set_myrand_state J=%d K=%d X=%d",
+rand_state.j, rand_state.k, rand_state.x);
+ for (i = 0; i < 8; i++) {
+freelog(LOG_RAND, "set_myrand_state %d, %08x %08x %08x %08x %08x %08x
%08x",
+ i, rand_state.v[7 * i],
+ rand_state.v[7 * i + 1], rand_state.v[7 * i + 2],
+ rand_state.v[7 * i + 3], rand_state.v[7 * i + 4],
+ rand_state.v[7 * i + 5], rand_state.v[7 * i + 6]);
+ }
}
/*
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39365) 2.1.0b4 random number seed not saved correctly
http://bugs.freeciv.org/Ticket/Display.html?id=39365 > Those patches were against the 2.1.0b4 source, here's the city.c patch against current revision 12954 (single line added). I didn't realize how much has been added since 2.1.0! Hopefully, 2.1.0 can be laid to bed soon --- ../city.c Thu May 3 12:47:50 2007 +++ common/city.c Sun May 13 16:42:24 2007 @@ -2389,6 +2389,7 @@ pcity->server.needs_arrange = FALSE; pcity->server.vision = NULL; /* No vision. */ + pcity->ai.founder_boat = FALSE; pcity->ai.founder_want = 0; /* calculating this is really expensive */ pcity->ai.next_founder_want_recalc = 0; /* turns to recalc found_want */ pcity->ai.trade_want = 1; /* we always want some */ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Ogre3D UI?
James Supancic wrote: > I am thinking about working on an Ogre3D GUI for freeciv. I've been > looking over the code in freeciv/freeciv/client/gui-* and think I > might be able to develop something nice. > This would be wonderful! I actually looked at doing it 18+ months ago, but decided it would be too much for me. It would need data support for elevations (and depths), among other things. And I'm a network protocol guy, not a game graphics guy. (I've hardly looked at the freeciv protocol, don't blame me.) > I have approximately a 3 month break from school this summer and think > that I could spend it creating a freeciv UI that I like better than > the current UIs (I like to play freeciv in a single player mode, and > prefer a UI that is attractive and enjoyable over a UI that is > effective and powerful). > When I first tried freeciv, it was to play with my brothers. They were not impressed with the UI, compared to then current civ3. Now, amplio is much nicer visually. I wish there were something better for isohex, too. Anyway, they were seduced by the lovely Civ4. And we still don't even have civ3 support ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39342) 2.1.0-beta4 border vs. fog of war
http://bugs.freeciv.org/Ticket/Display.html?id=39342 > Per I. Mathisen wrote: > Given how much FoW you usually have, this will make your real borders > really hard to visualize and plan with respect to. > > I do not really see a good and simple fix to this issue. We need to change > the way either borders or the problematic map updates are done to make > them consistent with each other. > Now, I have run into this problem, too. Here's my suggestion: 1. Foreign borders aren't "tile features" of the map, they are political. 2. When near a border with a unit, the border will appear, even when you haven't seen the city that created it. It's not the place itself, it's the workers, travelers, and minstrels that tell you about it. 3. When the border is no longer near, it should disappear after some number of turns (1 turn would be very easy to code). 4. When a long term physical asset, my city or fortress, creates a border that is adjacent, then the foreign border should persist. 5. When a foreign city changes hands, even though I don't "see" the city or know whether it has been destroyed, the border should change (as it does now). After all, the fall of a city or an entire civilization is information that is reported far and wide. We hear rumors when a Wonder is started or finished, we certainly should hear about major battles, especially as they occur next to our border. That's logically different than whether trees have been cut down, or a mine built. 50 years is a really good long time for a political rumor to travel! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39370) 2.1.0b4 city vision radius too small
http://bugs.freeciv.org/Ticket/Display.html?id=39370 > One of the nuisances (compared to the commercial games) is the limited vision radius of the city itself. When the game starts, the settler has full city X vision. As the settler travels, it has only 1 radius vision. That's fine. When the city is founded, it still has only 1 radius vision. That's wrong! The citizens are capable of traveling 2 radii to work, but not working because they don't know about the lay of the land? That makes no sense. 50 years is plenty of time for settled citizens to explore. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39372) 2.1.0b4 default cities.ruleset celebrate_size_limit mismatch ruleset.c celebratesize
http://bugs.freeciv.org/Ticket/Display.html?id=39372 > or vice versa. I think that the celebrate_size is a better name for both. Currently, the code is: /* City Parameters */ game.info.celebratesize = secfile_lookup_int_default(file, GAME_DEFAULT_CELEBRATESIZE, "parameters.celebratesize"); Need to choose one name! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39370) 2.1.0b4 city vision radius too small
http://bugs.freeciv.org/Ticket/Display.html?id=39370 >
Per I. Mathisen wrote:
> Yes. Patch to change this most welcome.
>
Apparently, it was a conscious decision by some prior developer. There
is a documented vision parameter that is only FALSE for cities.
Therefore, I propose a configurable ruleset option. Tested, works for me.
--- ../cities.ruleset Sun Feb 18 23:01:51 2007
+++ data/default/cities.ruleset Thu May 17 14:43:49 2007
@@ -60,6 +60,8 @@
;forced_luxury = 100
;forced_gold = 0
+vision_reveal_tiles = 1 ; was default zero for old savegames
+
;
; City styles define the way cities are drawn
;
--- ../citytools.c Tue Mar 20 22:22:54 2007
+++ server/citytools.c Thu May 17 13:49:28 2007
@@ -791,7 +791,7 @@
give_citymap_from_player_to_player(pcity, pgiver, ptaker);
old_vision = pcity->server.vision;
- pcity->server.vision = vision_new(ptaker, pcity->tile, FALSE);
+ pcity->server.vision = vision_new(ptaker, pcity->tile,
game.info.city_reveal_tiles);
vision_layer_iterate(v) {
vision_change_sight(pcity->server.vision, v,
vision_get_sight(old_vision, v));
@@ -974,7 +974,7 @@
}
/* Before arranging workers to show unknown land */
- pcity->server.vision = vision_new(pplayer, ptile, FALSE);
+ pcity->server.vision = vision_new(pplayer, ptile,
game.info.city_reveal_tiles);
city_refresh_vision(pcity);
tile_set_city(ptile, pcity);
--- ../packets.def Tue Mar 20 22:23:07 2007
+++ common/packets.def Thu May 17 13:25:59 2007
@@ -417,6 +417,7 @@
UINT8 allowed_city_names;
IMPROVEMENT palace_building;
IMPROVEMENT land_defend_building;
+ BOOL city_reveal_tiles;
BOOL changable_tax;
UINT8 forced_science;
UINT8 forced_luxury;
--- ../ruleset.cSun Feb 18 23:01:46 2007
+++ server/ruleset.cThu May 17 13:42:57 2007
@@ -2319,6 +2319,7 @@
game.info.angrycitizen =
secfile_lookup_bool_default(file, GAME_DEFAULT_ANGRYCITIZEN,
"parameters.angry_citizens");
+
game.info.changable_tax =
secfile_lookup_bool_default(file, TRUE, "parameters.changable_tax");
game.info.forced_science =
@@ -2332,6 +2333,10 @@
freelog(LOG_FATAL, "Forced taxes do not add up in ruleset!");
exit(EXIT_FAILURE);
}
+
+ /* old versions didn't reveal tiles */
+ game.info.city_reveal_tiles =
+secfile_lookup_bool_default(file, FALSE, "parameters.vision_reveal_tiles");
/* City Styles ... */
--- ../savegame.c Tue Mar 20 22:22:54 2007
+++ server/savegame.c Thu May 17 13:45:08 2007
@@ -2378,7 +2378,7 @@
}
/* adding the cities contribution to fog-of-war */
-pcity->server.vision = vision_new(pcity->owner, pcity->tile, FALSE);
+pcity->server.vision = vision_new(pcity->owner, pcity->tile,
game.info.city_reveal_tiles);
city_refresh_vision(pcity);
pcity->units_supported = unit_list_new();
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39342) 2.1.0-beta4 border vs. fog of war
http://bugs.freeciv.org/Ticket/Display.html?id=39342 > Per Inge Mathisen wrote: > So this is like today, only that you forget borders after a turn if > you do not see the border source? It is actually rather complicated, > and it does not answer my worry above that it will make borders hard > to visualize, due to the prevalence of FoW. > I see borders as a technique for constraining movement, rather than something to visualize. Leaving parts of old ones lying around seems more confusing to me. But, I only gave a rationale for cleaning them up. You don't seem to agree with my rationale ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39370) 2.1.0b4 city vision radius too small
http://bugs.freeciv.org/Ticket/Display.html?id=39370 >
Oh bother, I see that while I was poking at keeping things backward
compatible, you made a sweeping change. Ah well, here's my 2.1.0b4
proposal as applied to trunk Mix and match?
/*
Index: server/citytools.c
===
--- server/citytools.c (revision 12955)
+++ server/citytools.c (working copy)
@@ -792,7 +792,7 @@
give_citymap_from_player_to_player(pcity, pgiver, ptaker);
old_vision = pcity->server.vision;
- pcity->server.vision = vision_new(ptaker, pcity->tile, FALSE);
+ pcity->server.vision = vision_new(ptaker, pcity->tile,
game.info.city_reveal_tiles);
vision_layer_iterate(v) {
vision_change_sight(pcity->server.vision, v,
vision_get_sight(old_vision, v));
@@ -976,7 +976,7 @@
}
/* Before arranging workers to show unknown land */
- pcity->server.vision = vision_new(pplayer, ptile, FALSE);
+ pcity->server.vision = vision_new(pplayer, ptile,
game.info.city_reveal_tiles);
city_refresh_vision(pcity);
tile_set_city(ptile, pcity);
Index: server/ruleset.c
===
--- server/ruleset.c(revision 12955)
+++ server/ruleset.c(working copy)
@@ -2575,6 +2575,7 @@
game.info.angrycitizen =
secfile_lookup_bool_default(file, GAME_DEFAULT_ANGRYCITIZEN,
"parameters.angry_citizens");
+
game.info.changable_tax =
secfile_lookup_bool_default(file, TRUE, "parameters.changable_tax");
game.info.forced_science =
@@ -2589,6 +2590,10 @@
exit(EXIT_FAILURE);
}
+ /* old versions didn't reveal tiles */
+ game.info.city_reveal_tiles =
+secfile_lookup_bool_default(file, FALSE, "parameters.vision_reveal_tiles");
+
/* City Styles ... */
styles = secfile_get_secnames_prefix(file, "citystyle_", &nval);
Index: server/savegame.c
===
--- server/savegame.c (revision 12955)
+++ server/savegame.c (working copy)
@@ -2426,7 +2426,7 @@
}
/* adding the cities contribution to fog-of-war */
-pcity->server.vision = vision_new(pcity->owner, pcity->tile, FALSE);
+pcity->server.vision = vision_new(pcity->owner, pcity->tile,
game.info.city_reveal_tiles);
city_refresh_vision(pcity);
pcity->units_supported = unit_list_new();
/***
Index: data/default/cities.ruleset
===
--- data/default/cities.ruleset (revision 12955)
+++ data/default/cities.ruleset (working copy)
@@ -60,6 +60,8 @@
;forced_luxury = 100
;forced_gold = 0
+vision_reveal_tiles = 1 ; was default zero for old savegames
+
;
; City styles define the way cities are drawn
;
Index: common/packets.def
===
--- common/packets.def (revision 12955)
+++ common/packets.def (working copy)
@@ -425,6 +425,7 @@
UINT8 allowed_city_names;
IMPROVEMENT palace_building;
IMPROVEMENT land_defend_building;
+ BOOL city_reveal_tiles;
BOOL changable_tax;
UINT8 forced_science;
UINT8 forced_luxury;
Index: common/city.c
===
--- common/city.c (revision 12955)
+++ common/city.c (working copy)
@@ -2389,6 +2389,7 @@
pcity->server.needs_arrange = FALSE;
pcity->server.vision = NULL; /* No vision. */
+ pcity->ai.founder_boat = FALSE;
pcity->ai.founder_want = 0; /* calculating this is really expensive */
pcity->ai.next_founder_want_recalc = 0; /* turns to recalc found_want */
pcity->ai.trade_want = 1; /* we always want some */
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#8398) Re: Bug: cease-fires can't be extended
http://bugs.freeciv.org/Ticket/Display.html?id=8398 > Per I. Mathisen wrote: > I think the proper solution to this problem is that ceasefires do not > count down, but can be broken at any time by any government without penalty. > I disagree. The count down is an essential game function. And the penalty used to be important for reputation in the original games. Now, I'm uncertain about the penalty (reputation is gone?), but I'd still like to see a count. Perhaps the count value should be negotiable, just like gold value? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39372) 2.1.0b4 default cities.ruleset celebrate_size_limit mismatch ruleset.c celebratesize
http://bugs.freeciv.org/Ticket/Display.html?id=39372 > Here's the simplest possible patches for 2.1.0b4 and trunk. --- ../ruleset.cSun Feb 18 23:01:46 2007 +++ server/ruleset.cThu May 17 17:12:28 2007 @@ -2313,12 +2313,13 @@ game.info.celebratesize = secfile_lookup_int_default(file, GAME_DEFAULT_CELEBRATESIZE, - "parameters.celebratesize"); + "parameters.celebrate_size_limit"); game.info.add_to_size_limit = secfile_lookup_int_default(file, 9, "parameters.add_to_size_limit"); game.info.angrycitizen = secfile_lookup_bool_default(file, GAME_DEFAULT_ANGRYCITIZEN, "parameters.angry_citizens"); + game.info.changable_tax = secfile_lookup_bool_default(file, TRUE, "parameters.changable_tax"); game.info.forced_science = Index: server/ruleset.c === --- server/ruleset.c(revision 12955) +++ server/ruleset.c(working copy) @@ -2569,12 +2569,13 @@ game.info.celebratesize = secfile_lookup_int_default(file, GAME_DEFAULT_CELEBRATESIZE, - "parameters.celebratesize"); + "parameters.celebrate_size_limit"); game.info.add_to_size_limit = secfile_lookup_int_default(file, 9, "parameters.add_to_size_limit"); game.info.angrycitizen = secfile_lookup_bool_default(file, GAME_DEFAULT_ANGRYCITIZEN, "parameters.angry_citizens"); + game.info.changable_tax = secfile_lookup_bool_default(file, TRUE, "parameters.changable_tax"); game.info.forced_science = ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39373) abandoned city bounce
http://bugs.freeciv.org/Ticket/Display.html?id=39373 > I just had the oddest thing happen: when I created a settler (from a badly placed hut city), the settler bounced to my nearest city. That's certainly not how I remember Civ1 or Civ2 or Civ3 working! Of course, I want it to stay in place, so that I can move it over 2 places to a better site Having to move all the way back 10 moves is not wonderful. If this has been reported earlier, I'm not finding it. I do see that somebody wants the hut to become a settler instead -- a very good idea that happens in Civ3. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39367) 2.1.0b4 nation trivial errors
http://bugs.freeciv.org/Ticket/Display.html?id=39367 >
William Allen Simpson wrote:
> 3: Unused entries in file data/default/nations.ruleset:
> 3: unused entry: nation_barbarian.is_observer
> 3: unused entry: nation_bosnia.ciwilwar_nations
> 3: unused entry: nation_bosnia.ciwilwar_nations,1
> 3: unused entry: nation_texan.conflicting_nations
> 3: unused entry: nation_texan.conflicting_nations,1
>
> That's probably civil instead of ciwil!
>
Couldn't figure out what to do about is_observer. Here's the first
installment on trivial nation fixes for 2.1.0b4 and trunk.
--- ../bosnia.ruleset Sun Feb 18 23:01:53 2007
+++ data/nation/bosnia.ruleset Fri May 18 15:09:25 2007
@@ -23,6 +23,7 @@
city_style = "European"
ruler_titles = { "government", "male_title", "female_title"
+; /* TRANS: Ban = Duke */
"Despotism", _("Ban"), _("Ban")
"Monarchy",_("King"), _("Queen")
"Republic",_("President"),_("President")
@@ -34,7 +35,7 @@
init_government="Despotism"
init_units=""
-ciwilwar_nations="croatian", "serbian"
+civilwar_nations="croatian", "serbian"
cities =
"Sarajevo",
--- ../texan.rulesetSun Feb 18 23:01:53 2007
+++ data/nation/texan.ruleset Fri May 18 15:03:20 2007
@@ -4,7 +4,7 @@
plural=_("?plural:Texans")
groups="American"
legend=_("Texas is second largest and second most populous state of the\
- USA, famous for it's \"larger than life\" cowboy mentality.")
+ USA, famous for its \"larger than life\" cowboy mentality.")
leader=
"Sam Houston",
"Stephen F. Austin",
@@ -16,8 +16,8 @@
flag_alt = "usa"
city_style = "European"
ruler_titles = { "government", "male_title", "female_title"
- "Republic",_("Governor"), _("Governor")
- "Fundamentalism", _("Reverend"), _("Reverend")
+ "Republic",_("Governor"), _("?female:Governor")
+ "Fundamentalism", _("Reverend"), _("?female:Reverend")
}
init_techs=""
@@ -25,7 +25,7 @@
init_government="Despotism"
init_units=""
-conflicting_nations="american", "chilean" ; Latter because of similar flags
+conflicts_with="american", "chilean" ; Latter because of similar flags
civilwar_nations="american", "mexican"
cities =
Index: azeri.ruleset
===
--- azeri.ruleset (revision 12962)
+++ azeri.ruleset (working copy)
@@ -46,7 +46,7 @@
init_government="Despotism"
init_units=""
-conflict_with="soviet"
+conflicts_with="soviet"
civilwar_nations="turk", "persian", "armenian"
; http://de.wikipedia.org/wiki/Liste_der_Städte_in_Aserbaidschan
Index: texan.ruleset
===
--- texan.ruleset (revision 12962)
+++ texan.ruleset (working copy)
@@ -4,7 +4,7 @@
plural=_("?plural:Texans")
groups="American"
legend=_("Texas is second largest and second most populous state of the\
- USA, famous for it's \"larger than life\" cowboy mentality.")
+ USA, famous for its \"larger than life\" cowboy mentality.")
leader=
"Sam Houston",
"Stephen F. Austin",
Index: purhepecha.ruleset
===
--- purhepecha.ruleset (revision 12962)
+++ purhepecha.ruleset (working copy)
@@ -2,7 +2,7 @@
name=_("P'urhepecha")
plural=_("?plural:P'urhepecha")
-gourps="Medieval", "American"
+groups="Medieval", "American"
legend=_("The P'urhepecha are a people native to the modern Mexican state of\
Michoacan, the heart of a former empire known to them as Irechecua\
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] svn problems [was (PR#39367) 2.1.0b4 nation trivial errors]
Per Inge Mathisen wrote: > On 5/18/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: >> Here's the first installment on trivial nation fixes for 2.1.0b4 and >> trunk. > > Most of the S2_1 changes were already done (please 'svn up' before > making the patch), and the rest would invalidate the translations, > which is bad at this stage of the release process. So I just committed > the trunk patch. > Aha, of course I was making patches for the "released" 2.1.0b4 source. I'd found no prior references on this list to these specific fixes, so somebody sensibly made the trivial patches for S2_1 without telling us. === I've been trying for many hours to checkout S2_1, and got these errors: svn co svn://svn.gna.org/svn/freeciv/branches/S2_1 S2_1 svn: Malformed network data !! svn co svn://svn.gna.org/svn/freeciv/branches/S2_1 S2_1 svn: Malformed network data !! svn co svn://svn.gna.org/svn/freeciv/branches/S2_1 S2_1 svn: Malformed network data !! svn co svn://svn.gna.org/svn/freeciv/branches/S2_1 S2_1 AS2_1/m4 ... AS2_1/po svn: Connection closed unexpectedly cd S2_1 svn up Apo/cs.po ... Updated to revision 12963. svn up At revision 12963. === And just so you know it wasn't a fluke, I did it twice. The other time, it pooped out at: ... AS2_1/po/uk.po svn: Connection closed unexpectedly cd S2_1 svn up Apo/ro.po ... Updated to revision 12963. svn up svn: Malformed network data svn up svn: Malformed network data === Anyway, I'll begin testing with the S2_1 branch, and I'll post future patches against the branch instead of the release. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39370) 2.1.0b4 city vision radius too small
http://bugs.freeciv.org/Ticket/Display.html?id=39370 > Wondering why earlier developers had the knob, I fired up the old P5-60 Windows 3.11 civnet. Gosh, it's been years since I turned on that machine Building civ1 cities didn't reveal unexplored areas! So, my version with the configuration line is better for backward compatibility. I don't have any machines with my old civ2 installed -- long since replaced with civ3 PTW and Conquests -- perhaps somebody else could test civ2? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39364) 2.1.0b4 crash on opening scenarios screen
http://bugs.freeciv.org/Ticket/Display.html?id=39364 > Just compiled against today's S2_1, with some updated libraries, still crashed! Looks like string problem in a va_list. === Host Name: FlatLand.local Date/Time: 2007-05-19 05:30:52 -0400 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: civclient Path:/Users/wastrel/Projects/freeciv_stable/S2_1/client/civclient Version: ??? (???) PID: 23542 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x01df103c Thread 0 Crashed: 0 libSystem.B.dylib 0x90007220 strlen + 0x20 1 libglib-2.0.0.dylib 0x012e913c g_strdup + 0x20 2 libgobject-2.0.0.dylib 0x01133528 value_collect_string + 0x40 3 libgtk-x11-2.0.0.dylib 0x0163fc78 gtk_list_store_set_valist_internal + 0x390 4 libgtk-x11-2.0.0.dylib 0x0163ff08 gtk_list_store_set_valist + 0x17c 5 libgtk-x11-2.0.0.dylib 0x0163ffd4 gtk_list_store_set + 0x4c 6 civclient 0x000b2574 update_scenario_page + 0x12c (pages.c:1845) 7 civclient 0x000b32fc set_client_page + 0x100 (pages.c:2170) 8 civclient 0x000adfa8 start_scenario_callback + 0x18 (pages.c:106) 9 libgobject-2.0.0.dylib 0x0110f8f4 g_closure_invoke + 0x130 10 libgobject-2.0.0.dylib 0x01124104 signal_emit_unlocked_R + 0x8e8 11 libgobject-2.0.0.dylib 0x01123378 g_signal_emit_valist + 0x760 12 libgobject-2.0.0.dylib 0x01123618 g_signal_emit + 0x28 13 libgtk-x11-2.0.0.dylib 0x015161bc gtk_button_clicked + 0xd0 14 libgtk-x11-2.0.0.dylib 0x01517d24 gtk_real_button_released + 0x6c 15 libgobject-2.0.0.dylib 0x0110f8f4 g_closure_invoke + 0x130 16 libgobject-2.0.0.dylib 0x01123d5c signal_emit_unlocked_R + 0x540 17 libgobject-2.0.0.dylib 0x01123378 g_signal_emit_valist + 0x760 18 libgobject-2.0.0.dylib 0x01123618 g_signal_emit + 0x28 19 libgtk-x11-2.0.0.dylib 0x015160d8 gtk_button_released + 0xd0 20 libgtk-x11-2.0.0.dylib 0x015179c8 gtk_button_button_release + 0x3c 21 libgtk-x11-2.0.0.dylib 0x01648aa8 _gtk_marshal_BOOLEAN__BOXED + 0x124 22 libgobject-2.0.0.dylib 0x0110f8f4 g_closure_invoke + 0x130 23 libgobject-2.0.0.dylib 0x011242e4 signal_emit_unlocked_R + 0xac8 24 libgobject-2.0.0.dylib 0x011233b8 g_signal_emit_valist + 0x7a0 25 libgobject-2.0.0.dylib 0x01123618 g_signal_emit + 0x28 26 libgtk-x11-2.0.0.dylib 0x017fe908 gtk_widget_event_internal + 0x370 27 libgtk-x11-2.0.0.dylib 0x017fe1f4 gtk_widget_event + 0x150 28 libgtk-x11-2.0.0.dylib 0x01646864 gtk_propagate_event + 0x328 29 libgtk-x11-2.0.0.dylib 0x01644bcc gtk_main_do_event + 0x49c 30 libgdk-x11-2.0.0.dylib 0x010576c4 gdk_event_dispatch + 0xc0 31 libglib-2.0.0.dylib 0x012cf46c g_main_dispatch + 0x1ac 32 libglib-2.0.0.dylib 0x012d07cc g_main_context_dispatch + 0x98 33 libglib-2.0.0.dylib 0x012d0c7c g_main_context_iterate + 0x430 34 libglib-2.0.0.dylib 0x012d1450 g_main_loop_run + 0x360 35 libgtk-x11-2.0.0.dylib 0x01643d50 gtk_main + 0x140 36 civclient 0x000a85e0 ui_main + 0x4ec (gui_main.c:1420) 37 civclient 0x7620 main + 0x79c (civclient.c:360) 38 civclient 0x29b0 _start + 0x188 (crt.c:267) 39 dyld0x8fe1a31c _dyld_start + 0x64 PPC Thread State: srr0: 0x90007220 srr1: 0xf030vrsave: 0x cr: 0x28242244 xer: 0x lr: 0x012e913c ctr: 0x90007200 r0: 0x012e913c r1: 0xbfffe370 r2: 0x011334e8 r3: 0x01df1038 r4: 0x r5: 0xfefefeff r6: 0x80808080 r7: 0xbfffe600 r8: 0x01bc19a0 r9: 0x01df103c r10: 0x r11: 0x0133c59c r12: 0x90007200 r13: 0xbfffe900 r14: 0x0133c2e8 r15: 0x01143824 r16: 0xbfffe810 r17: 0x01b3fb30 r18: 0x0133c2e0 r19: 0x00562de0 r20: 0xbfffe7f8 r21: 0x007ca088 r22: 0x0133c2e8 r23: 0x r24: 0x0017fd7c r25: 0x01b460d0 r26: 0xbfffe640 r27: 0x01bc1240 r28: 0x r29: 0x01bc16d0 r30: 0x01df103c r31: 0x0163f900 Binary Images Description: 0x1000 -0xf0fff civclient ./client/civclient 0x565000 - 0x566fff libgmodule-2.0.0.dylib /opt/local/lib/libgmodule-2.0.0.dylib 0x56c000 - 0x571fff libpangocairo-1.0.0.dylib /opt/local/lib/libpangocairo-1.0.0.dylib 0x581000 - 0x595fff libatk-1.0.0.dylib /opt/local/lib/libatk-1.0.0.dylib 0x5a1000 - 0x5a7fff libXrender.1.dylib /opt/local/lib/libXrender.1.dylib 0x5ae000 - 0x5b6fff libintl.8.dylib/opt/local/lib/libintl.8.dylib 0x5c2000 - 0x5dcfff libgdk_pixbuf-2.0.0.dylib /opt/local/lib/libgdk_pixbuf-2.0.0.dylib 0x705000 - 0x71 libjpeg.62.dylib /opt/local/lib/libjpeg.62.dylib 0x726000 - 0x735fff libz.1.dylib /opt/local/lib/libz.1.dylib 0x74d000 - 0x750fff libpixbufloader-png.so /opt/local/lib/gtk-2.0
Re: [Freeciv-Dev] (PR#39370) 2.1.0b4 city vision radius too small
http://bugs.freeciv.org/Ticket/Display.html?id=39370 > Per I. Mathisen wrote: > I do not see why we should worry about that. It is nice that people can > play mods that feel like Civ1/2 with Freeciv, but we do not need to > support all kinds of small oddball configurations and/or bugs that people > scarcely even remember from civ1/2. > Admittedly, I played 1 & 2 so long ago that my memory is failing. ;-) I'm assuming that you are old enough to have played civ1 regularly for years (and civnet against multiple players), followed by more years playing civ2. I'm pretty sure the original freeciv authors disagree that the basic visual operation of civ1&2 was "oddball". They went to some lengths to reflect the actual historic functionality. Indeed, my suggestion was *NOT* that the old functionality go away, but that it should not be hard-coded -- a simple knob I proposed be added to allow civ3&4 behavior. Although I've only been on the mailing list for 18 months or so, and rarely contribute, I've some recollection that you worked on adding many knobs generalizing formerly hard-coded constants and functionality. I'm trying to cooperate in the same way. > Given how many bugs we have and have had related to vision, I think we > need to move toward making it simpler, rather than making it more complex. > While hard-coding a behavior is "simpler", it doesn't reflect my understanding of the purpose of the project: the "Good Parts Version" of the entire civ series with superior networking ability, and (hopefully) improved AI, running on multiple platforms. The old civ1&2 vision has been in the code and working for some time. I'm actually quite disappointed about the recent removing of basic functionality of civ1&2, such as reputation, temporary cease fire, Fundamentalism, etc. I'm even more disappointed that civ3 hasn't yet been added. But one thing at a time :-) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] current trunk compile failure(s)
I've been waiting around several days to see whether somebody fixes this? registry.c: In function `section_file_save': registry.c:816: error: `BUG_URL' undeclared (first use in this function) registry.c:816: error: (Each undeclared identifier is reported only once registry.c:816: error: for each function it appears in.) svn log utility/registry.c r12957 | per | 2007-05-17 12:24:54 -0400 (Thu, 17 May 2007) | 2 lines Replace bug email with bug URL. See PR#39329. svn diff -r12955:12963 utility/registry.c Index: utility/registry.c === --- utility/registry.c (revision 12955) +++ utility/registry.c (revision 12963) @@ -813,8 +813,7 @@ "avoid this make sure all rows of a table are filled\n" "out with an entry for every column. This is surely\n" "a bug so if you're reading this message, report it\n" - "to [EMAIL PROTECTED]", - real_filename, psection->name, expect); + "at %s", real_filename, psection->name, expect, BUG_URL); fz_fprintf(fs, "\n"); } fz_fprintf(fs, "}\n"); ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] current trunk compile failure(s)
William Allen Simpson wrote: > I've been waiting around several days to see whether somebody fixes this? > I'd repeatedly tried 'make clean' first, didn't work. Tried to find the missing .h, didn't work, posted here. Eventually, I grep'd the entire source, and found the symbol in configure.ac. ./autogen.sh --disable-nls --enable-client=gtk2 --prefix=/Users/wastrel/freeciv-test That worked! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39364) 2.1.0b4 crash on opening scenarios screen
http://bugs.freeciv.org/Ticket/Display.html?id=39364 > Reminder: ./autogen.sh --disable-nls --enable-client=gtk2 --prefix=/Users/wastrel/freeciv-stable Shouldn't be any translation, correct? === In client/gui-gtk-2.0/pages.c, update_scenario_page: /* Translated loaded names (if any). */ name = name ? _(name) : pfile->name; description = description ? _(description) : ""; assert(strlen(pfile->fullname)>0); assert(strlen(pfile->name)>0); assert(description!=NULL); assert(name!=NULL); assert(strlen(description)>0); assert(strlen(name)>0); gtk_list_store_append(scenario_store, &it); gtk_list_store_set(scenario_store, &it, 0, name, 1, pfile->fullname, 2, description, -1); Crash now occurs at: assert(strlen(description)>0); When I reverse the final tests, crash occurs at: assert(strlen(name)>0); === This is a CRASH, not an assert exit. The problem is bad memory access whenever trying to strlen description or name, as shown in the earlier crash logs. I'm presuming these untranslated names are bad. Branch 2.0 doesn't have this code. There's no way that I know enough to follow the translation routines, but I've narrowed it down so that there can be no question. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39377) RFE rivers on tile edges
http://bugs.freeciv.org/Ticket/Display.html?id=39377 > Currently, rivers only occur in the center of tiles. For civ 3 & 4, rivers appear along the edges of tiles, watering multiple adjacent tiles. Analyzing the requirements, it appears that the samegame could keep the river information with 3 additional bits to avoid duplicate/redundant information, describing the flat edges. Where edges are shared, only one tile (the lowest numbered, presumably in the North/Northwest) will have the bits. Any corner information can be derived from the flat edges. For hex tiles, need river1, river2, and river3. Keeping the edges separately allows the different isohex and hex2t to both work with tiles that have two rivers alternating edges (that is, river1 and river3). For square tiles, only river1 and river3 would be used, potentially allowing the same algorithm and graphics for the similarly oriented hex tile edges. Of course, here river1 and river3 have no intervening river2, so the square tiles could be encircled by river. This is analogous to currently switching from square to hex display, where (center) river branches display as circle artifacts. The current "river" bit could be kept (treated as river0), making it possible for rivers to flow both along edges and through the center. This would be different from civ 3 & 4, making display somewhat harder, but retaining much working code, and providing backward compatibility -- old rivers (river0) would continue to be displayed correctly. These savefiles would not likely be "reverse" compatible with earlier versions of the game, as new rivers would disappear and isolated center rivers become "ponds". ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39378) RFE hut dynamic rules
http://bugs.freeciv.org/Ticket/Display.html?id=39378 > The hut rules are currently static in unittools.c unit_enter_hut(). The rules should vary for civ1, 2, 3 & 4. For civ3 & 4, huts should respond more favorably to a scout, and very favorably within a national boundary. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39379) RFE civ3+ terrain support
http://bugs.freeciv.org/Ticket/Display.html?id=39379 > There is greater variety in civ3 (and other) terrain. Hills can be dry, grassy, and/or forested. Mountains can be dry, wet, icy, or volcanos. Oceans have several depths, with ridges, trenches, and vents/volcanos. Of course, not every combination is allowed. It should be possible to designate letters representing each valid combination. === Here's my first draft of a table. What have I missed? land: d desert D desert + hills p plain P plain + hills + evergreen q plain + hills + deciduous Q plain + hills + jungle g grass G grass + hills + evergreen k grass + hills + deciduous K grass + hills + jungle s swamp (grass) S swamp (grass) + evergreen z swamp (grass) + deciduous Z swamp (grass) + jungle t tundra T tundra + hills i ice (glacier) I ice + hills e evergreen forest (plain) E evergreen forest (grass) f deciduous forest (plain) F deciduous forest (grass) j jungle (grass) [existing] J jungle (plain) h hills (plain) [existing] H hills (grass) m mountains (bare) M mountains (icy) v volcano (bare) V volcano (icy?) lake: l fresh (higher elevation, has river to ocean) . salt (lower elevation, no river to ocean) ocean (formerly ' '): . coast , sea/shelf : floor ; trench ^ ridge ! vents ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 > With so many previous attempts, it seemed prudent to split off my effort for water into a separate ticket, so that they can cross reference. This is a more extensive consolidation. water (formerly ' '): + fresh lake (higher elevation, has river to ocean) - salt sea (lower elevation, no river to ocean) . coast , shelf : floor (deep) ; trench (abyss) ^ ridge ! vents This will incorporate an automatic technique for converting existing savefiles into the new types, by detecting ' ' (space) as "water", and determining fresh water lakes, salt water seas, with oceanic coast, shelf, and floor (deep). Note that whales are moved away from coast onto shelf (civ3, CTP). And there are no whales for inland lakes and seas. Note that shelf can still abut arctic/glacier ice, although not next to other shores. Floor (deep) and trench (abyss) are not next to any shore. There are placeholders for ridges and trenches and vents, but no code (yet) to generate them. They all need underwater mountain-like graphics. The reason for separate symbols for fresh water lakes and salt water seas is to simplify the civ3 irrigation calculations that require fresh water. This could also eliminate a lot of "safe" coastal testing, as it is done once at conversion/generation and saved. === This patch adds the first pass at revised water to the terrain rules (default only). The current revision 12965 has some support for deep, so tile definitions are not changed yet. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 >
Patch data/default/terrain.ruleset
Index: data/default/terrain.ruleset
===
--- data/default/terrain.ruleset(revision 12965)
+++ data/default/terrain.ruleset(working copy)
@@ -91,9 +91,11 @@
fallout_trade_penalty=50
; Below: The individual terrain types, one per section.
+;
; For now, the number of such sections must be kept the same (=12).
; Also, terrains should be in the same order as defined in common/map.h,
; and have similar roles/effects, as some things are still hardwired.
+;
; The actual tag used (the * in [terrain_*]) does not matter, except
; it must be unique for each terrain, and it may be used in debug
; output when reading this file.
@@ -152,8 +154,10 @@
; - CanHaveRiver = Set to 1 if this terrain can have river on it (the
;actual chance of river generation is controlled
;separately).
-; - UnsafeCoast = This terrain does not provide a safe coast for
+; - UnsafeCoast = This terrain does not provide a safe voyage for
;F_TRIRIEME units.
+; - UnsafeOcean = This terrain does not provide a safe voyage for
+;F_COASTAL or F_SEAWORTHY units.
; - Oceanic = This is an "ocean" terrain. This has a big effect
;on gameplay. Naval units can move on oceanic terrain,
;while land units cannot. Oceanic tiles can be used
@@ -177,6 +181,367 @@
; helptext= optional help text string; should escape all raw
; newlines so that xgettext parsing works
+[terrain_water]
+; undifferentiated open water from old savefiles
+name = _("Water")
+graphic = "ocean"
+graphic_alt = "-"
+identifier = " "
+movement_cost= 1
+defense_bonus= 0
+food = 1
+shield = 0
+trade= 2
+resources= "Fish", "Whales"
+road_trade_incr = 0
+road_time= 0
+irrigation_result= "no"
+irrigation_food_incr = 0
+irrigation_time = 0
+mining_result= "no"
+mining_shield_incr = 0
+mining_time = 0
+transform_result = "Swamp"
+transform_time = 36
+rail_time= 3
+airbase_time = 3
+fortress_time= 3
+clean_pollution_time = 3
+clean_fallout_time = 3
+warmer_wetter_result = "no"
+warmer_drier_result = "no"
+cooler_wetter_result = "no"
+cooler_drier_result = "no"
+native_to= "Sea", "Air", "Missile", "Helicopter"
+flags= "Oceanic", "NoCities", "NoPollution", "UnsafeCoast"
+property_ocean_depth = 10
+helptext= _("\
+Oceans cover much of the world, and only sea units (Triremes and\
+ other boats) can travel on them.\
+\n\n\
+Ocean squares can never be polluted or subjected to fallout.\
+")
+
+[terrain_fresh_water]
+name = _("Lake")
+graphic = "ocean"
+graphic_alt = "-"
+identifier = "+"
+movement_cost= 1
+defense_bonus= 0
+food = 1
+shield = 0
+trade= 2
+resources= "Fish"
+road_trade_incr = 0
+road_time= 0
+irrigation_result= "no"
+irrigation_food_incr = 0
+irrigation_time = 0
+mining_result= "no"
+mining_shield_incr = 0
+mining_time = 0
+transform_result = "Swamp"
+transform_time = 36
+rail_time= 3
+airbase_time = 3
+fortress_time= 3
+clean_pollution_time = 3
+clean_fallout_time = 3
+warmer_wetter_result = "no"
+warmer_drier_result = "no"
+cooler_wetter_result = "no"
+cooler_drier_result = "no"
+native_to= "Sea", "Air", "Missile", "Helicopter"
+flags= "Oceanic", "NoCities", "NoPollution"
+property_ocean_depth = 0
+helptext= _("\
+Oceans cover much of the world, and only sea units (Triremes and\
+ other boats) can travel on them.\
+\n\n\
+Ocean squares can never be polluted or subjected to fallout.\
+")
+
+[terrain_salt_water]
+name = _("Sea")
+graphic = "ocean"
+graphic_alt = "-"
+identifier = "-"
+movement_cost= 1
+defense_bonus= 0
+food = 1
+shield = 0
+trade= 2
+resources= "Fish"
+road_trade_incr = 0
+road_time= 0
+irrigation_result= "no"
+irrigation_food_incr = 0
+irrigation_time = 0
+mining_result= "no"
+mining_shield_incr = 0
+mining_time = 0
+transform_result = "Swamp"
+transform_time = 36
+rail_time= 3
+airbase_time = 3
+fortress_time= 3
+clean_pollution_time = 3
+clean_fallout_time = 3
+warmer_wetter_result = "no"
+warmer_drier_result = "no"
+cooler_wetter_result = "no"
+cooler_drier_result = "no"
+native
Re: [Freeciv-Dev] (PR#39379) RFE civ3+ terrain support
http://bugs.freeciv.org/Ticket/Display.html?id=39379 > Second draft, with minor corrections reconciling earlier attempts: land: a ice (arctic, glacier) A ice + hills t tundra T tundra + hills d desert D desert + hills p plain P plain + hills + evergreen q plain + hills + deciduous Q plain + hills + jungle g grass G grass + hills + evergreen k grass + hills + deciduous K grass + hills + jungle s swamp (grass) S swamp (grass) + evergreen z swamp (grass) + deciduous Z swamp (grass) + jungle e evergreen forest (plain) E evergreen forest (grass) f deciduous forest (plain) [existing] F deciduous forest (grass) j jungle (grass) [existing] J jungle (plain) h hills (plain) [existing] H hills (grass) m mountains (bare) M mountains (icy) u unseen [reserved] v volcano (bare) V volcano (icy?) water (formerly ' '): + fresh lake (higher elevation, has river to ocean) - salt sea (lower elevation, no river to ocean) . coast , shelf : floor (deep) ; trench (abyss) ^ ridge ! vents ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 >
Sadly, "Ocean" is more embedded in everything than I'd thought
Patch data/default/terrain.ruleset with smaller baby step.
Index: data/default/terrain.ruleset
===
--- data/default/terrain.ruleset(revision 12965)
+++ data/default/terrain.ruleset(working copy)
@@ -91,9 +91,11 @@
fallout_trade_penalty=50
; Below: The individual terrain types, one per section.
+;
; For now, the number of such sections must be kept the same (=12).
; Also, terrains should be in the same order as defined in common/map.h,
; and have similar roles/effects, as some things are still hardwired.
+;
; The actual tag used (the * in [terrain_*]) does not matter, except
; it must be unique for each terrain, and it may be used in debug
; output when reading this file.
@@ -152,8 +154,10 @@
; - CanHaveRiver = Set to 1 if this terrain can have river on it (the
;actual chance of river generation is controlled
;separately).
-; - UnsafeCoast = This terrain does not provide a safe coast for
+; - UnsafeCoast = This terrain does not provide a safe voyage for
;F_TRIRIEME units.
+; - UnsafeOcean = This terrain does not provide a safe voyage for
+;F_COASTAL or F_SEAWORTHY units.
; - Oceanic = This is an "ocean" terrain. This has a big effect
;on gameplay. Naval units can move on oceanic terrain,
;while land units cannot. Oceanic tiles can be used
@@ -177,6 +181,367 @@
; helptext= optional help text string; should escape all raw
; newlines so that xgettext parsing works
+[terrain_water]
+; undifferentiated open water from old savefiles
+name = _("Ocean")
+graphic = "ocean"
+graphic_alt = "-"
+identifier = " "
+movement_cost= 1
+defense_bonus= 0
+food = 1
+shield = 0
+trade= 2
+resources= "Fish", "Whales"
+road_trade_incr = 0
+road_time= 0
+irrigation_result= "no"
+irrigation_food_incr = 0
+irrigation_time = 0
+mining_result= "no"
+mining_shield_incr = 0
+mining_time = 0
+transform_result = "Swamp"
+transform_time = 36
+rail_time= 3
+airbase_time = 3
+fortress_time= 3
+clean_pollution_time = 3
+clean_fallout_time = 3
+warmer_wetter_result = "no"
+warmer_drier_result = "no"
+cooler_wetter_result = "no"
+cooler_drier_result = "no"
+native_to= "Sea", "Air", "Missile", "Helicopter"
+flags= "Oceanic", "NoCities", "NoPollution", "UnsafeCoast"
+property_ocean_depth = 10
+helptext= _("\
+Oceans cover much of the world, and only sea units (Triremes and\
+ other boats) can travel on them.\
+\n\n\
+Ocean squares can never be polluted or subjected to fallout.\
+")
+
+[terrain_fresh_water]
+name = _("Lake")
+graphic = "ocean"
+graphic_alt = "-"
+identifier = "+"
+movement_cost= 1
+defense_bonus= 0
+food = 1
+shield = 0
+trade= 2
+resources= "Fish"
+road_trade_incr = 0
+road_time= 0
+irrigation_result= "no"
+irrigation_food_incr = 0
+irrigation_time = 0
+mining_result= "no"
+mining_shield_incr = 0
+mining_time = 0
+transform_result = "Swamp"
+transform_time = 36
+rail_time= 3
+airbase_time = 3
+fortress_time= 3
+clean_pollution_time = 3
+clean_fallout_time = 3
+warmer_wetter_result = "no"
+warmer_drier_result = "no"
+cooler_wetter_result = "no"
+cooler_drier_result = "no"
+native_to= "Sea", "Air", "Missile", "Helicopter"
+flags= "Oceanic", "NoCities", "NoPollution"
+property_ocean_depth = 0
+helptext= _("\
+Oceans cover much of the world, and only sea units (Triremes and\
+ other boats) can travel on them.\
+\n\n\
+Ocean squares can never be polluted or subjected to fallout.\
+")
+
+[terrain_salt_water]
+name = _("Sea")
+graphic = "ocean"
+graphic_alt = "-"
+identifier = "-"
+movement_cost= 1
+defense_bonus= 0
+food = 1
+shield = 0
+trade= 2
+resources= "Fish"
+road_trade_incr = 0
+road_time= 0
+irrigation_result= "no"
+irrigation_food_incr = 0
+irrigation_time = 0
+mining_result= "no"
+mining_shield_incr = 0
+mining_time = 0
+transform_result = "Swamp"
+transform_time = 36
+rail_time= 3
+airbase_time = 3
+fortress_time= 3
+clean_pollution_time = 3
+clean_fallout_time = 3
+warmer_wetter_result = "no"
+w
Re: [Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 > I've discovered that the current state of the trunk is inconsistent. There appear to be parts of several patches from different PRs. As soon as the deep tiles are referenced, the client will not start. The current amplio terrain2.spec has t.l0.deep* while the tilespec has them at t.l1.deep*. The trident tiles.spec is even worse with t.l2.deep*. I'm mostly reintegrating 3 previous patches by hand. As the three layer approach seems to be already partly integrated, I'm finishing it, with the new ocean.png references. I agree with Jason that the boundary overlap in the graphics isn't correct. Anybody know what graphics editor I should use on this for consistency? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 >
Here is my first pass at the reintegrated patches. It runs. Not yet
extensively tested. My new code will take an old savefile and add four
kinds of water: lake, coast, shelf, and floor. Shelf and floor only
display as deep (so far).
Still, it's something to test!
Index: server/maphand.c
===
--- server/maphand.c(revision 12966)
+++ server/maphand.c(working copy)
@@ -120,6 +120,108 @@
}
/**
+ Regenerate bare ocean tiles with coasts, lakes, and deeper oceans
+**/
+static void regenerate_water(void)
+{
+ struct terrain *lake = get_terrain_by_identifier(LAKE_TERRAIN_IDENTIFIER);
+ struct terrain *coast = get_terrain_by_identifier(COAST_TERRAIN_IDENTIFIER);
+ struct terrain *shelf = get_terrain_by_identifier(SHELF_TERRAIN_IDENTIFIER);
+ struct terrain *floor = get_terrain_by_identifier(FLOOR_TERRAIN_IDENTIFIER);
+
+ /* coasts and lakes */
+ whole_map_iterate(ptile) {
+Continent_id here = tile_get_continent(ptile);
+
+if (T_UNKNOWN == ptile->terrain)
+ continue;
+
+if (WATER_TERRAIN_IDENTIFIER != ptile->terrain->identifier)
+ continue;
+
+if (0 < lake_surrounders[-here]) {
+ tile_set_terrain(ptile,lake);
+ continue;
+}
+
+adjc_iterate(ptile, tile2) {
+ if (T_UNKNOWN == tile2->terrain)
+continue;
+
+ /* glacier not otherwise near land is not coast */
+ if (GLACIER_TERRAIN_IDENTIFIER == tile2->terrain->identifier)
+continue;
+
+ if (!is_ocean(tile2->terrain)) {
+tile_set_terrain(ptile,coast);
+break;
+ }
+} adjc_iterate_end;
+ } whole_map_iterate_end;
+
+ /* continental shelf */
+ whole_map_iterate(ptile) {
+int near = 0;
+
+if (T_UNKNOWN == ptile->terrain)
+ continue;
+
+if (WATER_TERRAIN_IDENTIFIER != ptile->terrain->identifier)
+ continue;
+
+adjc_iterate(ptile, tile2) {
+ if (T_UNKNOWN == tile2->terrain)
+continue;
+
+ switch (tile2->terrain->identifier) {
+ case GLACIER_TERRAIN_IDENTIFIER:
+ case COAST_TERRAIN_IDENTIFIER:
+near++;
+break;
+ };
+} adjc_iterate_end;
+
+if (6 < near) {
+ /* smooth with neighbors */
+ tile_set_terrain(ptile,coast);
+} else if (0 < near) {
+ tile_set_terrain(ptile,shelf);
+}
+ } whole_map_iterate_end;
+
+ /* deep ocean floor */
+ whole_map_iterate(ptile) {
+int near = 0;
+
+if (T_UNKNOWN == ptile->terrain)
+ continue;
+
+if (WATER_TERRAIN_IDENTIFIER != ptile->terrain->identifier)
+ continue;
+
+adjc_iterate(ptile, tile2) {
+ if (T_UNKNOWN == tile2->terrain)
+continue;
+
+ switch (tile2->terrain->identifier) {
+ case GLACIER_TERRAIN_IDENTIFIER:
+ case COAST_TERRAIN_IDENTIFIER:
+ case SHELF_TERRAIN_IDENTIFIER:
+near++;
+break;
+ };
+} adjc_iterate_end;
+
+if (6 < near) {
+ /* smooth with neighbors */
+ tile_set_terrain(ptile,shelf);
+} else {
+ tile_set_terrain(ptile,floor);
+}
+ } whole_map_iterate_end;
+}
+
+/**
Assigns continent and ocean numbers to all tiles, and set
map.num_continents and map.num_oceans. Recalculates continent and
ocean sizes, and lake_surrounders[] arrays.
@@ -167,6 +269,7 @@
} whole_map_iterate_end;
recalculate_lake_surrounders();
+ regenerate_water();
freelog(LOG_VERBOSE, "Map has %d continents and %d oceans",
map.num_continents, map.num_oceans);
Index: data/amplio/terrain2.spec
===
--- data/amplio/terrain2.spec (revision 12966)
+++ data/amplio/terrain2.spec (working copy)
@@ -66,62 +66,62 @@
3, 7, "t.t_river_n1e1s1w1"
-;forrests as overlay
+;forests as overlay
- 4, 0, "t.l1.forest_n0e0s0w0"
- 4, 1, "t.l1.forest_n1e0s0w0"
- 4, 2, "t.l1.forest_n0e1s0w0"
- 4, 3, "t.l1.forest_n1e1s0w0"
- 4, 4, "t.l1.forest_n0e0s1w0"
- 4, 5, "t.l1.forest_n1e0s1w0"
- 4, 6, "t.l1.forest_n0e1s1w0"
- 4, 7, "t.l1.forest_n1e1s1w0"
- 5, 0, "t.l1.forest_n0e0s0w1"
- 5, 1, "t.l1.forest_n1e0s0w1"
- 5, 2, "t.l1.forest_n0e1s0w1"
- 5, 3, "t.l1.forest_n1e1s0w1"
- 5, 4, "t.l1.forest_n0e0s1w1"
- 5, 5, "t.l1.forest_n1e0s1w1"
- 5, 6, "t.l1.forest_n0e1s1w1"
- 5, 7, "t.l1.forest_n1e1s1w1"
+ 4, 0, "t.l2.forest_n0e0s0w0"
+ 4, 1, "t.l2.forest_n1e0s0w0"
+ 4, 2, "t.l2.forest_n0e1s0w0"
+ 4, 3, "t.l2.forest_n1e1s0w0"
+ 4, 4, "t.l2.forest_n0e0s1w0"
+ 4, 5, "t.l2.forest_n1e0s1w0"
+ 4, 6, "t.l2.forest_n0e1s1w0"
+ 4, 7, "t.l2.forest_n1e1s1w0"
+ 5, 0, "t.l2.forest_n0e0s0w1"
+ 5, 1, "t.l2.forest_n1e0s0w1"
+ 5, 2, "t.l2.forest_n0e1s0w1"
+ 5, 3, "t.l2.forest_n1e1s0w1"
+ 5, 4, "t.l2.forest_n0e0s1w1"
Re: [Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 >
Here is my second pass at the code. Amplio is ready, but everything else
is broken. Have to keep the name "Ocean" for various nations to work, so
that is assigned to "Coast", as differentiated from "Lake" and "Sea".
Of course, this doesn't make the graphics any prettier. I've tried, but
I'm not much good at using GIMP.
Index: server/maphand.c
===
--- server/maphand.c(revision 12966)
+++ server/maphand.c(working copy)
@@ -120,6 +120,108 @@
}
/**
+ Regenerate bare ocean tiles with coasts, lakes, and deeper oceans
+**/
+static void regenerate_water(void)
+{
+ struct terrain *lake = get_terrain_by_identifier(LAKE_TERRAIN_IDENTIFIER);
+ struct terrain *coast = get_terrain_by_identifier(COAST_TERRAIN_IDENTIFIER);
+ struct terrain *shelf = get_terrain_by_identifier(SHELF_TERRAIN_IDENTIFIER);
+ struct terrain *floor = get_terrain_by_identifier(FLOOR_TERRAIN_IDENTIFIER);
+
+ /* coasts and lakes */
+ whole_map_iterate(ptile) {
+Continent_id here = tile_get_continent(ptile);
+
+if (T_UNKNOWN == ptile->terrain)
+ continue;
+
+if (WATER_TERRAIN_IDENTIFIER != ptile->terrain->identifier)
+ continue;
+
+if (0 < lake_surrounders[-here]) {
+ tile_set_terrain(ptile,lake);
+ continue;
+}
+
+adjc_iterate(ptile, tile2) {
+ if (T_UNKNOWN == tile2->terrain)
+continue;
+
+ /* glacier not otherwise near land is not coast */
+ if (GLACIER_TERRAIN_IDENTIFIER == tile2->terrain->identifier)
+continue;
+
+ if (!is_ocean(tile2->terrain)) {
+tile_set_terrain(ptile,coast);
+break;
+ }
+} adjc_iterate_end;
+ } whole_map_iterate_end;
+
+ /* continental shelf */
+ whole_map_iterate(ptile) {
+int near = 0;
+
+if (T_UNKNOWN == ptile->terrain)
+ continue;
+
+if (WATER_TERRAIN_IDENTIFIER != ptile->terrain->identifier)
+ continue;
+
+adjc_iterate(ptile, tile2) {
+ if (T_UNKNOWN == tile2->terrain)
+continue;
+
+ switch (tile2->terrain->identifier) {
+ case GLACIER_TERRAIN_IDENTIFIER:
+ case COAST_TERRAIN_IDENTIFIER:
+near++;
+break;
+ };
+} adjc_iterate_end;
+
+if (6 < near) {
+ /* smooth with neighbors */
+ tile_set_terrain(ptile,coast);
+} else if (0 < near) {
+ tile_set_terrain(ptile,shelf);
+}
+ } whole_map_iterate_end;
+
+ /* deep ocean floor */
+ whole_map_iterate(ptile) {
+int near = 0;
+
+if (T_UNKNOWN == ptile->terrain)
+ continue;
+
+if (WATER_TERRAIN_IDENTIFIER != ptile->terrain->identifier)
+ continue;
+
+adjc_iterate(ptile, tile2) {
+ if (T_UNKNOWN == tile2->terrain)
+continue;
+
+ switch (tile2->terrain->identifier) {
+ case GLACIER_TERRAIN_IDENTIFIER:
+ case COAST_TERRAIN_IDENTIFIER:
+ case SHELF_TERRAIN_IDENTIFIER:
+near++;
+break;
+ };
+} adjc_iterate_end;
+
+if (6 < near) {
+ /* smooth with neighbors */
+ tile_set_terrain(ptile,shelf);
+} else {
+ tile_set_terrain(ptile,floor);
+}
+ } whole_map_iterate_end;
+}
+
+/**
Assigns continent and ocean numbers to all tiles, and set
map.num_continents and map.num_oceans. Recalculates continent and
ocean sizes, and lake_surrounders[] arrays.
@@ -167,6 +269,7 @@
} whole_map_iterate_end;
recalculate_lake_surrounders();
+ regenerate_water();
freelog(LOG_VERBOSE, "Map has %d continents and %d oceans",
map.num_continents, map.num_oceans);
Index: data/amplio/terrain2.spec
===
--- data/amplio/terrain2.spec (revision 12966)
+++ data/amplio/terrain2.spec (working copy)
@@ -66,62 +66,62 @@
3, 7, "t.t_river_n1e1s1w1"
-;forrests as overlay
+;forests as overlay
- 4, 0, "t.l1.forest_n0e0s0w0"
- 4, 1, "t.l1.forest_n1e0s0w0"
- 4, 2, "t.l1.forest_n0e1s0w0"
- 4, 3, "t.l1.forest_n1e1s0w0"
- 4, 4, "t.l1.forest_n0e0s1w0"
- 4, 5, "t.l1.forest_n1e0s1w0"
- 4, 6, "t.l1.forest_n0e1s1w0"
- 4, 7, "t.l1.forest_n1e1s1w0"
- 5, 0, "t.l1.forest_n0e0s0w1"
- 5, 1, "t.l1.forest_n1e0s0w1"
- 5, 2, "t.l1.forest_n0e1s0w1"
- 5, 3, "t.l1.forest_n1e1s0w1"
- 5, 4, "t.l1.forest_n0e0s1w1"
- 5, 5, "t.l1.forest_n1e0s1w1"
- 5, 6, "t.l1.forest_n0e1s1w1"
- 5, 7, "t.l1.forest_n1e1s1w1"
+ 4, 0, "t.l2.forest_n0e0s0w0"
+ 4, 1, "t.l2.forest_n1e0s0w0"
+ 4, 2, "t.l2.forest_n0e1s0w0"
+ 4, 3, "t.l2.forest_n1e1s0w0"
+ 4, 4, "t.l2.forest_n0e0s1w0"
+ 4, 5, "t.l2.forest_n1e0s1w0"
+ 4, 6, "t.l2.forest_n0e1s1w0"
+ 4, 7, "t.l2.forest_n1e1s1w0"
+ 5, 0, "t.l2.forest_n0e0s0w1"
+ 5, 1, "t.l2.forest_n1e0s0w1"
+ 5, 2, "t.l2.forest_n0e1s0w1"
+ 5, 3,
[Freeciv-Dev] (PR#39382) civ1 and civ2 rulesets crash, no sea barbarians, bad tech Never
http://bugs.freeciv.org/Ticket/Display.html?id=39382 > Tried testing my civ3 oceans against civ2 and civ1, just to make sure my code is behaving -- lo and behold, they already crash the server -- without my help civ2 2: Loading rulesets 1: No sea barbarian nation defined. At least one required! civ1 2: Loading rulesets 1: Invalid requirement Tech | Player | | | Never 1: Section airbase has unknown req: "Tech" "Never" (data/civ1/terrain.ruleset) 1: No sea barbarian nation defined. At least one required! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#34095) [Patch] Nation sanity checking
http://bugs.freeciv.org/Ticket/Display.html?id=34095 > Was this a testing process that is over now? For 2.1.0b4, I'd been testing rulesets and such by good ol' fashioned ./ser and load from the command line. Aborts now in trunk. === > load ../D-4000 2: Loading rulesets 1: Failed sanity check: !pplayer->nation || pplayer->nation->player == pplayer (sanitycheck.c:469) 1: last message repeated 2 times > quit Goodbye. player.c:243: failed assertion `pplayer->nation->player == pplayer' Abort trap ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39381) RFE civ3+ water support
http://bugs.freeciv.org/Ticket/Display.html?id=39381 > Per I. Mathisen wrote: > http://bugs.freeciv.org/Ticket/Display.html?id=39381 > > > On Sun, 27 May 2007, William Allen Simpson wrote: >> Pass 4 matches the revised amplio graphics. > > What is the purpose of all these new ocean types (trench, vent, etc.) in > the game, and why are you adding them to the civ1/civ2 rulesets (they > clearly did not have them)? > Otherwise, loading the savegames will blow up. New terrain identifiers have to be properly handled, even where (as in this case) they are just mapped to the same tile for display. We could build an equivalence mapping file, but it seemed simpler to me to add them to the (few) rulesets. It's just a datafile, too Unless you would prefer numerous extra configuration tests to world generation, game loading/saving, etc, depending on the ruleset? ;-) > I am all in favour of adding the deep/shallow distinction, but for the > others ones I am not sure what role they play. Is it for better graphics? > The deep/shallow distinction both helped the (previously non-working) shelf edge graphic, and in civ3 there are "seafaring" ships that can travel coast and shelf, but not deep ocean. Civ3 has volcanos. They erupt. In other civ related games, the ridges and floor are useful city sites. And have extra resources. They don't appear until after Oil discovery, but that seems harder to implement for a first pass. (I called them "oceanic vents" -- which actually covers more -- to distinguish them from land volcanoes and the future tile graphic; but should be easier for translators than details of oceanography and mid-ocean ridge processes.) In short, I'm trying to cover all known game possibilities, even where they aren't yet used, to avoid future data file conflicts. Finally, I'm hoping the result will look like "Google map", where this stuff is all clearly visible these days to the layman! :-) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39382) civ1 and civ2 rulesets crash, no sea barbarians, bad tech Never
http://bugs.freeciv.org/Ticket/Display.html?id=39382 > A patch for the sea barbarians had already been posted at PR#38387 many weeks ago. Committed. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39383) BUG: terrain and resource name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39383 >
While trying to debug some of my terrain changes, it was frustrating that
some error messages had empty (missing/blank) fields. Numerous messages
tried to insert a translated name into log messages that are not translated.
(I'm running without translation, so it shows up badly here.)
So, I spent all day figuring out some problems, and found a few others!
For example, the req_ Terrain Mountains probably didn't work for foreign
languages, because the test compared the translated terrain name against a
list that is always in ruleset (original) language.
Tests were wildly inconsistent, sometimes testing against original, others
against translated. I made them *all* against original. Translated names
are now only accessed via a central function. (The function existed, but
not everybody used it.)
My solution was to rename the "name" field to name_translated (how it
was actually used in most places), and rename name_orig to name_original.
That allowed me to find all the uses.
For the same reason, I renamed the accessor functions, so that future
programmers will be more aware of the actual purpose (or less confused).
I found some error messages that could be reworded to be identical, with
different parameters, that should ease translation a little.
Also, I found that there were many places that terrain and tiles were
confused (such as calling terrain "tile_type"). That will take more
time to unravel.
Compiles, runs here, needs more testing.
Index: server/generator/mapgen.c
===
--- server/generator/mapgen.c (revision 12970)
+++ server/generator/mapgen.c (working copy)
@@ -303,8 +303,8 @@
**/
static struct terrain *pick_ocean(int depth)
{
- /* FIXME: get_flag_terrain may return NULL if there is no match. */
- struct terrain *best_terrain = get_flag_terrain(TER_OCEANIC);
+ /* FIXME: pick_terrain_by_flag may return NULL if there is no match. */
+ struct terrain *best_terrain = pick_terrain_by_flag(TER_OCEANIC);
int best_match = abs(depth - best_terrain->property[MG_OCEAN_DEPTH]);
terrain_type_iterate(pterrain) {
@@ -980,9 +980,9 @@
if (!terrain_has_flag(pterrain, TER_CAN_HAVE_RIVER)) {
/* We have to change the terrain to put a river here. */
- /* FIXME: get_flag_terrain may return NULL
+ /* FIXME: pick_terrain_by_flag may return NULL
* if there is no match. */
- pterrain = get_flag_terrain(TER_CAN_HAVE_RIVER);
+ pterrain = pick_terrain_by_flag(TER_CAN_HAVE_RIVER);
tile_set_terrain(tile1, pterrain);
}
tile_set_special(tile1, S_RIVER);
@@ -1109,7 +1109,7 @@
terrain_type_iterate(pterrain) {
freelog(loglevel, "%20s : %4d %d%% ",
- get_name(pterrain), terrain_count[pterrain->index],
+ pterrain->name_original, terrain_count[pterrain->index],
(terrain_count[pterrain->index] * 100 + 50) / total);
} terrain_type_iterate_end;
}
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg(revision 12970)
+++ server/scripting/api.pkg(working copy)
@@ -100,7 +100,7 @@
};
struct Terrain {
- const char *name_orig @ name;
+ const char *name_original @ name;
};
Index: server/scripting/api_find.c
===
--- server/scripting/api_find.c (revision 12970)
+++ server/scripting/api_find.c (working copy)
@@ -147,15 +147,15 @@
**/
Terrain *api_find_terrain(int terrain_id)
{
- return get_terrain(terrain_id);
+ return get_terrain_by_number(terrain_id);
}
/**
- Return the tech type with the given name_orig.
+ Return the terrain with the given name_orig.
**/
Terrain *api_find_terrain_by_name(const char *name_orig)
{
- struct terrain *pterrain = get_terrain_by_name(name_orig);
+ struct terrain *pterrain = get_terrain_by_original_name(name_orig);
return pterrain;
}
Index: server/citytools.c
===
--- server/citytools.c (revision 12970)
+++ server/citytools.c (working copy)
@@ -1097,7 +1097,7 @@
_("Moved %s out of disbanded city %s "
"since it cannot stay on %s."),
unit_type(punit)->name, pcity->name,
- get_name(tile_get_terrain(ptile)));
+ terrain_name_translation(tile_get_terrain(ptile)));
break;
}
}
Index: server/cityturn.c
===
Re: [Freeciv-Dev] (PR#39383) BUG: terrain and resource name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39383 >
In this version, I moved the translation into the accessor functions, as
this seemed to be better than spread around in 3 places, especially as the
other places in the code forgot to test for NULL and '\0' (empty string).
Comments in the code seemed to indicate a move was desired.
There's a warning, because the current resource list is const, and this
modifies the pointer. Updating the const can happen later.
Also, renamed the previous name_orig (or name_original) to name_rule --
that better indicates where the name originated, and makes it easier to
search in the future.
I've left the rest alone, but more could be done
As far as I'm concerned, it's ready to check in.
Index: server/generator/mapgen.c
===
--- server/generator/mapgen.c (revision 12970)
+++ server/generator/mapgen.c (working copy)
@@ -303,8 +303,8 @@
**/
static struct terrain *pick_ocean(int depth)
{
- /* FIXME: get_flag_terrain may return NULL if there is no match. */
- struct terrain *best_terrain = get_flag_terrain(TER_OCEANIC);
+ /* FIXME: pick_terrain_by_flag may return NULL if there is no match. */
+ struct terrain *best_terrain = pick_terrain_by_flag(TER_OCEANIC);
int best_match = abs(depth - best_terrain->property[MG_OCEAN_DEPTH]);
terrain_type_iterate(pterrain) {
@@ -980,9 +980,9 @@
if (!terrain_has_flag(pterrain, TER_CAN_HAVE_RIVER)) {
/* We have to change the terrain to put a river here. */
- /* FIXME: get_flag_terrain may return NULL
+ /* FIXME: pick_terrain_by_flag may return NULL
* if there is no match. */
- pterrain = get_flag_terrain(TER_CAN_HAVE_RIVER);
+ pterrain = pick_terrain_by_flag(TER_CAN_HAVE_RIVER);
tile_set_terrain(tile1, pterrain);
}
tile_set_special(tile1, S_RIVER);
@@ -1109,7 +1109,7 @@
terrain_type_iterate(pterrain) {
freelog(loglevel, "%20s : %4d %d%% ",
- get_name(pterrain), terrain_count[pterrain->index],
+ pterrain->name_rule, terrain_count[pterrain->index],
(terrain_count[pterrain->index] * 100 + 50) / total);
} terrain_type_iterate_end;
}
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg(revision 12970)
+++ server/scripting/api.pkg(working copy)
@@ -100,7 +100,7 @@
};
struct Terrain {
- const char *name_orig @ name;
+ const char *name_rule @ name;
};
Index: server/scripting/api_find.c
===
--- server/scripting/api_find.c (revision 12970)
+++ server/scripting/api_find.c (working copy)
@@ -147,15 +147,15 @@
**/
Terrain *api_find_terrain(int terrain_id)
{
- return get_terrain(terrain_id);
+ return get_terrain_by_number(terrain_id);
}
/**
- Return the tech type with the given name_orig.
+ Return the terrain with the given name_orig.
**/
Terrain *api_find_terrain_by_name(const char *name_orig)
{
- struct terrain *pterrain = get_terrain_by_name(name_orig);
+ struct terrain *pterrain = get_terrain_by_rule_name(name_orig);
return pterrain;
}
Index: server/citytools.c
===
--- server/citytools.c (revision 12970)
+++ server/citytools.c (working copy)
@@ -1097,7 +1097,7 @@
_("Moved %s out of disbanded city %s "
"since it cannot stay on %s."),
unit_type(punit)->name, pcity->name,
- get_name(tile_get_terrain(ptile)));
+ terrain_name_translation(tile_get_terrain(ptile)));
break;
}
}
Index: server/cityturn.c
===
--- server/cityturn.c (revision 12970)
+++ server/cityturn.c (working copy)
@@ -817,7 +817,7 @@
"%s terrain is required. Postponing..."),
pcity->name,
get_impr_name_ex(pcity, building->index),
- get_name(preq->source.value.terrain));
+
terrain_name_translation(preq->source.value.terrain));
script_signal_emit("building_cant_be_built", 3,
API_TYPE_BUILDING_TYPE, building,
API_TYPE_CITY, pcity,
Index: server/ruleset.c
===
--- server/ruleset.c(revi
Re: [Freeciv-Dev] (PR#39383) BUG: terrain and resource name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39383 >
trunk revision 12972
S2_1 revision 12973
As S2_1 required a number of trivial changes, here's the final patch for
the record (after 12972, making 12973). In particular, where translated
strings already exist, they are painstakingly maintained.
Index: server/generator/mapgen.c
===
--- server/generator/mapgen.c (revision 12972)
+++ server/generator/mapgen.c (working copy)
@@ -303,8 +303,8 @@
**/
static struct terrain *pick_ocean(int depth)
{
- /* FIXME: get_flag_terrain may return NULL if there is no match. */
- struct terrain *best_terrain = get_flag_terrain(TER_OCEANIC);
+ /* FIXME: pick_terrain_by_flag may return NULL if there is no match. */
+ struct terrain *best_terrain = pick_terrain_by_flag(TER_OCEANIC);
int best_match = abs(depth - best_terrain->property[MG_OCEAN_DEPTH]);
terrain_type_iterate(pterrain) {
@@ -980,9 +980,9 @@
if (!terrain_has_flag(pterrain, TER_CAN_HAVE_RIVER)) {
/* We have to change the terrain to put a river here. */
- /* FIXME: get_flag_terrain may return NULL
+ /* FIXME: pick_terrain_by_flag may return NULL
* if there is no match. */
- pterrain = get_flag_terrain(TER_CAN_HAVE_RIVER);
+ pterrain = pick_terrain_by_flag(TER_CAN_HAVE_RIVER);
tile_set_terrain(tile1, pterrain);
}
tile_set_special(tile1, S_RIVER);
@@ -1109,7 +1109,7 @@
terrain_type_iterate(pterrain) {
freelog(loglevel, "%20s : %4d %d%% ",
- get_name(pterrain), terrain_count[pterrain->index],
+ pterrain->name_rule, terrain_count[pterrain->index],
(terrain_count[pterrain->index] * 100 + 50) / total);
} terrain_type_iterate_end;
}
Index: server/scripting/api_gen.c
===
--- server/scripting/api_gen.c (revision 12972)
+++ server/scripting/api_gen.c (working copy)
@@ -550,14 +550,14 @@
return 1;
}
-/* get function: name_orig of class Terrain */
-static int tolua_get_Terrain_Terrain_name_orig(lua_State* tolua_S)
+/* get function: name_rule of class Terrain */
+static int tolua_get_Terrain_Terrain_name_rule(lua_State* tolua_S)
{
Terrain* self = (Terrain*) tolua_tousertype(tolua_S,1,0);
#ifndef TOLUA_RELEASE
- if (!self) tolua_error(tolua_S,"invalid 'self' in accessing variable
'name_orig'",NULL);
+ if (!self) tolua_error(tolua_S,"invalid 'self' in accessing variable
'name_rule'",NULL);
#endif
- tolua_pushstring(tolua_S,(const char*)self->name_orig);
+ tolua_pushstring(tolua_S,(const char*)self->name_rule);
return 1;
}
@@ -1616,7 +1616,7 @@
tolua_endmodule(tolua_S);
tolua_cclass(tolua_S,"Terrain","Terrain","",NULL);
tolua_beginmodule(tolua_S,"Terrain");
- tolua_variable(tolua_S,"name",tolua_get_Terrain_Terrain_name_orig,NULL);
+ tolua_variable(tolua_S,"name",tolua_get_Terrain_Terrain_name_rule,NULL);
tolua_endmodule(tolua_S);
tolua_function(tolua_S,"methods_player_num_cities",tolua_api_methods_player_num_cities00);
tolua_function(tolua_S,"methods_player_num_units",tolua_api_methods_player_num_units00);
Index: server/scripting/api.pkg
===
--- server/scripting/api.pkg(revision 12972)
+++ server/scripting/api.pkg(working copy)
@@ -100,7 +100,7 @@
};
struct Terrain {
- const char *name_orig @ name;
+ const char *name_rule @ name;
};
Index: server/scripting/api_find.c
===
--- server/scripting/api_find.c (revision 12972)
+++ server/scripting/api_find.c (working copy)
@@ -147,15 +147,15 @@
**/
Terrain *api_find_terrain(int terrain_id)
{
- return get_terrain(terrain_id);
+ return get_terrain_by_number(terrain_id);
}
/**
- Return the tech type with the given name_orig.
+ Return the terrain with the given name_orig.
**/
Terrain *api_find_terrain_by_name(const char *name_orig)
{
- struct terrain *pterrain = get_terrain_by_name(name_orig);
+ struct terrain *pterrain = get_terrain_by_rule_name(name_orig);
return pterrain;
}
Index: server/cityturn.c
===
--- server/cityturn.c (revision 12972)
+++ server/cityturn.c (working copy)
@@ -770,7 +770,7 @@
"%s terrain is required. Postponing..."),
pcity->name,
get_impr_name_ex(pcity, building->index),
- get_name(preq->source.value.terrain));
+
[Freeciv-Dev] (PR#39386) cleanup tilespec.c
http://bugs.freeciv.org/Ticket/Display.html?id=39386 >
Do we allow a cleanup phase?
Trying to understand tilespec.c, there are a number of places where an
if{} or {} was added around major sections of code without reindenting.
Also, several levels of alternating ifs and switches, where fewer levels
will work with just a bit of code duplication or adding a subroutine.
This code was nearly incomprehensible (until I straightened it).
While I was at it, there are an awful lot of places where log messages
will just show a couple of blanks (such as, unused alt graphics names).
They needed \"%s\" in the format.
Here's an evening's worth of cleanup. No additional function, other
than leaving in some of the new parameter names that I'll want later
Tested in my local branch, I'll check it against current trunk tonight.
Index: client/tilespec.c
===
--- client/tilespec.c (revision 12973)
+++ client/tilespec.c (working copy)
@@ -60,6 +60,7 @@
#include "tilespec.h"
#define TILESPEC_SUFFIX ".tilespec"
+#define TILE_SECTION_PREFIX "terrain_"
/* This the way directional indices are now encoded: */
#define MAX_INDEX_CARDINAL 64
@@ -76,22 +77,26 @@
enum direction4 {
DIR4_NORTH = 0, DIR4_SOUTH, DIR4_EAST, DIR4_WEST
};
+const char direction4letters[4] = "udrl";
enum match_style {
- MATCH_NONE, MATCH_BOOLEAN, MATCH_FULL
+ MATCH_NONE,
+ MATCH_SAME, /* "boolean" match */
+ MATCH_FULL
};
enum cell_type {
- CELL_SINGLE, CELL_RECT
+ CELL_WHOLE, /* entire tile */
+ CELL_CORNER /* corner of tile */
};
-#define MAX_NUM_LAYERS 3
-
struct terrain_drawing_data {
char *name;
char *mine_tag;
- int num_layers; /* Can only be 1 or 2. */
+ int num_layers; /* 1 thru MAX_NUM_LAYERS. */
+#define MAX_NUM_LAYERS 3
+
struct {
bool is_tall;
int offset_x, offset_y;
@@ -1018,7 +1023,7 @@
sprintf(full_name, "%s.%s", gfx_filename, gfx_fileext);
if ((real_full_name = datafilename(full_name))) {
- freelog(LOG_DEBUG, "trying to load gfx file %s", real_full_name);
+ freelog(LOG_DEBUG, "trying to load gfx file \"%s\".", real_full_name);
s = load_gfxfile(real_full_name);
if (s) {
return s;
@@ -1026,7 +1031,7 @@
}
}
- freelog(LOG_VERBOSE, "Could not load gfx file %s.", gfx_filename);
+ freelog(LOG_VERBOSE, "Could not load gfx file \"%s\".", gfx_filename);
return NULL;
}
@@ -1061,7 +1066,7 @@
sf->big_sprite = load_gfx_file(gfx_filename);
if (!sf->big_sprite) {
-freelog(LOG_FATAL, _("Couldn't load gfx file for the spec file %s"),
+freelog(LOG_FATAL, _("Couldn't load gfx file for the spec file \"%s\"."),
sf->file_name);
exit(EXIT_FAILURE);
}
@@ -1147,7 +1152,7 @@
if (!duplicates_ok) {
for (k = 0; k < num_tags; k++) {
if (!hash_insert(t->sprite_hash, mystrdup(tags[k]), ss)) {
- freelog(LOG_ERROR, "warning: already have a sprite for %s",
tags[k]);
+ freelog(LOG_ERROR, "warning: already have a sprite for \"%s\".",
tags[k]);
}
}
} else {
@@ -1191,7 +1196,7 @@
if (!duplicates_ok) {
for (k = 0; k < num_tags; k++) {
if (!hash_insert(t->sprite_hash, mystrdup(tags[k]), ss)) {
- freelog(LOG_ERROR, "warning: already have a sprite for %s", tags[k]);
+ freelog(LOG_ERROR, "warning: already have a sprite for \"%s\".",
tags[k]);
}
}
} else {
@@ -1230,13 +1235,57 @@
}
}
- freelog(LOG_FATAL, _("Couldn't find a supported gfx file extension for %s"),
+ freelog(LOG_FATAL, _("Couldn't find a supported gfx file extension for
\"%s\"."),
gfx_filename);
exit(EXIT_FAILURE);
return NULL;
}
/**
+ Determine the match_style string.
+***/
+static int check_match_style(const char *style, const int layer)
+{
+ if (mystrcasecmp(style, "bool") == 0) {
+return MATCH_SAME;
+ }
+ if (mystrcasecmp(style, "full") == 0) {
+return MATCH_FULL;
+ }
+ if (mystrcasecmp(style, "none") == 0) {
+return MATCH_NONE;
+ }
+ if (mystrcasecmp(style, "same") == 0) {
+return MATCH_SAME;
+ }
+ freelog(LOG_ERROR, "Unknown match_style \"%s\" for layer %d.",
+ style, layer);
+ return MATCH_NONE;
+}
+
+/**
+ Determine the cell_type string.
+***/
+static int check_cell_type(const char *cell_type, const char *tile_type)
+{
+ if (mystrcasecmp(cell_type, "corner") == 0) {
+return CELL_CORNER;
+ }
+ if (mystrcasecmp(cell_type, "rect") == 0) {
+return CELL_CORNER;
+ }
+ if (mystrcasecmp(cell_type, "single") == 0) {
+return CELL_WHOLE;
+ }
+ if (mystrcasecmp(cell_type, "whole")
Re: [Freeciv-Dev] (PR#39386) cleanup tilespec.c
http://bugs.freeciv.org/Ticket/Display.html?id=39386 > Committed trunk revision 12976. Note that this makes it obvious that the code does not even come close to the doc/README.graphics documentation! (Very confusing to new coders.) Moreover, the match_type = "full" requires the cell_type = "rect", then actually operates on a "cellgroup" -- AFAICT a whole tile! The code was so convoluted that folks have been putting things in the wrong place Another day, another patch. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39387) replace match_type = "full" with "pair"
http://bugs.freeciv.org/Ticket/Display.html?id=39387 > match_type = "full" -- as it exists -- has a number of problems. It requires the cell_type = "rect", then actually operates on a "cellgroup" -- AFAICT a whole tile! It conflicts (or at least the documentation says it does) with all other match types. This causes otherwise unnecessary drawing layers. It requires exponentially more tiles as the number of potential matches. Currently, 3 matches requires 81 tiles, and the older version required about 96 corner cells (some were duplicates). It is not used in existing tilesets, likely because of its problems. === match_type = "pair" should operate in full orthogonal harmony with other match types. Thus, various tiles could use pairwise matching (such as water and glacier), while others could use single/boolean matching (such as hills), and others none. This would collapse the current terrain2 and terrain3 levels, and/or allow more interesting interactions. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Bug in windows client sdl 2.1.0 beta 4
Keguji Ves Zavrey wrote: > If there is any way I can help more to remove this bug, then please e-mail me. > Could you attach the savegame? > ps. I tried to send this email to [EMAIL PROTECTED] but I get > undelivery bounces... Yes, that address died from spam overload, try [EMAIL PROTECTED] ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39385) suggestion: Buy column on Cities report
http://bugs.freeciv.org/Ticket/Display.html?id=39385 > Lars Huttar wrote: > So I would like an easy way to locate the build products I can afford to > buy. > ... > An alternative way to do it would be to highlight (e.g. make bold) the > city rows for which the player has enough gold to buy the build products. > Good idea! I'd also prefer the / fields to be in the same order in each column, so that it's easy to see when something is going to be done soon (turns remaining as first). ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39385) suggestion: Buy column on Cities report preliminary patch
http://bugs.freeciv.org/Ticket/Display.html?id=39385 > > It is a patch to client/cityrepdata.c in the S2_1 branch and it builds > fine and seems to work > Of course, since this is an enhancement (not a bug fix, and especially one that adds new translation), it would be for trunk first, and have to be "approved" for S2_1. Also, it seems from inspection to have the cost twice in the list, so more work needs to be done It's not an area I'm familiar with, but due to popularity, I'll take a look. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39385) suggestion: Buy column on Cities report preliminary patch
http://bugs.freeciv.org/Ticket/Display.html?id=39385 >
I've a different patch against trunk. The documentation in comments on
how to add are wrong. I shuffled the fields a bit. To make up for the
extra space, I turned off the governor field default.
This doesn't show costs larger than (the previous patch had a bug
in that the field was declared as only 3 wide, but had no check). In my
test with 7 wonders building, I didn't need more than that.
Index: client/cityrepdata.c
===
--- client/cityrepdata.c(revision 12975)
+++ client/cityrepdata.c(working copy)
@@ -362,21 +362,13 @@
if (!pcity->production.is_unit
&& impr_flag(pcity->production.value, IF_GOLD)) {
-my_snprintf(buf, sizeof(buf), "%s (%d/X/X/X)%s",
+my_snprintf(buf, sizeof(buf), "%s (%d/X)%s",
get_impr_name_ex(pcity, pcity->production.value),
MAX(0, pcity->surplus[O_SHIELD]), from_worklist);
} else {
-int turns = city_turns_to_build(pcity, pcity->production, TRUE);
-char time[32];
const char *name;
int cost;
-if (turns < 999) {
- my_snprintf(time, sizeof(time), "%d", turns);
-} else {
- my_snprintf(time, sizeof(time), "-");
-}
-
if(pcity->production.is_unit) {
name = get_unit_type(pcity->production.value)->name;
cost = unit_build_shield_cost(get_unit_type(pcity->production.value));
@@ -385,14 +377,42 @@
cost = impr_build_shield_cost(pcity->production.value);
}
-my_snprintf(buf, sizeof(buf), "%s (%d/%d/%s/%d)%s", name,
- pcity->shield_stock, cost, time, city_buy_cost(pcity),
+my_snprintf(buf, sizeof(buf), "%s (%d/%d)%s", name,
+ pcity->shield_stock, cost,
from_worklist);
}
return buf;
}
+static const char *cr_entry_build_turns(const struct city *pcity,
+ const void *data)
+{
+ int turns = city_turns_to_build(pcity, pcity->production, TRUE);
+ static char buf[8];
+
+ if (turns < ) {
+my_snprintf(buf, sizeof(buf), "%4d", turns);
+ } else {
+my_snprintf(buf, sizeof(buf), "-");
+ }
+ return buf;
+}
+
+static const char *cr_entry_buy_cost(const struct city *pcity,
+ const void *data)
+{
+ int price = city_buy_cost(pcity);
+ static char buf[8];
+
+ if (price < ) {
+my_snprintf(buf, sizeof(buf), "%4d", price);
+ } else {
+my_snprintf(buf, sizeof(buf), "-");
+ }
+ return buf;
+}
+
static const char *cr_entry_corruption(const struct city *pcity,
const void *data)
{
@@ -417,7 +437,6 @@
/* City report options (which columns get shown)
* To add a new entry, you should just have to:
- * - increment NUM_CREPORT_COLS in cityrepdata.h
* - add a function like those above
* - add an entry in the city_report_specs[] table
*/
@@ -454,12 +473,17 @@
N_("Best attacking units"), NULL, FUNC_TAG(attack)},
{ FALSE, 8, 1, N_("Best"), N_("defense"),
N_("Best defending units"), NULL, FUNC_TAG(defense)},
- { FALSE, 2, 1, N_("Units"), N_("?Supported (units):Sup"),
+ { FALSE, 2, 1, N_("Units"), N_("?Present (units):Here"),
+N_("Number of units present"), NULL, FUNC_TAG(present) },
+ { FALSE, 2, 1, N_("Units"), N_("?Supported (units):Home"),
N_("Number of units supported"), NULL, FUNC_TAG(supported) },
- { FALSE, 2, 1, N_("Units"), N_("?Present (units):Prs"),
-N_("Number of units present"), NULL, FUNC_TAG(present) },
- { TRUE, 10, 1, N_("Surplus"), N_("?food/prod/trade:F/P/T"),
+ { TRUE, 4, 1, NULL, N_("?turn:Grow"), N_("Turns until growth/famine"),
+NULL, FUNC_TAG(growturns) },
+ { TRUE, 7, 1, N_("Food"), N_("Stock"), N_("Food Stock"),
+NULL, FUNC_TAG(food) },
+
+ { TRUE, 10, 1, N_("Surplus"), N_("?food/production/trade:F/P/T"),
N_("Surplus: Food, Production, Trade"),
NULL, FUNC_TAG(resources) },
{ FALSE, 3, 1, NULL, N_("?Food surplus:F+"), N_("Surplus: Food"),
@@ -468,7 +492,12 @@
N_("Surplus: Production"), NULL, FUNC_TAG(prodplus) },
{ FALSE, 3, 1, NULL, N_("?Trade surplus:T+"), N_("Surplus: Trade"),
NULL, FUNC_TAG(tradeplus) },
- { TRUE, 10, 1, N_("Economy"), N_("?gold/lux/sci:G/L/S"),
+ { FALSE, 3, 1, NULL, N_("?corruption:T-"), N_("Corruption"),
+NULL, FUNC_TAG(corruption) },
+ { FALSE, 3, 1, NULL, N_("?waste:P-"), N_("Waste"),
+NULL, FUNC_TAG(waste) },
+
+ { TRUE, 10, 1, N_("Economy"), N_("?gold/luxury/science:G/L/S"),
N_("Economy: Gold, Luxuries, Science"),
NULL, FUNC_TAG(output) },
{ FALSE, 3, 1, NULL, N_("?Gold:G"), N_("Economy: Gold"),
@@ -480,19 +509,16 @@
{ FALSE, 1, 1, N_("?trade_routes:n"), N_("?trade_routes:T"),
N_("Number of Trade Routes"),
NULL, FUNC_TAG(num_trade) },
- { TRUE, 7, 1, N_("Food"), N_("Stock"), N_("Food
Re: [Freeciv-Dev] You can't alter const objects?
James Supancic wrote: > In resource_name_translation, in terrain.c you are altering the value > of a const parameter. > This is not allowed, and gcc 4.1 tells us this with: > terrain.c: In function 'resource_name_translation': > terrain.c:244: error: assignment of read-only location > > I'm not sure how this should be fixed? Maybe just remove the const > type specifier? It was working fine before, then I did "svn up" and it > broke. > It's only a warning here, you must have stricter compliance turned on. (I noted the warning in a comment in the code.) Actually, it's initializing a component of the structure, which certainly *always* has to be done at some point! The problem is that somebody prior to me declared the enclosing array const, when it's clearly not. I'll fix it today. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39383) BUG: terrain and resource name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39383 >
William Allen Simpson wrote:
> There's a warning, because the current resource list is const, and this
> modifies the pointer. Updating the const can happen later.
>
trunk revision 12977
S2_1 revision 12978
Remaining "const struct resource *" caused 1 warning, and a report that
gcc 4.1 (or a stricter compile option) escalated it to a compile error.
Most "const" removed; 5 remain in function parameters, causing no warnings.
This is the S2_1 patch for posterity. The trunk is nearly identical
(different line numbers).
Happy hacking! Please let me know of any more problems!
Index: server/generator/mapgen.c
===
--- server/generator/mapgen.c (revision 12977)
+++ server/generator/mapgen.c (working copy)
@@ -1361,7 +1361,7 @@
}
if (!is_ocean(pterrain) || near_safe_tiles (ptile)) {
int i = 0;
- const struct resource **r;
+ struct resource **r;
for (r = pterrain->resources; *r; r++) {
/* This is a standard way to get a random element from the
Index: server/ruleset.c
===
--- server/ruleset.c(revision 12977)
+++ server/ruleset.c(working copy)
@@ -2788,7 +2788,7 @@
terrain_type_iterate(pterrain) {
const int i = pterrain->index;
-const struct resource **r;
+struct resource **r;
packet.id = i;
Index: server/maphand.h
===
--- server/maphand.h(revision 12977)
+++ server/maphand.h(working copy)
@@ -40,7 +40,7 @@
struct player_tile {
struct terrain *terrain; /* May be NULL for unknown tiles. */
bv_special special;
- const struct resource *resource;
+ struct resource *resource;
unsigned short seen_count[V_COUNT];
unsigned short own_seen[V_COUNT];
/* If you build a city with an unknown square within city radius
Index: server/savegame.c
===
--- server/savegame.c (revision 12977)
+++ server/savegame.c (working copy)
@@ -746,7 +746,7 @@
ch is the character read from the map, and n is the number of the special
(0 for special_1, 1 for special_2).
/
-static void set_savegame_old_resource(const struct resource **r,
+static void set_savegame_old_resource(struct resource **r,
const struct terrain *terrain,
char ch, int n)
{
@@ -769,7 +769,7 @@
/
Return the resource for the given identifier.
/
-static const struct resource *identifier_to_resource(char c)
+static struct resource *identifier_to_resource(char c)
{
if (c == RESOURCE_NULL_IDENTIFIER) {
return NULL;
Index: common/combat.c
===
--- common/combat.c (revision 12977)
+++ common/combat.c (working copy)
@@ -601,10 +601,10 @@
struct unit *punit = unit_list_get(ptile->units, 0);
freelog(LOG_ERROR, "get_defender bug: %s's %s vs %s's %s (total %d"
-" units) on %s at (%d,%d). ", unit_owner(attacker)->name,
+" units) on \"%s\" at (%d,%d). ", unit_owner(attacker)->name,
unit_type(attacker)->name, unit_owner(punit)->name,
unit_type(punit)->name, unit_list_size(ptile->units),
-terrain_name_translation(ptile->terrain), ptile->x, ptile->y);
+ptile->terrain->name_rule, ptile->x, ptile->y);
}
return bestdef;
Index: common/tile.c
===
--- common/tile.c (revision 12977)
+++ common/tile.c (working copy)
@@ -114,7 +114,7 @@
/
Set the given resource at the specified tile.
/
-void tile_set_resource(struct tile *ptile, const struct resource *presource)
+void tile_set_resource(struct tile *ptile, struct resource *presource)
{
ptile->resource = presource;
}
Index: common/tile.h
===
--- common/tile.h (revision 12977)
+++ common/tile.h (working copy)
@@ -30,7 +30,7 @@
int index; /* Index coordinate of the tile. */
struct terrain *terrain; /* May be NULL for unknown tiles. */
bv_special special;
- const struct resource *resource; /* available resource, or NULL */
+ struct resource *resource; /* available resource, or NULL */
struct city *ci
Re: [Freeciv-Dev] (PR#39385) RFE: Buy column on Cities report
http://bugs.freeciv.org/Ticket/Display.html?id=39385 >
Ulrik Sverdrup wrote:
> I did this with the field width wrong as well, but I think we should
> reserve a width up to 5 for build costs. I can imagine wonders costing
> more than 1 if you buy them from scratch in the derfault ruleset.
> With mods or altered rulesets, it might be even more possible, so we
> should allow up to 5 digits.
>
OK. Done.
> + { TRUE, 4, 1, NULL, N_("?gold:Buy"), N_("Gold to purchase building"),
> + NULL, FUNC_TAG(buy_cost) },
>
> In this change, shouldn't it be FALSE in the first field (for
> numerical values), And a better long text would be "Cost to rush
> production" (I think that is consistent with other wording around in
> freeciv, and "building" might associate to improvement which is wrong.
>
The first field is whether to show by default. We want it to show --
it is the same Buy formerly shown in "Currently Building".
After playing around a bit, I've combined the Turns and Buy into a
single column. Two columns just takes too much screen real estate.
The sort always seems to have the buy cost roughly correspond to the
remaining turns. How about:
?action:Building
Turns/Buy
Turns or gold to complete production
===
While playing around, I've implemented my wish list of changes.
It's always bugged me that the specialists occur at the far right, after
the buildings. That turned out to be an artifact of the initialization.
And that the name of the city scrolls off to the left as I'm looking at
buildings. So, I moved the city name into the middle.
All the happiness and growth (and units) are now to the left.
All the science, production, and trade are now to the right.
Comments?
Index: client/cityrepdata.c
===
--- client/cityrepdata.c(revision 12977)
+++ client/cityrepdata.c(working copy)
@@ -60,8 +60,8 @@
const void *data)
{
static char buf[4];
- my_snprintf(buf, sizeof(buf), "%s", (city_celebrating(pcity) ? "*" :
- (city_unhappy(pcity) ? "X" : " ")));
+ my_snprintf(buf, sizeof(buf), "%s", (city_celebrating(pcity) ? "+" :
+ (city_unhappy(pcity) ? "-" : " ")));
return buf;
}
@@ -272,9 +272,8 @@
static char buf[32];
int goldie = pcity->surplus[O_GOLD];
- my_snprintf(buf, sizeof(buf), "%s%d/%d/%d",
- (goldie < 0) ? "-" : (goldie > 0) ? "+" : "",
- (goldie < 0) ? (-goldie) : goldie,
+ my_snprintf(buf, sizeof(buf), "%3d/%d/%d",
+ goldie,
pcity->prod[O_LUXURY],
pcity->prod[O_SCIENCE]);
return buf;
@@ -311,28 +310,24 @@
return buf;
}
-static const char *cr_entry_food(const struct city *pcity,
-const void *data)
-{
- static char buf[32];
- my_snprintf(buf, sizeof(buf), "%d/%d",
- pcity->food_stock,
- city_granary_size(pcity->size) );
- return buf;
-}
-
static const char *cr_entry_growturns(const struct city *pcity,
const void *data)
{
- static char buf[8];
int turns = city_turns_to_grow(pcity);
+ char buffer[8];
+ static char buf[32];
+
if (turns == FC_INFINITY) {
/* 'never' wouldn't be easily translatable here. */
-my_snprintf(buf, sizeof(buf), "-");
+my_snprintf(buffer, sizeof(buffer), "---");
} else {
/* Shrinking cities get a negative value. */
-my_snprintf(buf, sizeof(buf), "%4d", turns);
+my_snprintf(buffer, sizeof(buffer), "%4d", turns);
}
+ my_snprintf(buf, sizeof(buf), "%s (%d/%d)",
+ buffer,
+ pcity->food_stock,
+ city_granary_size(pcity->size) );
return buf;
}
@@ -362,21 +357,13 @@
if (!pcity->production.is_unit
&& impr_flag(pcity->production.value, IF_GOLD)) {
-my_snprintf(buf, sizeof(buf), "%s (%d/X/X/X)%s",
+my_snprintf(buf, sizeof(buf), "%s (%d/X)%s",
get_impr_name_ex(pcity, pcity->production.value),
MAX(0, pcity->surplus[O_SHIELD]), from_worklist);
} else {
-int turns = city_turns_to_build(pcity, pcity->production, TRUE);
-char time[32];
const char *name;
int cost;
-if (turns < 999) {
- my_snprintf(time, sizeof(time), "%d", turns);
-} else {
- my_snprintf(time, sizeof(time), "-");
-}
-
if(pcity->production.is_unit) {
name = get_unit_type(pcity->production.value)->name;
cost = unit_build_shield_cost(get_unit_type(pcity->production.value));
@@ -385,19 +372,42 @@
cost = impr_build_shield_cost(pcity->production.value);
}
-my_snprintf(buf, sizeof(buf), "%s (%d/%d/%s/%d)%s", name,
- pcity->shield_stock, cost, time, city_buy_cost(pcity),
+my_snprintf(buf, sizeof(buf), "%s (%d/%d)%s", name,
+ pcity->shield_stock, cost,
from_worklist);
}
return
Re: [Freeciv-Dev] (PR#39388) S2_1 missing t.ocean1
http://bugs.freeciv.org/Ticket/Display.html?id=39388 > Daniel Markstedt wrote: > S2_1 rev12978; when connecting to a server: > > 0: Don't have graphics tags t.ocean1 or for base terrain Ocean > I think I'm the person that most recently touched that area of S2_1, but not the terrain files themselves We'll need a lot more information, as it Works For Me. S2_1/data/amplio/terrain1.spec line 125 15, 3, "t.ocean1" What client? What tileset? What server? What ruleset? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39389) BUG: technology/advance name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39389 > Per I. Mathisen wrote: > All LOG_ERROR, LOG_VERBOSE and LOG_FATAL messages should be without > translation. > To summarize, only LOG_NORMAL should be translated, because those are displayed to the user. > I am not sure if this is written down anywhere. It should probably be > added to http://freeciv.wikia.com/wiki/Internationalization > A place that I had not seen. Would help to have a README in doc, too. There's a tiny bit in fcintl.h, and some other macros; PL_() and Qn_(), that I'm not sure are actually used ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39388) S2_1 missing t.ocean1
http://bugs.freeciv.org/Ticket/Display.html?id=39388 > I don't know how to help you. I'm running MacOSX 10.3.9 with MacPorts. I just re-did all my usual, just in case there was something odd left over: cd Projects/freeciv_stable/S2_1/ export LDFLAGS="-L/opt/local/lib" export CPPFLAGS="-I/opt/local/include" export CC="gcc -no-cpp-precomp" ./autogen.sh --disable-nls --enable-client=gtk2 --prefix=/Users/wastrel/freeciv-stable make clean make >&../xx There's just one warning in the output: ld: warning multiple definitions of symbol _locale_charset /opt/local/lib/libintl.dylib(localcharset.o) definition of _locale_charset /opt/local/lib/libiconv.dylib(localcharset.o) definition of _locale_charset In X11 xterm, cd Projects/freeciv_stable/S2_1/ ./civ 2: No real audio plugin present, proceeding with sound support disabled 2: For sound support, install SDL_mixer 2: http://www.libsdl.org/projects/SDL_mixer/index.html It starts up the server (awfully slowly) and just runs! BBEdit finds all the t.ocean1, too. S2_1/data/amplio/terrain1.spec:125: 15, 3, "t.ocean1" S2_1/data/hex2t/tiles.spec:59:2, 10, "t.ocean1" S2_1/data/isophex/terrain1.spec:55:10, 0, "t.ocean1" S2_1/data/isotrident/terrain1.spec:137:0, 3, "t.ocean1" Somehow, there's something unusual about your setup? (Or mine?) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39390) S2_1: SDL client compile fails
http://bugs.freeciv.org/Ticket/Display.html?id=39390 >
This is definitely odd. The history shows that's been around a very long
time
S2_1/ChangeLog:30707:
Thu Jun 17 13:07:54 1999 Nicolas Brunel <[EMAIL PROTECTED]>:
* acconfig.h, config.h.in, configure.in, client/civclient.c,
common/shared.h, server/civserver.c: The defines MAILING_LIST and
SITE has been replaced by BUG_EMAIL_ADDRESS and WEBSITE_URL. They
have been withdrawn from acconfig.h. We now hint people to report
bugs via [EMAIL PROTECTED] . Patch submitted by David Pfitzner
<[EMAIL PROTECTED]>.
But my search of the source didn't find it in any of those places.
S2_1/client/gui-sdl/gui_main.c:202:
fc_fprintf(stderr, _("Report bugs to <%s>.\n"), BUG_EMAIL_ADDRESS);
Yet, it compiles here! (Admittedly, I've not tried SDL, just GTK2.)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39391) Warnings in lua code
http://bugs.freeciv.org/Ticket/Display.html?id=39391 > I don't get those warnings/errors, either. Of course, I'm running gcc 3.3 on a G5 -- gcc 4.1 itself won't even compile on this system, something wrong with the register assignment last time I checked (months ago). But since getting various reports of warnings turning into fatal errors, probably should upgrade the entire lua package. Especially as lua isn't really used for much yet. Nip the problem in the bud. Assuming the new version doesn't have bigger and better errors. I'll note that included gettext is pretty old, too. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39385) RFE: Buy column on Cities report
http://bugs.freeciv.org/Ticket/Display.html?id=39385 > And now the debate: Could this be pulled up into 2.1 at this late date? It was a more of a bug fix than a mere enhancement, and on that basis alone, I'm in favor. It is missing one new (rarely seen) menu translation. How do I know it would rarely be seen? Items in the same menu in many translations were missing or incomplete. Repeated cases. I fixed a bunch! And there are many that I could not fix I'll count the original requester and the preliminary patcher -- with me, that's 3. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39385) RFE: Buy column on Cities report
http://bugs.freeciv.org/Ticket/Display.html?id=39385 > Per I. Mathisen wrote: > The question is, does it change translations? If so, I'd say no. It is > frozen for new features and translation string changes now. We need to get > it out soon... :/ > Soon, as in 15 months ago? There are still many bug reports, some crashing. We need to fix them and put out another beta. The short answer is NO, a single menu item can be replaced by an existing string (such as "Production") for S2_1. Thus, it meets the requirement "frozen for new ... translation string changes now." I'll assume that I've met the requirement, and check it in without further complaint. It would help for those of you using trunk to actually test the revised city report (F1). I think you'll like it, and consider it a worthy addition to S2_1! The long answer is YES, I fixed many (about 135) translation strings. These should not be frozen! === For example, in the first (cs.po) and many others: #: client/gui-sdl/citydlg.c:2603 #, fuzzy, c-format msgid "?food:Surplus: %d" -msgstr "?Food surplus:J+" +msgstr "?food:PÅ™ebytek: %d" As you can plainly see, 18/27 files had dropped the %d, in various ways, probably the most common problem. This does not work properly (an active translator would have noticed)! How did this get missed? My guess is that some kind of mechanical process confused the two colon, msgid "?food:Surplus: %d" with the single colon (and different capitalization) earlier in the file, -msgid "?Food surplus:F+" -msgstr "?Food surplus:J+" << As you can see, I added [short], among other changes to the format. That should help ensure translation consistency in the future: +msgid "?Food surplus [short]:+F" +msgstr "?Food surplus [short]:+J" === Another example (pt_BR.po), #: client/cityrepdata.c:441 #, fuzzy msgid "Workers: Happy" -msgstr "Operários" +msgstr "Operários: Feliz" #: client/cityrepdata.c:443 #, fuzzy msgid "Workers: Content" -msgstr "Operários" +msgstr "Operários: Contente" #: client/cityrepdata.c:445 #, fuzzy msgid "Workers: Unhappy" -msgstr "Operários" +msgstr "Operários: Descontente" As you can plainly see, 3 menu items are all translated "Workers" without the descriptor. All you see is: Operários Operários Operários Not useful! I was able to guess the descriptor from other strings. (There's a lot of redundancy in the files.) === In fact, I did a lot of that kind of thing. I started out working on my own changes, and noticed a lot of problems in lines nearby. I spent far more time fixing other folk's errors than adding this Buy column. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39385) RFE: Buy column on Cities report
http://bugs.freeciv.org/Ticket/Display.html?id=39385 > Committed S2_1 revision 12989. Committed trunk revision 12990. At this point, both should function exactly the same. Except Russian. I was surprised to discover that there were quite a few conflicts with S2_1, because folks have been updating .po files there without fixing trunk, and vice versa. Therefore, I harmonized them both. The trunk changes are attached. Unfortunately, ru.po isn't even using the same character set. Somebody who can read the language will have to handle them. (Sorry, my russian is limited to phonetic singing after much rehearsal.) Please note: I only harmonized the parts of .po files near city report. There are a lot of other differences that translators should handle. Presumably the persons that committed updates to only one branch! Index: po/cs.po === --- po/cs.po(revision 12989) +++ po/cs.po(working copy) @@ -7726,8 +7726,8 @@ msgstr "Oslavuje/Klid/Nepokoj" #: client/cityrepdata.c:435 -msgid "Concise +=Rapture, -=Disorder" -msgstr "StruÄnÄ +=Oslavuje, -=Nepokoj" +msgid "Concise + Rapture, - Disorder" +msgstr "StruÄnÄ + Oslavuje, - Nepokoj" #: client/cityrepdata.c:437 client/gui-mui/citydlg.c:1365 #: client/gui-xaw/citydlg.c:2408 data/default/units.ruleset:309 Index: po/pt_BR.po === --- po/pt_BR.po (revision 12989) +++ po/pt_BR.po (working copy) @@ -7205,7 +7205,7 @@ #: client/cityrepdata.c:73 msgid "?city_state:Rapture" -msgstr "Celebração" +msgstr "Celebração" #: client/cityrepdata.c:74 msgid "?city_state:Disorder" @@ -7217,10 +7217,9 @@ #: client/cityrepdata.c:361 msgid "(worklist)" -msgstr "" +msgstr "(lista de tarefas)" #: client/cityrepdata.c:429 -#, fuzzy msgid "?city:Name" msgstr "Nome" @@ -7243,99 +7242,88 @@ #: client/cityrepdata.c:433 msgid "Rapture/Peace/Disorder" -msgstr "Celebração/Paz/Desordem" +msgstr "Celebração/Paz/Desordem" #: client/cityrepdata.c:435 -msgid "Concise +=Rapture, -=Disorder" -msgstr "Conciso +=Celebração, -=Desordem" +msgid "Concise + Rapture, - Disorder" +msgstr "Conciso + Celebração, - Desordem" #: client/cityrepdata.c:437 client/gui-mui/citydlg.c:1365 #: client/gui-xaw/citydlg.c:2408 data/default/units.ruleset:309 msgid "Workers" -msgstr "Operários" +msgstr "Operários" #: client/cityrepdata.c:438 msgid "?happy/content/unhappy/angry:H/C/U/A" -msgstr "F/C/D/A" +msgstr "F/C/D/Z" #: client/cityrepdata.c:439 -#, fuzzy msgid "Workers: Happy, Content, Unhappy, Angry" -msgstr "Operários: Feliz, Contente, Descontente" +msgstr "Operários: Feliz, Contente, Descontente, Zangado" #: client/cityrepdata.c:441 msgid "?Happy workers:H" msgstr "F" #: client/cityrepdata.c:441 -#, fuzzy msgid "Workers: Happy" -msgstr "Operários: Feliz" +msgstr "Operários: Feliz" #: client/cityrepdata.c:443 msgid "?Content workers:C" -msgstr "" +msgstr "C" #: client/cityrepdata.c:443 -#, fuzzy msgid "Workers: Content" -msgstr "Operários: Contente" +msgstr "Operários: Contente" #: client/cityrepdata.c:445 msgid "?Unhappy workers:U" msgstr "D" #: client/cityrepdata.c:445 -#, fuzzy msgid "Workers: Unhappy" -msgstr "Operários: Descontente" +msgstr "Operários: Descontente" #: client/cityrepdata.c:447 msgid "?Angry workers:A" -msgstr "" +msgstr "Z" #: client/cityrepdata.c:447 -#, fuzzy msgid "Workers: Angry" -msgstr "Operários" +msgstr "Operários: Zangado" #: client/cityrepdata.c:449 msgid "Special" msgstr "Especial" #: client/cityrepdata.c:450 -#, fuzzy msgid "?entertainers/scientists/taxmen:E/S/T" -msgstr "?Artistas, Cientistas, Fiscais:A/C/F" +msgstr "A/C/F" #: client/cityrepdata.c:451 msgid "Entertainers, Scientists, Taxmen" msgstr "Artistas, Cientistas, Fiscais" #: client/cityrepdata.c:453 client/cityrepdata.c:455 -#, fuzzy msgid "Best" -msgstr "Servidor" +msgstr "Melhor" #: client/cityrepdata.c:453 -#, fuzzy msgid "attack" -msgstr "Ataque:" +msgstr "ataque" #: client/cityrepdata.c:454 -#, fuzzy msgid "Best attacking units" -msgstr "Atacar automaticamente contra unidades terrestres" +msgstr "Unidades com melhor ataque" #: client/cityrepdata.c:455 -#, fuzzy msgid "defense" -msgstr "Defesa:" +msgstr "defesa" #: client/cityrepdata.c:456 -#, fuzzy msgid "Best defending units" -msgstr "Dissolve unidade" +msgstr "Unidades com melhor defesa" #: client/cityrepdata.c:457 client/cityrepdata.c:459 #: client/gui-gtk-2.0/cityrep.c:1208 client/gui-gtk-2.0/cityrep.c:1229 @@ -7349,28 +7337,24 @@ #: client/gui-xaw/menu.c:219 client/gui-xaw/menu.c:246 #: client/gui-xaw/repodlgs.c:890 client/gui-xaw/repodlgs.c:1085 #: data/Freeciv.in:1895 data/helpdata.txt:866 -#, fuzzy msgid "Units" -msgstr "?_Lista de:Unidades" +msgstr "Unidades" #: client/cityrepdata.c:457 -#, fuzzy msgid "?Supported (units):Owned" -msgstr "suportadas" +msgstr "Sup" #: client/cityrepdata.c:
Re: [Freeciv-Dev] (PR#39389) BUG: technology/advance name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39389 > I've begun a new section on standardization, with a section on logging. http://freeciv.wikia.com/wiki/Internationalization#Logging ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39394) Rigid border rules in S2_1
http://bugs.freeciv.org/Ticket/Display.html?id=39394 > Ulrik Sverdrup wrote: > Proposed change: make borders in S2_1 a little less rigid, by allowing > tiles to change hands when new sources are drastically closer than the > old owning source. > I agree. I have my own collection of odd border events pictures. My guess is that the current system of recording the border (as in the samegame) with one source per tile is too rigid. It probably needs a list per tile of influences, with each tile then "deciding" the owner dynamically. New/changed sources would each record their influence in surrounding tiles. But I never understood the other things that were tried. It certainly has to be different for civ3, where temples, libraries, etc. increase influence over time. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39396) BUG: 2.1.0b4 section_file_load_section
http://bugs.freeciv.org/Ticket/Display.html?id=39396 > This code has *never* worked: PR#14243 committed in revision 11100 (Sun, 09 Oct 2005) 20 months ago. It is called in only one place, client/gui-gtk-2.0/pages.c update_scenario_page, that crashes! (PR#39364) Its parameter, const char *part, was unused. It must be passed to the next routine. Index: utility/registry.c === --- utility/registry.c (revision 12991) +++ utility/registry.c (working copy) @@ -653,7 +653,7 @@ inf = inf_from_file(real_filename, datafilename); return section_file_read_dup(my_section_file, real_filename, - inf, TRUE, NULL); + inf, TRUE, part); } ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39364) 2.1.0b4 crash on opening scenarios screen
http://bugs.freeciv.org/Ticket/Display.html?id=39364 >
The problem was not in the translation routines. It had other causes.
This code has *never* worked: PR#14243 committed in revision 11100 (Sun,
09 Oct 2005) 20 months ago.
The primary cause is that code freed the section file data before copying
the name and description strings. Their pointers were no longer valid.
The secondary problem is that the new routine section_file_load_section,
used only in this place, did not function as documented. (PR#39396)
Although my patch works, it has not been tested extensively. It is
dependent on other patches to function properly, and should be
committed simultaneously.
This patch also fixes a minor error from PR#14243, where two patches
added the same information to different sections of tutorial.sav.
Index: client/gui-gtk-2.0/pages.c
===
--- client/gui-gtk-2.0/pages.c (revision 12991)
+++ client/gui-gtk-2.0/pages.c (working copy)
@@ -1825,23 +1825,28 @@
datafile_list_iterate(files, pfile) {
GtkTreeIter it;
struct section_file sf;
-char *description = NULL, *name = NULL;
+gtk_list_store_append(scenario_store, &it);
+
if (section_file_load_section(&sf, pfile->fullname, "scenario")) {
- name = secfile_lookup_str_default(&sf, NULL, "scenario.name");
- description = secfile_lookup_str_default(&sf,
+ char *sname = secfile_lookup_str_default(&sf, NULL, "scenario.name");
+ char *sdescription = secfile_lookup_str_default(&sf,
NULL, "scenario.description");
+
+ gtk_list_store_set(scenario_store, &it,
+0, sname ? Q_(sname) : pfile->name,
+1, pfile->fullname,
+2, sdescription ? Q_(sdescription) : "",
+ -1);
section_file_free(&sf);
+} else {
+ gtk_list_store_set(scenario_store, &it,
+0, pfile->name,
+1, pfile->fullname,
+2, "",
+ -1);
}
-/* Translated loaded names (if any). */
-name = name ? _(name) : pfile->name;
-description = description ? _(description) : "";
-
-gtk_list_store_append(scenario_store, &it);
-gtk_list_store_set(scenario_store, &it,
- 0, name, 1, pfile->fullname, 2, description, -1);
-
free(pfile->name);
free(pfile->fullname);
free(pfile);
Index: data/scenario/tutorial.sav
===
--- data/scenario/tutorial.sav (revision 12991)
+++ data/scenario/tutorial.sav (working copy)
@@ -455,7 +455,6 @@
randseed=0
save_random=0
rulesetdir="default"
-description="Tutorial Scenario."
[savefile]
options="startoptions spacerace2 rulesets diplchance_percent worklists2
map_editor known32fix turn attributes watchtower rulesetdir client_worklists
orders startunits turn_last_built improvement_order technology_order embassies"
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39396) BUG: 2.1.0b4 section_file_load_section
http://bugs.freeciv.org/Ticket/Display.html?id=39396 > S2_1 revision 12993 trunk revision 12994 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39364) 2.1.0b4 crash on opening scenarios screen
http://bugs.freeciv.org/Ticket/Display.html?id=39364 > S2_1 revision 12993 trunk revision 12994 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39394) Rigid border rules in S2_1
http://bugs.freeciv.org/Ticket/Display.html?id=39394 > Per I. Mathisen wrote: > Any replacement rule for borders has to not just generate nicer borders, > but be simple to understand as well. I have yet to find any such > replacement rule. If you have any, feel free to post it. Just saying "no > so rigid" or "more influences" does not help, unfortunately. > Is this a top priority item for 2.1? Or can it be handled in the future? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39364) 2.1.0b4 crash on opening scenarios screen
http://bugs.freeciv.org/Ticket/Display.html?id=39364 > Ulrik Sverdrup wrote: > I would like to help test the patch, however I have not been able to > reproduce the crash. I compiled S2_1 from svn just before this patch > with > ./configure --enable-client=gtk --disable-nls --disable-gtktest > which built the gtk2 client, on Ubuntu 6.10/ppc > That just means that somehow the string is in the same place in memory, section_file_free didn't wipe anything, so the pointer is still good. For whatever reason, that's not how it works here (MacOSX ppc). The patch itself (gtk_list_store_set before section_file_free) is simple. > I can start ./civ, click the scenario button, select a scenario a start > playing. > > Any ideas? What should I try to test this patch? > When I'm talking about further testing, it means using gdb and walking through the code to ensure it does everything as expected. (That's how the missing "part" parameter was found.) There's really no other way to test the section file routines. There are some commented out freelog lines that I'd activated during my testing, but very limited. Likewise, the gtk_list_store_set routines: do they actually copy and free the strings? I'm not sure, but it works (for me) now. The documentation (http://developer.gnome.org/doc/API/2.0/gtk/GtkListStore.html) says it does for some kinds of objects, but not for others. And the second Google hit is a complaint about "segmentation fault with a gtk_list_store_set", so it may be a common problem! Anyway, it took me several odd weekends (and 30 crash dumps) to understand the problem, as the code is not well documented. I kept getting frustrated and giving up and doing something else. What might be especially useful is to port the code to other clients. The name and description are only displayed for gtk. Or to improve the display in gtk, it's rather ugly. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39394) Rigid border rules in S2_1
http://bugs.freeciv.org/Ticket/Display.html?id=39394 > Per I. Mathisen wrote: >> The question: Is the fortress bug (you can build fortresses on enemy >> territory) important. Should it be fixed for 2.1? > > Yes. All bugs should be fixed... > In this case, my opinion is that you should be able to build fortresses on enemy territory, but they shouldn't affect the borders at all. Only actual population should affect the border. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39389) BUG: technology/advance name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39389 > Guest wrote: > ... but i don't think any freelog() message should be translated. > Am awaiting Per's decision on that matter. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39397) Freeciv 2.1 Beta crashes on New Game or Load Game
http://bugs.freeciv.org/Ticket/Display.html?id=39397 > Christian Knoke wrote: > 3: Don't have graphics tags or for tech_type Nichts ... > 0: Don't have graphics tags t.ocean1 or for base terrain Ocean > This looks like the same kind of thing reported in PR#39388. But I've had absolutely no luck replicating it. Works perfectly here, ./civ executed in the main directory. Could you send your exact compilation and execution commands? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39397) Freeciv 2.1 Beta crashes on New Game or Load Game
http://bugs.freeciv.org/Ticket/Display.html?id=39397 > Christian Knoke wrote: > 3: Don't have graphics tags or for tech_type Nichts Forgot to mention that there are longstanding bugs searching tech based on translated names instead of ruleset names, and I'm already working on that in PR#39389. We were distracted by a discussion about when freelog should be translated I'll commit something soon. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39401) r12999 trunk compile fails with new tolua
http://bugs.freeciv.org/Ticket/Display.html?id=39401 > ../../dependencies/tolua/tolua -n api -o ./api_gen.c -H ./api_gen.h ./api.pkg gcc -no-cpp-precomp -DHAVE_CONFIG_H -I. -I../.. -I../../utility -I../../common -I../../intl -I../../server -I../../dependencies/lua/src -I../../dependencies/tolua -Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -DLOCALEDIR="\"/Users/wastrel/freeciv-test/share/locale\"" -DDEFAULT_DATA_PATH="\".:data:~/.freeciv:/Users/wastrel/freeciv-test/share/freeciv\"" -g -O2 -Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -fsigned-char -MT api_gen.o -MD -MP -MF .deps/api_gen.Tpo -c -o api_gen.o api_gen.c api_gen.c:11:21: tolua++.h: No such file or directory api_gen.c:14: error: syntax error before "int" api_gen.c:14: error: parse error before '*' token api_gen.c:29: error: parse error before '*' token api_gen.c: In function `tolua_reg_types': api_gen.c:31: warning: implicit declaration of function `tolua_usertype' api_gen.c:31: error: `tolua_S' undeclared (first use in this function) api_gen.c:31: error: (Each undeclared identifier is reported only once api_gen.c:31: error: for each function it appears in.) api_gen.c: At top level: api_gen.c:46: error: parse error before '*' token api_gen.c: In function `tolua_get_Player_ai_control': api_gen.c:48: warning: implicit declaration of function `tolua_tousertype' api_gen.c:48: error: `tolua_S' undeclared (first use in this function) api_gen.c:50: warning: implicit declaration of function `tolua_error' api_gen.c:52: warning: implicit declaration of function `tolua_pushboolean' api_gen.c: At top level: api_gen.c:59: error: parse error before '*' token api_gen.c: In function `tolua_set_Player_ai_control': api_gen.c:61: error: `tolua_S' undeclared (first use in this function) api_gen.c:63: error: `tolua_Error' undeclared (first use in this function) api_gen.c:63: error: parse error before "tolua_err" api_gen.c:65: warning: implicit declaration of function `tolua_isboolean' api_gen.c:65: error: `tolua_err' undeclared (first use in this function) api_gen.c:68: warning: implicit declaration of function `tolua_toboolean' api_gen.c: At top level: api_gen.c:76: error: parse error before '*' token api_gen.c: In function `tolua_get_Player_name': api_gen.c:78: error: `tolua_S' undeclared (first use in this function) api_gen.c:82: warning: implicit declaration of function `tolua_pushstring' api_gen.c: At top level: api_gen.c:89: error: parse error before '*' token api_gen.c: In function `tolua_get_Player_nation_ptr': api_gen.c:91: error: `tolua_S' undeclared (first use in this function) api_gen.c:95: warning: implicit declaration of function `tolua_pushusertype' api_gen.c: At top level: api_gen.c:102: error: parse error before '*' token api_gen.c: In function `tolua_set_Player_nation_ptr': api_gen.c:104: error: `tolua_S' undeclared (first use in this function) api_gen.c:106: error: `tolua_Error' undeclared (first use in this function) api_gen.c:106: error: parse error before "tolua_err" api_gen.c:108: warning: implicit declaration of function `tolua_isusertype' api_gen.c:108: error: `tolua_err' undeclared (first use in this function) api_gen.c: At top level: api_gen.c:119: error: parse error before '*' token api_gen.c: In function `tolua_get_Player_ai': api_gen.c:121: error: `tolua_S' undeclared (first use in this function) api_gen.c: At top level: api_gen.c:132: error: parse error before '*' token api_gen.c: In function `tolua_set_Player_ai': api_gen.c:134: error: `tolua_S' undeclared (first use in this function) api_gen.c:136: error: `tolua_Error' undeclared (first use in this function) api_gen.c:136: error: parse error before "tolua_err" api_gen.c:138: error: `tolua_err' undeclared (first use in this function) api_gen.c: At top level: api_gen.c:149: error: parse error before '*' token api_gen.c: In function `tolua_get_Player_id': api_gen.c:151: error: `tolua_S' undeclared (first use in this function) api_gen.c:155: warning: implicit declaration of function `tolua_pushnumber' api_gen.c:155: error: `lua_Number' undeclared (first use in this function) api_gen.c:155: error: parse error before "self" api_gen.c: At top level: api_gen.c:162: error: parse error before '*' token api_gen.c: In function `tolua_get_City_name': api_gen.c:164: error: `tolua_S' undeclared (first use in this function) api_gen.c: At top level: api_gen.c:175: error: parse error before '*' token api_gen.c: In function `tolua_get_City_owner_ptr': api_gen.c:177: error: `tolua_S' undeclared (first use in this function) api_gen.c: At top level: api_gen.c:188: error: parse error before '*' token api_gen.c: In function `tolua_set_City_owner_ptr': api_gen.c:190: error: `tolua_S' undeclared (first use in this function) api_gen.c:192: error: `tolua_Error' undeclared (first use in this function) api_gen.c:192: error: parse error before "tolua_err" api_gen.c:194: error: `tolua_err' undeclared (first use in this function) api_gen.c
Re: [Freeciv-Dev] (PR#39389) BUG: technology/advance name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39389 > Per I. Mathisen wrote: > I do not really have much of an opinion on whether LOG_FATAL or LOG_ERROR > should be translated or not. However, LOG_VERBOSE and LOG_DEBUG should > never be translated - they are not meant for public consumption, just > debugging. > I found several instances of LOG_FATAL that SHOULD be translated, as they inform the user that no rulesets can be found, or that the savegame is too old, or uses a terrain ruleset that is no longer supported. The user wouldn't have any idea about the installation problem without translation. Otherwise, most are: /* TRANS: message for an obscure ruleset error. */ Those were eliminated. Such errors should be found before shipping, or are truly odd bugs that should be reported verbatim. I found many instances of LOG_ERROR that should be LOG_FATAL, as they are just before an exit or assert(FALSE). Otherwise, removed all translation of LOG_ERROR, LOG_VERBOSE and LOG_DEBUG in ruleset and savegame, and where the tech/advance was translated for a log message elsewhere. Also, based on other recent reports here, added the filename to most logging messages, so that we can figure out where problems are located. > LOG_NORMAL is used to display all the usual information in the server > command-line, so it should definitely be translated. > Agreed. In ruleset and savegame, those (both) are translated. Trunk revision 13000. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39401) r12999 trunk compile fails with new tolua
http://bugs.freeciv.org/Ticket/Display.html?id=39401 >
Per I. Mathisen wrote:
> http://bugs.freeciv.org/Ticket/Display.html?id=39401 >
>
> On Sun, 17 Jun 2007, William Allen Simpson wrote:
>> api_gen.c:11:21: tolua++.h: No such file or directory
>
> I think I fixed this now. Please test again (make sure recompile is
> forced).
>
No joy.
Tried touch api.pkg
Tried rm api_gen.*
make clean && make failed in the same place.
But I think I found another problem:
trunk/dependencies/tolua/tolua:2117: output('#include "tolua++.h"\n\n')
It might be simpler to rename it back to tolua++.h and be done with it!
There are 19 occurrences in 10 files. (Some are documentation.)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39386) cleanup tilespec.c
http://bugs.freeciv.org/Ticket/Display.html?id=39386 > The rather different code in S2_1 was difficult to compare without straightening it, too. This makes the differences more apparent, and hopefully will assist debugging recent reports of load failures in certain configurations. Committed S2_1 revision 13003. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39389) BUG: technology/advance name translation
http://bugs.freeciv.org/Ticket/Display.html?id=39389 > Combined with (PR#39386) cleanup tilespec.c in hopes of debugging recent reports of tile load failures in certain configurations. The freelog removal of translation (in most cases) should clarify the file and rule names as they are loaded. There are no new strings to be translated. (Many obscure error messages are no longer used.) Committed S2_1 revision 13003. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
Per Inge Mathisen wrote: > I tried unsucessfully to update trunk to latest lua and tolua versions. > For some reasons I could not figure out, tolua generated a bad api_gen.c, > and the makefile did not regenerate this file for me and thus alert me to > the problems before I had already committed the changes. Even 'make > maintainer-clean' did not clean out these files. > It has been apparent for some time that the makefiles need work! > So I had to roll back the repository to the state before I started the > upgrade. This generates some unfortunate svn noise, and William's r13000 > is gone. I am really sorry about that. > That's OK, I try to save everything. My usual series of commands just before commit is (for example): svn up make >&../xxx svn diff >../du.12993 svn ci -F ../ci.log.12993 Yep, I save the command history, too I've been a consultant for ~25 years, so I'm fairly compulsive about logging. ;-) And I'm pretty sure that it is possible to regenerate the diffs from different svn versions, too. But it's not a command that I use regularly, so I'd have to read the manual > Speaking of r13000, I would very much like to see it go in in smaller > chunks which are easier to manage when debugging using svn. > Sorry, but these are each tiny changes to a single header file, affecting many, many files. I've been doing them in as small increments as possible. (I was actually thinking about trying *larger* combined ones, hoping that would be *less* disruptive. But I'll stick to one .h at a time for now.) > Also, while on the topic of api_gen.c|h, I do not see why these > automatically generated source files are in the repository? All the tools > required to generate them are already in the repository. > I agree. And there was a part of a bug report by a translator on another list that indicated a problem with keeping them in sync (or something). Anyway, I'll just poke at S2_1 while you are fixing up trunk. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39397) Freeciv 2.1 Beta crashes on New Game or Load Game
http://bugs.freeciv.org/Ticket/Display.html?id=39397 > Christian Knoke wrote: > svn update > ./autogen.sh > make > su -c "make install" > civclient > > ~$ which civclient > /usr/local/bin/civclient > Thank you, very helpful. The major difference between your test and my test: I'm running in the build directory with ./civ, not an install directory. However, when I "make install" (in my local test directory), there are still no errors in loading rulesets. The civclient won't execute civserver, while civserver doesn't seem to find ~/.freeciv/saves, but those are probably different issues Both load the rulesets! So, I've updated the verbose logging. If you would kindly update to r13003, run with verbose, and post the log (or a relevant excerpt), that should pinpoint any problems. civserver --log server.log --debug 3 civclient --log client.log --debug 3 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
William Allen Simpson wrote: > Per Inge Mathisen wrote: >> Also, while on the topic of api_gen.c|h, I do not see why these >> automatically generated source files are in the repository? All the >> tools required to generate them are already in the repository. >> > I agree. And there was a part of a bug report by a translator on another > list that indicated a problem with keeping them in sync (or something). > I've just looked at the trunk/server/scripting/.svn/dir-prop-base It appears that api_gen.h and .c were already set to be ignored, along with Makefile Makefile.in api_gen.c api_gen.h .deps libscripting.a AFAIK, all that needs to be done is "svn delete" them, and they should go away. Somebody must have deliberately added them in the past? svn ci -m "delete api_gen.*" Deleting scripting/api_gen.c Deleting scripting/api_gen.h Committed revision 13004. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
William Allen Simpson wrote: > AFAIK, all that needs to be done is "svn delete" them, and they should go > away. Somebody must have deliberately added them in the past? > Yes, for cross compiling from linux to windows in: http://bugs.freeciv.org/Ticket/Display.html?id=13571 There is a better way. Generate your tools into a tools/bin, then cross compile. It isn't too hard. I'll look into it. (Do we really cross-compile releases?) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
Question: is tolua used for anything other than pre-compilation? That is, AFAICT tolua is only used to build api_gen.* Therefore, tolua would never be anything other than natively compiled, and would not be distributed in a binary distribution? Only lua would be generated for the target distribution? My suggestion is that we: 1) get tolua++ installed and running in the trunk, 2) then test cross-compilation, 3) then upgrade lua itself afterward. My observation is that the main problem we experienced was trying to change from tolua++.h to tolua.h. Therefore, I also suggest that we not change the header. It seems to be too embedded in the tolua++ expectations. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
Per I. Mathisen wrote: > On Mon, 18 Jun 2007, William Allen Simpson wrote: >> My observation is that the main problem we experienced was trying to >> change >> from tolua++.h to tolua.h. > > No, that was just an amusing side-show. The problem was that tolua++ > generated a faulty api_gen.c file. > OK, my order of suggestions was based on the PR#39400 problem with tolua. Christian didn't report a problem with lua. In fact, he indicates that the his sarge box works with lua (an external lib?) Maybe we should reverse my suggestion. 1) install the latest lua. Make sure it works. Surely the latest lua will still work with the older tolua! 2) reorganize the tolua tree a little bit to be compiled by "make tools" -- so that cross-compiling works correctly. 3) then, knowing that everything else works, try installing tolua++. Narrow the problems to a single point of failure. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
Per Inge Mathisen wrote: > On 6/18/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: >> 1) install the latest lua. Make sure it works. Surely the latest lua will >> still work with the older tolua! > > No, tolua 5.0 does not work with lua 5.1, unfortunately. And there is > no more recent version of tolua, hence the use of tolua++, a more up > to date derivative version. > Ah. So it has to be tolua first. According to the documentation, tolua++ will work with both lua 5.0 and 5.1. OK, we have a plan. === Unfortunately, tolua++ doesn't seem to be widely available as an external package. It has to be in the source tree. However, I checked my current favorite platforms (MacPorts, NetBSD pkgsrc, debian, Ubuntu), and all of them have lua 5.1.2 as packages. I'm thinking that maybe the way to go with lua is the same as gettext -- change to a build option, but allow an up-to-date external library for most folks. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39403) BUG: 2.1.0b4 MacOSX 3.9 fails to find libintl.h
http://bugs.freeciv.org/Ticket/Display.html?id=39403 > Apparently not using the CPPFLAGS? === export LDFLAGS="-L/opt/local/lib" export CPPFLAGS="-I/opt/local/include" export CC="gcc -no-cpp-precomp" ./autogen.sh --enable-nls --enable-client=gtk2 --prefix=/Users/wastrel/freeciv-i18n ... + checking for xgettext >= 0.10.36 ... found 0.16.1, ok. ... checking whether NLS is requested... yes checking whether included gettext is requested... no checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for GNU gettext in libc... no checking for GNU gettext in libintl... yes checking for dcgettext... yes checking for msgfmt... /opt/local/bin/msgfmt checking for gmsgfmt... /opt/local/bin/msgfmt checking for xgettext... /opt/local/bin/xgettext ... checking for ngettext in -lc... no checking for ngettext in -lintl... yes checking whether libintl's ngettext works at runtime... yes checking for GNU xgettext version >= 0.10.36... yes checking for GNU msgfmt version >= 0.10.35... yes ... === gcc -no-cpp-precomp -DHAVE_CONFIG_H -I. -I.. -I../intl -Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -DLOCALEDIR="\"/Users/wastrel/freeciv-i2_1/share/locale\"" -DDEFAULT_DATA_PATH="\".:data:~/.freeciv:/Users/wastrel/freeciv-i2_1/share/freeciv\"" -g -O2 -Wall -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -fsigned-char -MT fciconv.o -MD -MP -MF .deps/fciconv.Tpo -c -o fciconv.o fciconv.c In file included from fciconv.c:36: fcintl.h:23:21: libintl.h: No such file or directory fciconv.c: In function `init_character_encodings': fciconv.c:120: warning: implicit declaration of function `bind_textdomain_codeset' fciconv.c: In function `convert_string': fciconv.c:206: warning: implicit declaration of function `gettext' fciconv.c:206: warning: passing arg 2 of `real_freelog' makes pointer from integer without a cast make[3]: *** [fciconv.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 === FlatLand:~/Projects/freeciv_stable/i2_1 wastrel$ locate libintl.h /opt/local/include/libintl.h /opt/local/var/db/dports/software/gettext/0.16.1_0/opt/local/include/libintl.h ... FlatLand:~/Projects/freeciv_stable/i2_1 wastrel$ env LDFLAGS=-L/opt/local/lib TERM_PROGRAM=Apple_Terminal TERM=xterm-color SHELL=/bin/bash CPPFLAGS=-I/opt/local/include ... ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39403) BUG: 2.1.0b4 CPPFLAGS ignored and other makefile oddities
http://bugs.freeciv.org/Ticket/Display.html?id=39403 > Must be using old instructions. Found some newer ones at: http://freeciv.wikia.com/wiki/Install-MacOSX There, it specifies putting them all in the CC variable: export CC="gcc -no-cpp-precomp -I/opt/local/include -L/opt/local/lib" Not traditional, but that works (at least it compiles with only warnings). Still, CFLAGS and CPPFLAGS are the traditional method, and something is definitely wrong with the configure I found PR#35785, so it's a relatively new problem, but it's been reported before. http://bugs.freeciv.org/Ticket/Display.html?id=35785 Also, note that the -W options appear twice on each command line. Very odd! Who's the configure/makefile expert for the project? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
Per I. Mathisen wrote: > BTW, the sources need some changes to work with new lua and tolua > versions, as you can see in r12995-9, and I am not sure if those changes > are compatible with older lua versions. > Well, I expect to find out over the next couple of days :-) I'm putting the tolua++ in its own subdirectory, so it will compile and not interfere with the older tolua in my build tree. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39406) Is S2_1 clients compilation broken?
http://bugs.freeciv.org/Ticket/Display.html?id=39406 > Egor Vyscrebentsov wrote: > svn branches/S2_1 rev 13004. > > gui-xaw and gui-gtk-2.0 do not compiled on my machine with > following error: > > freeciv-s2_1/client/packhand.c: In function ‘handle_ruleset_building’ > freeciv-s2_1/client/packhand.c:2249: error: ‘advance’ undeclared (first use > in this function) > freeciv-s2_1/client/packhand.c:2249: error: (Each undeclared identifier is > reported only once > freeciv-s2_1/client/packhand.c:2249: error: for each function it appears in.) > make[3]: *** [packhand.o] Error 1 > > What to do? (c) > Line 2249 is in the middle of an #ifdef DEBUG section, so it never was compiled here. Looks like an 's' is missing on "advances". svn ci -m "(PR#39406) correct misspelling in DEBUG section" Sendingclient/packhand.c Transmitting file data . Committed revision 13005. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39388) S2_1 trident missing t.ocean1
http://bugs.freeciv.org/Ticket/Display.html?id=39388 > Daniel Markstedt wrote: > On 6/10/07, William Allen Simpson <[EMAIL PROTECTED]> wrote: >> What tileset? >> > Any. > Using my improved error logging (most recently r13003 for S2_1), we discovered that this was not accurate. As I mentioned in the previous message, all the S2_1 tilesets have t.ocean1, except for trident. I've wasted far too many cycles trying to figure out what's wrong with amplio (the default). Sure enough, the new verbose output is: 3: Reading registry from "/Users/daniel/freeciv-beta-gtk/share/freeciv/trident/units.spec" 3: Reading registry from "/Users/daniel/freeciv-beta-gtk/share/freeciv/trident/tiles.spec" 0: Don't have graphics tags "t.ocean1" or "" for base (blend) terrain "Ocean". This is not a problem with "any" tileset, it's a problem with trident! That's no surprise, as trident doesn't have blending I've checked trident/tiles.spec back to 1.14, and there's never been any t.ocean1, so it appears an old logic error in the code. Looks like improved error logging actually found it! Unfortunately, it's rather obscure code. :-( It's been completely re-written in trunk. :-) If possible, I'll make it more like trunk. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39397) 2.1.0 Beta missing graphics for trident Ocean and tech Nichts
http://bugs.freeciv.org/Ticket/Display.html?id=39397 > As I was looking for similar reports, I discovered that you've been reporting the same Ocean problem since beta 1 #16078: Beta1: civclient crash on game load http://bugs.freeciv.org/Ticket/Display.html?id=16078 SVN 2.1 22 MAR 2006 GTK2 Linux civclient crashes with a segmaentation fault on loading the attached save game (and HEAD does as well). civlient -d 3 says: [...] 3: Don't have graphics tags a.writing or - for tech_type Schrift 3: Don't have graphics tags t.ocean1 or for tile_type Ozean Speicherzugriffsfehler (core dumped) ... Starting civserver seperately avoids the crash. That's classic sign of an uninitialized pointer! (The location moves depending on the other applications loaded.) Also: (PR#16007) Beta1: civclient crash on game load http://bugs.freeciv.org/Ticket/Display.html?id=16007 (PR#16101) Beta1: civclient crash on game load http://bugs.freeciv.org/Ticket/Display.html?id=16101 (PR#16103) Beta1: civclient crash on game load http://bugs.freeciv.org/Ticket/Display.html?id=16103 Meanwhile, it was also diagnosed with another problem (nationgroups) that was fixed. Sometimes multiple problems mask each other. Now, my improved error logging catches the missing ocean graphic. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39388) S2_1 trident missing t.ocean1
http://bugs.freeciv.org/Ticket/Display.html?id=39388 >
The ancient bug had been fixed in trunk months ago.
Tested against all 5 tilesets.
Committed S2_1 revision 13006.
Index: client/tilespec.c
===
--- client/tilespec.c (revision 13005)
+++ client/tilespec.c (working copy)
@@ -2638,7 +2638,6 @@
/* Set up each layer of the drawing. */
for (l = 0; l < draw->num_layers; l++) {
sprite_vector_init(&draw->layer[l].base);
-sprite_vector_reserve(&draw->layer[l].base, 1);
switch (draw->layer[l].cell_type) {
case CELL_SINGLE:
@@ -2673,7 +2672,6 @@
lookup_sprite_tag_alt(t, buffer, "", TRUE, "matched terrain",
pterrain->name_rule);
}
- draw->layer[l].base.p[0] = draw->layer[l].match[0];
break;
};
break;
@@ -2779,10 +2777,6 @@
};
}
}
- my_snprintf(buffer, sizeof(buffer), "t.%s1", draw->name);
- draw->layer[l].base.p[0]
-= lookup_sprite_tag_alt(t, buffer, "", TRUE, "base (blend) terrain",
-pterrain->name_rule);
break;
};
}
@@ -2795,6 +2789,14 @@
};
enum direction4 dir;
+if (draw->layer[0].base.size < 1) {
+ my_snprintf(buffer, sizeof(buffer), "t.%s1", draw->name);
+ sprite_vector_reserve(&draw->layer[0].base, 1);
+ draw->layer[0].base.p[0]
+ = lookup_sprite_tag_alt(t, buffer, "", TRUE, "base (blend) terrain",
+ pterrain->name_rule);
+}
+
for (dir = 0; dir < 4; dir++) {
assert(sprite_vector_size(&draw->layer[0].base) > 0);
draw->blend[dir] = crop_sprite(draw->layer[0].base.p[0],
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
It appears that tolua++ is a dead end. It hasn't had any fixes for over a year, and the version 1.0.92 doesn't compile as distributed. I have no confidence in a coder that accidentally deleted the include of the primary header file. Clearly somebody that doesn't compile before commit (and has lost interest in fixing obvious bugs): --- dependencies/tolua/tolua_event.c(revision 13006) +++ dependencies/tolua/tolua_event.c(working copy) -#include "tolua_event.h" -#include "tolua.h" +#include "tolua++.h" === I fixed the compilation (there are a couple more errors), but the output still has another bug, somehow not converting its internal representation "_cstring" to "char *": api_gen.c: In function `tolua_api__00': api_gen.c:1384: error: `_cstring' undeclared (first use in this function) api_gen.c:1384: error: (Each undeclared identifier is reported only once api_gen.c:1384: error: for each function it appears in.) api_gen.c:1384: error: parse error before "const" api_gen.c:1386: error: `tolua_var_1' undeclared (first use in this function) api_gen.c: In function `tolua_api_N_00': api_gen.c:1413: error: `_cstring' undeclared (first use in this function) api_gen.c:1413: error: parse error before "const" api_gen.c:1415: error: `tolua_var_2' undeclared (first use in this function) api_gen.c: In function `tolua_api_Q_00': api_gen.c:1442: error: `_cstring' undeclared (first use in this function) api_gen.c:1442: error: parse error before "const" api_gen.c:1444: error: `tolua_var_3' undeclared (first use in this function) === There is another coder that's been working on a successor called toluaxx, and has commits as recently as 2 months ago. I'll try that tomorrow. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk lua mess
William Allen Simpson wrote: > It appears that tolua++ is a dead end. It hasn't had any fixes for > over a year, and the version 1.0.92 doesn't compile as distributed. >... > There is another coder that's been working on a successor called toluaxx, > and has commits as recently as 2 months ago. I'll try that tomorrow. > As I wrap my head around this junk Both tolua and tolua++ are actually lua programs, used lua as an external program, running it on themselves, and then distributed the resulting C. Clever bootstrapping. In the past, freeciv safely ignored the *.lua files and compiled the C, running the resulting binary program in place. Instead, toluaxx assumes the existance of an external lua, and distributes the *.lua (renamed from tolua++) with its own command parser. It runs itself interpreted. Probably easier for developers to build and maintain. Therefore, freeciv will require the existence of a lua main binary, as well as the lua runtime libraries it needs to link. So, freeciv will need --with-included-lua (like gettext), and/or an external package. Likewise, freeciv will need --with-included-toluaxx, as toluaxx might be an external package, too. OK, I kinda-sorta understand the build requirements. Where should the standalone "included-lua" binary reside? Remember, it will be built *prior* to building toluaxx and/or cross-compiling, it cannot be in the lua/src directory. In bootstrap? Finally, could somebody explain why lua is important? It's hardly used! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39411) [patch] gov icons in tech tree show up misaligned
http://bugs.freeciv.org/Ticket/Display.html?id=39411 > Excellent catch! (Also, fixed some indentation here.) Committed S2_1 revision 13012, trunk revision 13013. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
