Ostensibly, yes, at least on a ruleset level. On a code level, however, the old code essentially had to separately evaluate the reqs and nreqs for an effect (and they work slightly differently) with the same data, meaning that (a) you had almost the same code twice, which creates redundancy in the code, and (b) whenever something about the requirements system was changed, it became necessary to make a whole bunch of little changes in a whole bunch of places, which is more work, so the whole system was more prone to accidentally introducing errors.nef wrote: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.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.
Now, I wasn't able to figure out if something like that ever happened (digging through code you don't know well with only github's web interface is cumbersome), but either way, eschewing nreqs to create one unified requirements system in 2.6 removes this additional work and risk for the future by creating clean, compact code (unifying three methods that were each essentially a dozen lines of hot air into one method that did it all concisely).
Why yes, I am studying to become a software engineer, how could you tell?
