[Freeciv-Dev] (PR#40069) server crash 2
http://bugs.freeciv.org/Ticket/Display.html?id=40069 > Looks identical (or at least indistinguishable) from PR#40068. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40068) server crash
http://bugs.freeciv.org/Ticket/Display.html?id=40068 > > [wsimpson - Sat Feb 02 23:07:04 2008]: > > Jason Short wrote: > > Looks to me like this means dsite->location is invalid. I have no > > familiarity with this code however. > > > That's (my) very new border code. I'll take a look at it. > > What I don't understand is why it's not reproducible? Usually, that > means > an uninitialized variable, but all these structures are zeroed with > calloc(), > so that's unlikely Saving and loading doesn't generally give identical AI behavior so if this is caused by AI units moving or something then you won't get the same behavior from the savegame most likely. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40070) Server crash 3
http://bugs.freeciv.org/Ticket/Display.html?id=40070 > get_city_bonus is passing in a NULL city. This is allowed according to the effects interface (undocumented of course) but because it calls city_owner that function now segfaults on it. I have no definite opinion on whether NULL targets are worthwhile for get_xxx_bonus functions, but the function docs do need to specify. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40070) common/effect.c get_city_bonus() with NULL city
http://bugs.freeciv.org/Ticket/Display.html?id=40070 > This will be applicable to all branches! In 2.1, has 60 occurrences in 20 files. In 2.2, has 63 occurrences in 23 files. In this case, the code already has a FIXME over two years old! It clearly indicates: /* It is a virtual unit, so must start in a city... */ struct city *pcity = tile_city(punit->tile); /* The default is to lose 100%. The growth bonus reduces this. */ int foodloss_pct = 100 - get_city_bonus(pcity, EFT_GROWTH_FOOD); There's no question that pcity should *not* be NULL. My guess is this is another bug related to old/new border calculation, as in PR#40069, because there's been a long history of problems with the tile not pointing to the expected city. One of the problems that new deterministic border code was made to correct! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40069) end_turn() => map_calculate_borders() has bad site->location
http://bugs.freeciv.org/Ticket/Display.html?id=40069 > In this report, tile0=0x2b. In PR#40068, tile0=0x4, and the client crashed, too. Let's keep this separate, to deal with the border recalculation issue. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40070) common/effects.c get_city_bonus() with NULL city
http://bugs.freeciv.org/Ticket/Display.html?id=40070 > In this case, the traceback clearly shows the NULL city: city_owner (pcity=0x0) at city.c:654 That's properly failing checks added by PR#39998 and PR#39895 respectively: assert(NULL != pcity && NULL != pcity->owner); But for the record, and as a reminder to myself, this assert should probably be split into two lines for better traceback indication. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40068) client gtk_progress_set_percentage() assertion
http://bugs.freeciv.org/Ticket/Display.html?id=40068 > Jason Short wrote: > Saving and loading doesn't generally give identical AI behavior so if > this is caused by AI units moving or something then you won't get the > same behavior from the savegame most likely. > I've argued about this before (PR#39365), and it damn well SHOULD! I've spent a fair amount of time getting 2.1 to be reproducible, by checking and saving all myrand() states. Time to do again for 2.2! (Necessary, but tedious. Another ticket for another time.) Meanwhile, this report has two problems listed. Let's dedicate it to solving the client issue (leaving the server issue for the next ticket): (civclient:17913): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion `percentage >= 0 && percentage <= 1.0' failed 2: Verbindung zum Server verloren! The civclient.c line number is bogus, there are currently 807 lines. The log message is merely: #: client/clinet.c:143 client/clinet.c:144 msgid "Lost connection to server!" msgstr "Verbindung zum Server verloren!" So, how is gtk_progress_set_percentage() called? There's no direct reference anywhere in the code, and nothing seems relevant in clinet.c at all! It's probably unrelated. Anybody out there understand the GTK2 client enough to track this down? ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40068) client gtk_progress_set_percentage() assertion
http://bugs.freeciv.org/Ticket/Display.html?id=40068 > Christian Knoke wrote: > These 2 messages needn't necessarly be connected. I just copied the outbut > on the terminal after the crash. > Yes, and that's excellent bug reporting practice! That tells us that the client asserted sometime before the server died. Apparently, the assert() in GTK2 doesn't stop the client, unlike the assert() in the server But in any case, this client GTK2 message is something I've never seen, and we should figure out what happened. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40068) client gtk_progress_set_percentage() assertion
http://bugs.freeciv.org/Ticket/Display.html?id=40068 > Du schriebst am 03. Feb um 04:30 Uhr: > (civclient:17913): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion > `percentage >= 0 && percentage <= 1.0' failed > 2: Verbindung zum Server verloren! These 2 messages needn't necessarly be connected. I just copied the outbut on the terminal after the crash. Christian -- Christian Knoke* * *http://cknoke.de * * * * * * * * * Ceterum censeo Microsoft esse dividendum. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40071) i18n: review LOG_FATAL and freeciv.org
http://bugs.freeciv.org/Ticket/Display.html?id=40071 > Committed trunk revision 14376. Committed S2_2 revision 14377, with update-po to add TRANS comments. Reminder, ./autogen.sh before make! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40025) Happiness plurals
http://bugs.freeciv.org/Ticket/Display.html?id=40025 > I have been playing a game lately, and watching what happens as the size of my empire increases. I believe this effect of additional unhappy citizens didn't happen in 2.0 (at least, that would explain why, when I imported an almost perfect saved game from 2.0 into 2.1, half my cities where in turmoil). I have reached 80 cities in democracy now, and I have more unhappy citizens (5) than initial content citizens (4). I don't know whether this is a bug or a feature, but William is right that the message should be more informative, and perhaps the help texts should be improved, too. What I would like to see here is some info about the total number of cities, how many content citizens have cities by default, and a warning on when this figure will change. Maybe something like: 40 cities, 10 above the limit of 30, 4 below 44. First 2 citizens content, next 2 unhappy. 80 cities, on the limit of 80, 14 below 94. First 4 citizens unhappy, next 1 angry. I'm not sure I have grasped the rule, though, and the figures are more or less invented. The only explanation I have found of this rule in the help texts is in some governments, and in the help for the variables cityfactor and unhappysize. It doesn't make much sense, though. My cityfactor is 14; however the help for Democracy says "for each 16 additional cities another unhappy citizen will appear." Furthermore, for Communism there is no mention of this rule (why? all the others have it) Cheers, Joan 2008/1/23, William Allen Simpson <[EMAIL PROTECTED]>: > > > http://bugs.freeciv.org/Ticket/Display.html?id=40025 > > > Committed S2_2 revision 14284. > Committed trunk revision 14285. > > Still open awaiting win32 verification. > > Also hoping for better sentences for 2.2 and later. > > I have been playing a game lately, and watching what happens as the size of my empire increases. I believe this effect of additional unhappy citizens didn't happen in 2.0 (at least, that would explain why, when I imported an almost perfect saved game from 2.0 into 2.1, half my cities where in turmoil). I have reached 80 cities in democracy now, and I have more unhappy citizens (5) than initial content citizens (4). I don't know whether this is a bug or a feature, but William is right that the message should be more informative, and perhaps the help texts should be improved, too. What I would like to see here is some info about the total number of cities, how many content citizens have cities by default, and a warning on when this figure will change. Maybe something like:40 cities, 10 above the limit of 30, 4 below 44. First 2 citizens content, next 2 unhappy. 80 cities, on the limit of 80, 14 below 94. First 4 citizens unhappy, next 1 angry.I'm not sure I have grasped the rule, though, and the figures are more or less invented.The only explanation I have found of this rule in the help texts is in some governments, and in the help for the variables cityfactor and unhappysize. It doesn't make much sense, though. My cityfactor is 14; however the help for Democracy says "for each 16 additional cities another unhappy citizen will appear." Furthermore, for Communism there is no mention of this rule (why? all the others have it)Cheers,Joan2008/1/23, William Allen Simpson <[EMAIL PROTECTED]>: http://bugs.freeciv.org/Ticket/Display.html?id=40025 >Committed S2_2 revision 14284.Committed trunk revision 14285.Still open awaiting win32 verification. Also hoping for better sentences for 2.2 and later. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40025) Happiness plurals
http://bugs.freeciv.org/Ticket/Display.html?id=40025 > Joan Creus wrote on Feb 03, 06:40 (-0800): > > http://bugs.freeciv.org/Ticket/Display.html?id=40025 > > > I have been playing a game lately, and watching what happens as the size of > my empire increases. I believe this effect of additional unhappy citizens > didn't happen in 2.0 (at least, that would explain why, when I imported an > almost perfect saved game from 2.0 into 2.1, half my cities where in > turmoil). This is in there since some time of 2.1. Something has been changed intendedly, I don't remember what it was. I have noticed this earlier and complained about. It is impossible now to grow large empires (with happiness), and it may be very hard to at least manage them. I don't like it very much. Christian -- Christian Knoke* * *http://cknoke.de * * * * * * * * * Ceterum censeo Microsoft esse dividendum. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Request: Option for behavior of specials while terraforming in game setup?
It seems that through various versions of Freeciv, the behavior of specials squares when they were terraformed has been changed. I propose that one could choose from a list of possible behaviors when setting up the game, rather than taking the option out of the game creator's hands. This could be done as a server setting, and it would be simple to re-implement the old settings, but what would be ideal would be putting a *large* range of options available as a user-controlled setting. Here is an example of how I would describe various options: 1.) It rerolls whether or not there is a special whenever the land type is changed, and the new special will always be appropriate to the land type, even if land is changed to water or vice versa 2.) The special simply stays, but land specials always stay on land, and if it is changed to water, it goes away, and water specials can never be on land 3.) It changes to whichever tier of special is appropriate for the new land type, (ie, so if you change a land special to swamp, it will either be peat or spice, depending on wcich "side" the special was on) (of course, if land is changed to water or vice versa, the special goes away) 4.) It changes an existing special to a random special of the appropriate type (so if you changed a plains/wheat to swamp, it would have a 50/50 chance of being peat or spice) (of course, if land is changed to water or vice versa, the special goes away...) 5.) when the special is changed to another type of terrain, the special is always removed. 6.) Like 3, but water specials stay 7.) like 4, but water specials stay This would allow people to customize the utility of terraforming specials in game, which expands gameplay options. Does anyone have any thoughts about this? Also, I have attempted to send this request before, but I haven't been able to. Thanks! Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40073) BUG: 2.2-test AI building_want random interval not saved/restored
http://bugs.freeciv.org/Ticket/Display.html?id=40073 >
There's a problem with reproducing reports for 2.2 savegames. Over the past
9 months, I've spent considerable time improving the reproducibility of 2.1
(PR#39365, PR#39572, etc.)
Searching for myrand() differences between 2.1 and 2.2, found only 1 more
variable, added by PR#12682. It is used as both an interval *and* a "weight"
multiplier for calculating AI wants.
Renamed it to ai.building_wait, and save/restore it. (Yes, that's punny.)
Renamed the related AI "recalc" variables to have the same prefix_* as the
corresponding *_want counterparts (matching the names in the savegames).
Moved the pseudo-random equation from tilespec into rand, making it easier
to find, trace, and use elsewhere.
Other trivial cleanup.
Index: utility/rand.c
===
--- utility/rand.c (revision 14377)
+++ utility/rand.c (working copy)
@@ -78,8 +78,8 @@
directly representable in type RANDOM_TYPE, so we do instead:
divisor = MAX_UINT32/size
*/
-RANDOM_TYPE myrand_debug(RANDOM_TYPE size, const char *called_as, int line,
- const char *file)
+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;
@@ -110,8 +110,8 @@
rand_state.v[rand_state.x] = new_rand;
if (++bailout > 1) {
- freelog(LOG_ERROR, "%s(%lu) = %lu bailout at line %d of %s",
- called_as, (unsigned long)size, (unsigned long)new_rand, line,
file);
+ freelog(LOG_ERROR, "%s(%lu) = %lu bailout at %s:%d",
+ called_as, (unsigned long)size, (unsigned long)new_rand, file,
line);
new_rand = 0;
break;
}
@@ -124,8 +124,8 @@
new_rand = 0;
}
- freelog(LOG_RAND, "%s(%lu) = %lu at line %d of %s",
- called_as, (unsigned long)size, (unsigned long)new_rand, line,
file);
+ freelog(LOG_RAND, "%s(%lu) = %lu at %s:%d",
+ called_as, (unsigned long)size, (unsigned long)new_rand, file,
line);
return new_rand;
}
@@ -248,3 +248,31 @@
/* restore state: */
set_myrand_state(saved_state);
}
+
+/*
+ Local pseudo-random function for repeatedly reaching the same result,
+ instead of myrand(). Primarily needed for tiles.
+
+ Use an invariant equation for seed.
+ Result is 0 to (size - 1).
+*/
+RANDOM_TYPE myrandomly_debug(RANDOM_TYPE seed, RANDOM_TYPE size,
+const char *called_as, int line, const char *file)
+{
+ RANDOM_TYPE result;
+
+#define LARGE_PRIME (10007)
+#define SMALL_PRIME (1009)
+
+ /* Check for overflow and underflow */
+ assert((int)(seed * LARGE_PRIME) > 0);
+ assert(size < SMALL_PRIME);
+ assert(size > 0);
+ result = ((seed * LARGE_PRIME) % SMALL_PRIME) % size;
+
+ freelog(LOG_RAND, "%s(%lu,%lu) = %lu at %s:%d",
+ called_as, (unsigned long)seed, (unsigned long)size,
+ (unsigned long)result, file, line);
+
+ return result;
+}
Index: utility/rand.h
===
--- utility/rand.h (revision 14377)
+++ utility/rand.h (working copy)
@@ -26,8 +26,8 @@
bool is_init;/* initially 0 for static storage */
} RANDOM_STATE;
-#define myrand(vsize) myrand_debug((vsize), "myrand", \
-__LINE__, __FILE__)
+#define myrand(_size) \
+ myrand_debug((_size), "myrand", __LINE__, __FILE__)
RANDOM_TYPE myrand_debug(RANDOM_TYPE size, const char *called_as,
int line, const char *file);
@@ -40,4 +40,12 @@
void test_random1(int n);
+/*===*/
+
+#define myrandomly(_seed, _size) \
+ myrandomly_debug((_seed), (_size), "myrandomly", __LINE__, __FILE__)
+
+RANDOM_TYPE myrandomly_debug(RANDOM_TYPE seed, RANDOM_TYPE size,
+const char *called_as, int line, const char *file);
+
#endif /* FC__RAND_H */
Index: server/stdinhand.c
===
--- server/stdinhand.c (revision 14377)
+++ server/stdinhand.c (working copy)
@@ -2357,7 +2357,6 @@
} else {
pcity->debug = TRUE;
CITY_LOG(LOG_TEST, pcity, "debugged");
- pcity->ai.next_recalc = 0; /* force recalc of city next turn */
}
} else if (ntokens > 0 && strcmp(arg[0], "units") == 0) {
int x, y;
Index: server/savegame.c
===
--- server/savegame.c (revision 14377)
+++ server/savegame.c (working copy)
@@ -2533,21 +2533,30 @@
worklist_load(file, &pcity->worklist, "player%d.c%d", plrno, i);
/* FIXME: remove this when the urgency is properly rec
Re: [Freeciv-Dev] (PR#40072) map displays wrong nation for enemy city
http://bugs.freeciv.org/Ticket/Display.html?id=40072 > Thanks, looking ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40025) Happiness plurals
http://bugs.freeciv.org/Ticket/Display.html?id=40025 > Christian Knoke wrote: > This is in there since some time of 2.1. Something has been changed > intendedly, I don't remember what it was. > Wasn't paying much attention at the time, but it made the empire happiness code actually work! As it was intended! The default settings still aren't as stringent as commercial civ, where the effects kick in at 10 > I have noticed this earlier and complained about. It is impossible > now to grow large empires (with happiness), and it may be very hard to > at least manage them. > Well, you can always change the settings for a new ruleset: data/default/effects.ruleset: Empire_Size_Base Empire_Size_Step That's what Joan was asking for: better documentation. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40025) Happiness plurals
http://bugs.freeciv.org/Ticket/Display.html?id=40025 > 2008/2/3, Christian Knoke <[EMAIL PROTECTED]>: > > > http://bugs.freeciv.org/Ticket/Display.html?id=40025 > > > > This is in there since some time of 2.1. Something has been changed > intendedly, I don't remember what it was. > > I have noticed this earlier and complained about. It is impossible > now to grow large empires (with happiness), and it may be very hard to > at least manage them. It is indeed more challenging. By now, I am doing fine against the "hard" IAs with 80 cities in democracy. I always build ports when I can, and lots of Markets and trade routes. Michelangelo's and J.S. Bach's are essential, of course. I could probably win soon by building the spaceship, but I'll try to take over all the cities and see whether I can prevent revolutions. Joan 2008/2/3, Christian Knoke <[EMAIL PROTECTED]>: http://bugs.freeciv.org/Ticket/Display.html?id=40025 >This is in there since some time of 2.1. Something has been changedintendedly, I don't remember what it was. I have noticed this earlier and complained about. It is impossiblenow to grow large empires (with happiness), and it may be very hard toat least manage them.It is indeed more challenging. By now, I am doing fine against the "hard" IAs with 80 cities in democracy. I always build ports when I can, and lots of Markets and trade routes. Michelangelo's and J.S. Bach's are essential, of course. I could probably win soon by building the spaceship, but I'll try to take over all the cities and see whether I can prevent revolutions. Joan ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Request: Option for behavior of specials while terraforming in game setup?
Jonathan Kaplan wrote: > ... but what would be > ideal would be putting a *large* range of options available as a > user-controlled setting. Shudder. That's horrible. How do you test? Remember, this has to handle civ1/2/3-like games, so civ1 Swamp resource Oil has to turn into civ2 Peat, and then civ3 Oil again, depending on the *same* game loading a different ruleset. Likewise, Tundra, Desert, etc. All while the terrain is irrigated/mined/transformed. The reason that the old Freeciv behaviors were changed it that the code didn't actually work well -- Fish on land, etc. There were long discussions. The best path to correct code was "hiding" the resource whenever wrong for the terrain. It has the added advantage that after cutting down trees, and building a road, reforesting gives back the Game Just like they teach in natural resources classes! > 1.) It rerolls whether or not there is a special whenever the land type > is changed, and the new special will always be appropriate to the land > type, even if land is changed to water or vice versa Very like civ1. And that was changed in commercial civ2, because it leads to bad game play. People repeatedly change the terrain until they get the combination they like best. And when did cutting down a mountain ever give you a wonderful forest full of deer, anyway? In life, it yields a thousand year blight! > 2.) The special simply stays, but land specials always stay on land, and > if it is changed to water, it goes away, and water specials can never be > on land That's what was intended in 2.0, but it never worked well. And again, the players gamed the system, so you ended up with buffalo on grassland, etc. The resources are "balanced" for each terrain. Allowing them on another terrain creates horrendous game play problems. ... > Does anyone have any thoughts about this? Many. But the most important thing is to get the current code well tested before embarking on new options The one thing that I'd planned was new flags for persistent/exhausted resources, so that Coal/Gold would stay after transforming a hill, but be depleted over time. So, "living" resources would still disappear on terrain changes, but could replenish forever. Anyway, these should never be "a user-controlled setting." They need to be in well-developed scenarios, where all the chosen features can be balanced. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40073) BUG: 2.2-test AI building_want random interval not saved/restored
http://bugs.freeciv.org/Ticket/Display.html?id=40073 > Committed trunk revision 14378. Committed S2_2 revision 14379. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Request: Option for behavior of specials while terraforming in game setup?
William Allen Simpson wrote: > Jonathan Kaplan wrote: >> ... but what would be >> ideal would be putting a *large* range of options available as a >> user-controlled setting. > > Shudder. That's horrible. How do you test? > > Remember, this has to handle civ1/2/3-like games, so civ1 Swamp resource > Oil has to turn into civ2 Peat, and then civ3 Oil again, depending on the > *same* game loading a different ruleset. Likewise, Tundra, Desert, etc. > All while the terrain is irrigated/mined/transformed. > > The reason that the old Freeciv behaviors were changed it that the code > didn't actually work well -- Fish on land, etc. > > There were long discussions. The best path to correct code was "hiding" > the resource whenever wrong for the terrain. It has the added advantage > that after cutting down trees, and building a road, reforesting gives > back > the Game Just like they teach in natural resources classes! Well, I just think that as many options as can be made to work *fairly well* should be available, for people to choose as they like! I like being able to make quite a bit of swamp/spices, even if it is "unrealistic". > >> 1.) It rerolls whether or not there is a special whenever the land >> type is changed, and the new special will always be appropriate to >> the land type, even if land is changed to water or vice versa > > Very like civ1. And that was changed in commercial civ2, because it > leads > to bad game play. People repeatedly change the terrain until they get > the > combination they like best. > > And when did cutting down a mountain ever give you a wonderful forest > full > of deer, anyway? In life, it yields a thousand year blight! Like I said, the idea is a choice where you can choose the type of gameplay you want, and the style of terraforming utility you want in your game... I just think this shouldn't be a "developer chosen only" thing, because many people like one of the options that the game had previously. Why would it be so hard to simply make the options that have come about so far to be availalble? > >> 2.) The special simply stays, but land specials always stay on land, >> and if it is changed to water, it goes away, and water specials can >> never be on land > > That's what was intended in 2.0, but it never worked well. And again, > the > players gamed the system, so you ended up with buffalo on grassland, etc. > > The resources are "balanced" for each terrain. Allowing them on another > terrain creates horrendous game play problems. > > ... > >> Does anyone have any thoughts about this? > > Many. But the most important thing is to get the current code well > tested > before embarking on new options > > The one thing that I'd planned was new flags for persistent/exhausted > resources, so that Coal/Gold would stay after transforming a hill, but be > depleted over time. So, "living" resources would still disappear on > terrain changes, but could replenish forever. > > Anyway, these should never be "a user-controlled setting." They need > to be > in well-developed scenarios, where all the chosen features can be > balanced. > Well, why can't anyone choose the settings of the specials like they can for everything else? It seems to me that this game is about giving you options for customization, not taking them away... Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40069) end_turn() => map_calculate_borders() has bad site->location
http://bugs.freeciv.org/Ticket/Display.html?id=40069 >
I've poked and prodded this, and cannot get it to crash again. My guess is
that it's an array overrun of some kind from elsewhere, as the ->location is
the first entry in the common/vision.h struct vision_site{}. The values in
the reports might be consistent with a string on a little-endian machine.
Jason, could you valgrind the PR#40068 savegame on a little-endian machine
and see whether you can detect anything?
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
