Negative requirements: nreq vs. "negate" TRUE/FALSE

[Corbeau]

I understand the "nreqs" thing is going to be obsolete and replaced by "negate" TRUE/FALSE. So, I tried this:

Code: Select all

[effect_granary_1]
type    = "Growth_Food"
value   = 20
reqs   =
    { "type", "name", "range", "negate"
      "MinSize", "1", "City", FALSE
      "MinSize", "2", "City", TRUE
    }

Ended up with "Growth_Food: Requirement list has multiple MinSize requirements" error.

This is not a real problem because I'll probably be reverting to "nreqs" format, but I'm curious, how are you supposed to do this with the new format?

[Akechi]

At first, I think not "negate", but "present".

Post edited:
And if you replaced negate to present, you need invert TRUE/FALSE.

Code: Select all

[effect_granary_1]
type    = "Growth_Food"
value   = 20
reqs   =
    { "type", "name", "range", "negate"
      "MinSize", "1", "City", FALSE
      "MinSize", "2", "City", TRUE
    }

In 2.6 coding, above code will be:

Code: Select all

[effect_granary_1]
type    = "Growth_Food"
value   = 20
reqs   =
    { "type", "name", "range", "present"
      "MinSize", "1", "City", TRUE
      "MinSize", "2", "City", FALSE
    }

[Corbeau]

Some other effects work nicely with "negate". (But, to be honest, I think this was a confusing way to implement this; "present" makes much more sense.)

And the problem isn't this part, but the fact that there are two same requirement types (MinSize) in the same field.

[Akechi]

Some other effects work nicely with "negate". (But, to be honest, I think this was a confusing way to implement this; "present" makes much more sense.)

And the problem isn't this part, but the fact that there are two same requirement types (MinSize) in the same field.

It seems nreqs is just deprecated, but negated is dropped in 2.6 (server/ruleset.c) so negate is not understandable for ruleset.c.
(by the way, not "negate", but "negated"...)

[Corbeau]

(by the way, not "negate", but "negated"...)

Hold on, there is a bump on my desk, I need to smooth it out with my forehead.

[Akechi]

Hold on, there is a bump on my desk, I need to smooth it out with my forehead.

Uh, sorry for lack of words.
Quoted from 2.5's doc/README.effects:

A requirement may have a 'negated' field, and if this is 'TRUE', the
requirement is negated. If this is 'FALSE', the requirement is not negated.

Quoted from 2.6's doc/README.effects:

A requirement may have a 'present' field, and if this is 'FALSE',
the requirement is negated (the condition must not be true for the req to be
met).

Quoted from http://freeciv.wikia.com/wiki/How_to_up ... 2.5_to_2.6:

Negated replaced with present

Old negated property of the requirements has been replaced with opposite meaning present so that ruleset author is not required to think in double-negations (negating negation).

[Wahazar]

So, nreq still exist for 2.6? I hope so, it was convenient.
If I understand correctly, change affect things such:

Code: Select all

    
      "type", "name", "range", "negated"
      "Tech", "Construction", "Player", FALSE
      "Road", "River", "Adjacent", TRUE

(aqueduct can be build if construction and no river)
which would now like:

Code: Select all

    
      "type", "name", "range", "present"
      "Tech", "Construction", "Player", TRUE
      "Road", "River", "Adjacent", FALSE

[Ignatus]

If both

Code: Select all

nreqs=

and

Code: Select all

present

mechanisms existed in the game but all nrequs were logically multiplied as reqs do, not summed as they did in 2.4, then we could get at least basic logical operations (

Code: Select all

not(not A and not B) == A or B

) which would make the ruleset files shorter and more comprehensible. Would it much slow the effect computation?

[Alien Valkyrie]

Adding more complex effect requirement formulae probably wouldn't affect computation time too much, but it would make it significantly harder for AI to understand them.
Also, I believe the "negated" (and then "present") aren't supposed to be something additional, but a way to generalize and abstract the requirements system, which makes both it and anything dealing with it (such as AI) clearer and less error-prone.

[nef]

Also, I believe the "negated" (and then "present") aren't supposed to be something additional, but a way to generalize and abstract the requirements system, which makes both it and anything dealing with it (such as AI) clearer and less error-prone.

I think it is clear enough that the changes 2.4 -> 2.5 -> 2.6 are entirely cosmetic (i.e. syntax only). The first change (2.4 -> 2.5) was to unify the syntax between the effects file and all the others. The second change (2.5 - 2.6) was to deal with human frailty concerning double negatives.

Adding more complex effect requirement formulae probably wouldn't affect computation time too much, but it would make it significantly harder for AI to understand them.

This has been discussed before. For most situations bard has shown how to do it. But you need an exhaustive list for the negatives - which is in fact manageable in most cases. For examples see the civ2civ3 effects.ruleset. I agree with Caedo (and whomever responded to the original) that adding additional boolean operators would make life difficult for AI (AND auto generated help) - for very little gain - considering the technique shown by bard more or less does the job.