[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

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

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Update of patch #3835 (project freeciv): Planned Release: 2.3.5, 2.4.0, 2.5.0 => 2.3.5, 2.4.0, 2.5.0, 2.6.0 ___ Reply to this item at: ___ Message

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Update of patch #3835 (project freeciv): Status:None => Ready For Test Assigned to:None => cazfi ___ Reply to this item at:

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #12, patch #3835 (project freeciv): Adding a new patch for S2_6 changing "negated" to "present" for application above patch #3879 (file #17939) ___ Additional Item Attachment: File name: negated-requirement-sanity+present

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #11, patch #3835 (project freeciv): > In the event that survives is not compared in > are_requirements_opposites(), should it not also be removed from > are_requirements_equal()? Pakcet handling wants to know if data is bitwise equal, not if it's semantically equivalent. This is

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #10, patch #3835 (project freeciv): I'm inclined to agree that survives shouldn't matter (the code was written to compare the code structures, rather than with careful semantic analysis). That said, I can think of a couple cases where one might use this: a) Creating a condi

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #9, patch #3835 (project freeciv): Reading the patch once more, I noticed that for requirements to be considered opposites they should have same 'survives'. I'm 95% sure 'survives' shouldn't matter here. Of course, 5% is still a big uncertainty. _

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #8, patch #3835 (project freeciv): And when I check what precisely needs doing for S2_4 and trunk patches to ensure that !oceanic+grassland and land+!forest are both acceptable, I discover that I was indeed reading the code wrong. These work with the patches previously attached

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #7, patch #3835 (project freeciv): I haven't reviewed all of effects.c, but there's a number of calls into it in various places that aren't AI-specific (like from combat), and the few parts I inspected tend to call into requirements.c at a much lower level than the reqs processin

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #6, patch #3835 (project freeciv): About getting rid of effects nreqs: Is there some other place totally breaking if one tries to make ruleset that works that way already, than ai evalutaion of building effects in aicity.c? That one place could be even considered a bug, and simpl

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #5, patch #3835 (project freeciv): > In practice, such redundancies will slow processing the > requirements vector, but should not otherwise impact the game. Yeah, the reason sanity checks against such redundancies is to help ruleset authors spot where they may have made an erro

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #4, patch #3835 (project freeciv): Unless refactored, the code can't complain about "desert"+"not oceanic", so that will remain. In practice, such redundancies will slow processing the requirements vector, but should not otherwise impact the game. I have a branch where I'm play

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #3, patch #3835 (project freeciv): > I wonder if the local_reqs_of_type[] checks in S2_4 and trunk > should be wrapped in a conditional like the reqs_of_type[] > checks that follow. In the absence of such a conditional, it is > potentially possible (depending on the ordering of i

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Follow-up Comment #2, patch #3835 (project freeciv): Backport patches attached. Looking through them, I wonder if the local_reqs_of_type[] checks in S2_4 and trunk should be wrapped in a conditional like the reqs_of_type[] checks that follow. In the absence of such a conditional, it is potential

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

Update of patch #3835 (project freeciv): Planned Release: => 2.3.5, 2.4.0, 2.5.0 ___ Follow-up Comment #1: Can you make version(s) for stable branches too? It's rather serious bug that ruleset sanity ch

[Freeciv-Dev] [patch #3835] Negated requirements sanity checking improvements

URL: Summary: Negated requirements sanity checking improvements Project: Freeciv Submitted by: persia Submitted on: Fri 05 Apr 2013 08:22:55 PM JST Category: general Priority: 5