[Freeciv-Dev] [patch #4816] civ2civ3: ZoCs not affected by non military units.
Update of patch #4816 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4816 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #21437] Autosettlers ignoring special resources (mining hills without coal when coal is available)
Update of bug #21437 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?21437 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4885] Revised logic for AI improvement consideration and improvement redundancy
Follow-up Comment #3, patch #4885 (project freeciv): I no longer believe this ticket can be split: the manner in which the AI detects whether an improvement is interesting is somewhat semantically bound to how is_improvement_redundant() is implemented. From the client side, the calls to is_improvement_redundant() seem sensible: ask if buildings currently in cities are currently providing a benefit (with no promise that they won't start providing a benefit later). A sensible implementation for this is just to see if the improvement provides value (money, units, extras, disaster protection, action prevention, effects, etc.), which isn't terribly difficult (although a bit tedious, with lots of potential for consolidated logic). Doing this properly will also require some means of deciding whether an additional effect value is actually beneficial (for example, an effect that reduced unit movement by 1 should probably not be considered beneficial). For the AI, things are a bit different. The AI seems to use this in part to decide if a building that isn't currently in a city will ever be interesting to have, so using the same logic above means that many improvements that *will* be interesting later are ignored, reducing the want value for dependencies (e.g. Libraries get built less because they fact that they enable Universities isn't interesting, because the University isn't providing any effect for a city without a Library). Also, the AI immediately sells any improvement that it detects as redundant, so improvements that are only sometimes useful tend to get sold before they are useful when conditions aren't right (e.g. switch from Democracy to Communism: lose Superhighways trade bonus, sell Superhighways, find Democracy less interesting later (and if interesting enough, less beneficial than before)). I'm tempted for the AI to consider building utility differently, selling buildings less often: this may mean keeping buildings that aren't currently useful (e.g. Cathedrals in the presence of Michelangelo's Chapel or Police Stations in the presence of Women's Suffrage), but seems to cause the AI to develop cities more in general. Others opinions on the matter welcomed. ___ Reply to this item at: http://gna.org/patch/?4885 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22359] Infinite loop in pick_random_tech
Follow-up Comment #1, bug #22359 (project freeciv): Which ruleset is loaded for these backtraces? Are they different rulesets? ___ Reply to this item at: http://gna.org/bugs/?22359 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22359] Infinite loop in pick_random_tech
Follow-up Comment #2, bug #22359 (project freeciv): freeciv-web has its own ruleset, simplified version of classic ruleset that does not expose features unimplemented in freeciv-web. https://github.com/freeciv/freeciv-web/tree/master/freeciv/data/fcweb ___ Reply to this item at: http://gna.org/bugs/?22359 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4952] Two-mode-workers for threaded AI
Update of patch #4952 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4952 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4946] Make alien empire size penalties less severe
Follow-up Comment #1, patch #4946 (project freeciv): - Corrected section name of the new effect sensible with the actual rule (was leftover from earlier iteration of the rules) (file #21460) ___ Additional Item Attachment: File name: EmpireSize-2.patch Size:2 KB ___ Reply to this item at: http://gna.org/patch/?4946 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4954] Build threaded AI to Windows Installer build
Update of patch #4954 (project freeciv): Status: Ready For Test = Done ___ Follow-up Comment #1: so the support should be sufficient for threaded AI Doesn't look like that in actual testing. Loading threaded AI fails. ___ Reply to this item at: http://gna.org/patch/?4954 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4962] Remove the now unused fields REQ_RANGE and REQ_TYPE from packets.def
Update of patch #4962 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4962 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22359] Infinite loop in pick_random_tech
Follow-up Comment #3, bug #22359 (project freeciv): Here's how to reproduce this infinite loop: - Start a new game on Freeciv-web with the 'techlevel 100' setting. - End the first turn. - The server will then freeze, using 100% CPU. I think that the Freeciv server is running the loop in choose_random_tech() without ever stopping. This could be because all techs have been discovered already through the techlevel setting, so the iteration never ends. ___ Reply to this item at: http://gna.org/bugs/?22359 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22359] Infinite loop in pick_random_tech
Follow-up Comment #4, bug #22359 (project freeciv): I also get the same server problem in the Freeciv GTK2 client running the Freeciv C server from current trunk. ___ Reply to this item at: http://gna.org/bugs/?22359 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #21193] Empty city does not provide contact
Follow-up Comment #1, bug #21193 (project freeciv): This has supposed to have been working since r2367, and in trunk, unit_move() calls maybe_make_contact(), which should trigger contact to the owner of any adjacent city. I can't reproduce this on trunk (r25614) by starting a new game with the classic ruleset, using the editor to place an (empty) foreign city a knights-move from the start position, and moving the initial explorer unit adjacent. Do you have a savegame or instructions to reproduce? ___ Reply to this item at: http://gna.org/bugs/?21193 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22359] Infinite loop in choose_random_tech()
Update of bug #22359 (project freeciv):
Summary: Infinite loop in pick_random_tech = Infinite loop
in choose_random_tech()
___
Follow-up Comment #5:
I'm not understanding the recent changes to techs well enough to know the
right answer, but there's an infinite loop available in choose_random_tech()
when choose_tech() fails to set a research target (as it does when passed an
unresearchable target). This patch worked for me, but I'm not at all
confident it's right, so won't even consider putting it in SVN (although
anyone else is welcome to swipe it if they understand the situation and like
this solution). It may be useful to folk running public servers who want to
avoid this issue (but it may break other things: I don't know).
--- a/server/techtools.c
+++ b/server/techtools.c
@@ -924,7 +924,11 @@ void choose_random_tech(struct player *plr)
{
struct research* research = research_get(plr);
do {
-choose_tech(plr, pick_random_tech(plr));
+Tech_type_id tech = pick_random_tech(plr);
+choose_tech(plr, tech);
+if (research_invention_state(research, tech) != TECH_PREREQS_KNOWN) {
+ break;
+}
} while (research-researching == A_UNSET);
}
Despite the backtraces, the call to pick_random_tech() where the
interruptions happen is always from choose_random_tech(), and
pick_random_tech() is iterating properly over all available advances, and
returning, and re-interating when called again (I did reproduce this several
times with instrumented builds to confirm this).
___
Reply to this item at:
http://gna.org/bugs/?22359
___
Message sent via/by Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #22359] Infinite loop in choose_random_tech()
Follow-up Comment #6, bug #22359 (project freeciv): Thanks a lot. I can confirm that the patch solves the infinite loop problem. ___ Reply to this item at: http://gna.org/bugs/?22359 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
