[Freeciv-Dev] [patch #4987] Replace UI concept "Redundant" with current utility indicator

Update of patch #4987 (project freeciv): Depends on: => patch #4885 ___ Reply to this item at: ___ Message sen

[Freeciv-Dev] [patch #4990] Consider improvement side effects other than buildable units

Follow-up Comment #1, patch #4990 (project freeciv): Seems I failed to use the new functions everywhere: updated patch with more consistent implementation for the allows_extras tests. (file #21561) ___ Additional Item Attachment: File name

[Freeciv-Dev] [patch #4988] Always allow selected reqs to be met with nulls

Follow-up Comment #1, patch #4988 (project freeciv): > VUT_OTYPE requirements should be potentially met with a null > request. Should be TRI_MAYBE in that case. ___ Reply to this item at: __

[Freeciv-Dev] [bug #14210] optionally include advance benefits in output message

Follow-up Comment #5, bug #14210 (project freeciv): Another rebase of the patch, this time to go over patches #4889 and #4990, and use the semantics enabled there. As a side effect, no longer advertises available stuff just because the discovered technologies don't block it. Still incomplete. (

[Freeciv-Dev] [patch #4988] Always allow selected reqs to be met with nulls

Follow-up Comment #2, patch #4988 (project freeciv): The problem with returning TRI_MAYBE is that the various tests the AI uses to determine if a requirement is really active right now all check with RPT_CERTAIN and NULL target_output. If VUT_OTYPE sets eval to TRI_MAYBE in this situation, the re

[Freeciv-Dev] [patch #4988] Always allow selected reqs to be met with nulls

Follow-up Comment #3, patch #4988 (project freeciv): So we get to "ugly hack" space. Can we figure how to make API clean in this respect, or should we rename RPT_CERTAIN as RPT_CERTAIN_EXCEPT_WHEN_NOT and RPT_POSSIBLE as RPT_POSSIBLE_EXCEPT_WHEN_UNCERTAIN_NOT_ACCEPTED Yes, the current RTP_xxx -mo

[Freeciv-Dev] [patch #4988] Always allow selected reqs to be met with nulls

Follow-up Comment #4, patch #4988 (project freeciv): Yes, this stomps all over the meaning of "RPT_CERTAIN": on the unit side, it's just a generalisation of an existing hack, but the addition of OutputType and Specialist make it more glaringly obvious that the hack is to support a feature we don't

[Freeciv-Dev] [patch #4991] Use dai_can_requirement_be_met_in_city in dai_wants_defender_against

URL: Summary: Use dai_can_requirement_be_met_in_city in dai_wants_defender_against Project: Freeciv Submitted by: persia Submitted on: Sat 26 Jul 2014 07:56:38 PM JST Category: ai

[Freeciv-Dev] [patch #4991] Use dai_can_requirement_be_met_in_city in dai_wants_defender_against

Update of patch #4991 (project freeciv): Depends on: => patch #4885 ___ Reply to this item at: ___ Message sen

[Freeciv-Dev] [patch #4988] Always allow selected reqs to be met with nulls

Follow-up Comment #5, patch #4988 (project freeciv): If you want this to go forward without more fundamental rewrite, you could introduce new RPT_xxx (RPT_AI?). That way you don't need to mess sematics of RPT_CERTAIN or RPT_POSSIBLE. ___ Re

[Freeciv-Dev] [bug #22381] Inconsistent nativity limits on source tile for regular attacks

Update of bug #22381 (project freeciv): Status: Ready For Test => Fixed Open/Closed:Open => Closed ___ Reply to this item at:

[Freeciv-Dev] [patch #4992] Extend insert_allows in helpdata.c

URL: Summary: Extend insert_allows in helpdata.c Project: Freeciv Submitted by: persia Submitted on: Sun 27 Jul 2014 08:17:10 AM JST Category: client Priority: 5 - Normal

[Freeciv-Dev] [patch #4988] Always allow selected reqs to be met with nulls

Update of patch #4988 (project freeciv): Status: Ready For Test => None Assigned to: persia => None Planned Release: 2.6.0 => _

[Freeciv-Dev] [patch #4983] Introduce the UnitState requirement type with the test Transported

Update of patch #4983 (project freeciv): Status: Ready For Test => Done Open/Closed:Open => Closed ___ Reply to this item at: