Page 1 of 2

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

Posted: Tue Aug 21, 2018 12:33 pm
by 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?

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

Posted: Tue Aug 21, 2018 1:28 pm
by Akechi
At first, I think not "negate", but "present".

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

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
    }

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

Posted: Tue Aug 21, 2018 1:36 pm
by 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.

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

Posted: Tue Aug 21, 2018 2:11 pm
by Akechi
Corbeau wrote: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"...)

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

Posted: Tue Aug 21, 2018 2:33 pm
by Corbeau
Akechi wrote:(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.

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

Posted: Tue Aug 21, 2018 2:47 pm
by Akechi
Corbeau wrote: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).

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

Posted: Tue Aug 21, 2018 3:29 pm
by 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

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

Posted: Tue Aug 21, 2018 6:46 pm
by 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?

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

Posted: Wed Aug 22, 2018 6:35 am
by 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.

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

Posted: Mon Aug 27, 2018 1:03 pm
by nef
Caedo wrote: 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.