Define unit requirements

[ibboard]

Rollcall had a concept of "use restrictions", which are the basis for WarFoundry "use restrictions". An initial basic implementation already exists but isn't extensively used or tested. A full set of use restrictions should be handled and available for different factories to create as necessary.

[ibboard]

Rollcall restrictions:

• N, UnitIDList - In this case the army may have N of this unit for each unit in the UnitIDList. Assume there are three X units and two Y units. Then 2,X|Y means you may have no more than 10 [2 * (3 + 2)] of this unit while 2,X,2,Y means you may have no more than 6 [2 * 3] or no more than 4 [2 * 2] of this unit.
• -1, UnitIDList - The army must have at least one unit listed in the UnitIDList to be eligible to have this unit. Note that -1,X,-1,Y means the army must have at least unit X AND one unit Y while -1,X|Y means the army must have a unit X OR Y
• -2. UnitIDList - The army may not have any unit listed in the UnitIDList to be eligible to have this unit. Note that -2,X,-2,Y is equivalent to -2,X|Y with the exception that two entries produce two warning messages.
• -3, X -This unit cannot be chosen. This unit is only used as a champion. If X is 1 then the unit can have its own equipment, otherwise the equipment will match that of the parent unit.
• -4,0 - This unit may be the army general but is not required to be so
• -5,0 - This unit must be the army general.

-4 and -5 equivalents should be handled under #23. -3 is to be handled by #28.

[ibboard]

Remove owner so that the team can more easily see bugs. Using default owners seems good at first but is bad practice when a team can be working on any part of the project.

[ibboard]

Move tickets to new "confirmed" status to show that they've been checked

[ibboard]

Separate API milestone from UI milestone

[ibboard]

(In #57) Ticket doesn't make sense any more - we're defining the spec as we go and relying on backward/forward compatibility so there is no "complete" to load.

[ibboard]

A list of requirements has been collected in ​this thread. In addition to unit requirements (what must/must not be taken before a unit can/can't be taken) we also need to consider equipment requirements.

The current list of requirements is:

• Must have one (or more) of unit Y to take any number of unit X (e.g. "must have at least one bowman unit to take Borris the Bowman special character")
• Can have up to A units of X for every B of unit Y (e.g. "can have up to three slave units for each normal unit")
• Cannot have any of Y to take X (e.g. "cannot have any flame demons if you take dryads")
• Unit X makes unit Y count as cat A instead of cat B (mainly occurs with special characters moving special choices to core choices)
• Unit X requires Z number of models of unit Y (e.g. "Doomsayer can only be taken if there are 15 or more flagelants")
• Unit X can only be taken in armies of Y points and above (e.g. "Grand High Emperor can only be taken in armies of 3000pts or more)
• Unit must take item X to have equipment item Y (e.g. "must have Mark of Warrior God to take Axe of Warrior God")
• Equipment item X can only be taken Y times per army (e.g. "rare scroll can only be taken three times per army")
• Points limits on unit equipment (e.g. "up to 40pts spent on any combination of items Q, R, S...Y or Z")
• Equipment X can only be taken in armies of Y points and above (e.g. "Historic National Battle Standard can only be takin in armies of 3000pts or more")

[ibboard]

In [831]:

Re #27: Define unit requirements

• First skeleton of first new style requirement

[ibboard]

In [832]:

Re #27: Define unit requirements

• First test for first new style requirement
• Update some of the Mock objects to add a few more required elements (mainly Category)

[ibboard]

In [833]:

Re #27: Define unit requirements

• Refactor out common code
• Simplify tests to try with one unit type required at first
• Add test where requirement is satisfied

[ibboard]

In [834]:

Re #27: Define unit requirements

• Add checking for passing requirements

[ibboard]

In [835]:

Re #27: Define unit requirements

• Add tests to cover UnitType, since we'll often be checking if we can create a unit rather than creating and adding it

[ibboard]

In [836]:

Re #27: Define unit requirements

• Change method definition to be able to handle both Unit and UnitType

[ibboard]

In [837]:

Re #27: Define unit requirements

• Update method name for a more "natural language" approach of "if (req.AllowsAdding(...))"

[ibboard]

In [838]:

Re #27: Define unit requirements

• Update method name for a more "natural language" approach of "if (req.AllowsAdding(...))"

[ibboard]

In [839]:

Re #27: Define unit requirements

• Add unit tests for multiple unit types being required

[ibboard]

In [840]:

Re #27: Define unit requirements

• Rename class to match behaviour (no longer just units)

[ibboard]

In [841]:

Re #27: Define unit requirements

• Rename class to match behaviour (no longer just units)
• Move to correct package

[ibboard]

In [842]:

Re #27: Define unit requirements

• Add tests where a min count > 1 is set

[ibboard]

In [843]:

Re #27: Define unit requirements

• Implement code for min limits > 1

[ibboard]

In [844]:

Re #27: Define unit requirements

• Add unit tests for validating an existing army without adding anything to it

[ibboard]

In [845]:

Re #27: Define unit requirements

• Add new method for validating an existing army
• Refactor existing code into new method

[ibboard]

In [846]:

Re #27: Define unit requirements

• Add last unit test to get more obvious behaviour equivalent to Rollcall's "-1" (can take unlimited X once one Y is taken)

[ibboard]

In [847]:

Re #27: Define unit requirements

• Document methods
• Add new method that provides default "must have at least one" behaviour - "must have at least N to take unlimited" (where N is greater than 1) is probably less common

[ibboard]

In [848]:

Re #27: Define unit requirements

• Rebuild and add unit test for "no more than N" requirement

[ibboard]

In [849]:

Re #27: Define unit requirements

• Make use of default value in "Requires at least N"
• Add initial implementation of "No more than N"

[ibboard]

In [851]:

Re #27: Define unit requirements

• Copy and paste first requirement that does "requirement for unit type"

[ibboard]

In [852]:

Re #27: Define unit requirements

• Copy and paste first requirement unit test that does "requirement for unit type"

[ibboard]

In [858]:

Re #27: Unit requirements

• Add unit tests for when the unit with the prerequisite doesn't exist (requirement needn't hold)

[ibboard]

In [859]:

Re #27: Unit requirements

• Add "is applicable" checking to army validation

[ibboard]

In [860]:

Re #27: Unit requirements

• Add tri-state enum (passed, failed, not applicable)

[ibboard]

In [861]:

Re #27: Unit requirements

• Add tri-state enum (passed, failed, not applicable) and helper class

[ibboard]

In [862]:

Re #27: Unit requirements

• Switch to enumeration and update tests as appropriate

[ibboard]

In [863]:

Re #27: Unit requirements

• Update "Requires at least" requirements to use new enum

[ibboard]

In [864]:

Re #27: Unit requirements

• Switch remaining unit requirement to using enum

[ibboard]

In [865]:

Re #27: Unit requirements

• Switch to using validation enum
• Add tests for unit type

[ibboard]

In [866]:

Re #27: Unit requirements

• Correct documentation
• Add "limit to none" method

[ibboard]

In [867]:

Re #27: Unit requirements

• Test limit setting for "no more than" requirement

[ibboard]

In [868]:

Re #27: Unit requirements

• Add test to make sure that requirement actually revalidates after change

[ibboard]

In [869]:

Re #27: Unit requirements

• Quick first draft of unit tests for "unit requires no more than X"

[ibboard]

In [870]:

Re #27: Unit requirements

• First draft of "Unit requires no more than X" requirement

[ibboard]

In [871]:

Re #27: Unit requirements

• Test threshold
• Test that default setting is 0
• Test that "No more than" requirement gives "N/A" when appropriate

[ibboard]

In [872]:

Re #27: Unit requirements

• Restructure "check default" tests so that we actually check the default (test before and after)
• Add test to make sure requirement checks on each request
• Add test to make sure that adding more prohibited units than the limit causes a failure

[ibboard]

In [873]:

Re #27: Unit Requirements

• Take unit being added into account

[ibboard]

In [874]:

Re #27: Unit Requirements

• Test base "no more than" requirement validates armies correctly

[ibboard]

In [875]:

Re #27: Unit requirements

• Add test for adding required unit types to satisfy requirements

[ibboard]

In [876]:

Re #27: Unit requirements

• Add matching test for unit type requiring at least N units

[ibboard]

In [877]:

Re #27: Unit requirements

• Make basic "Requires at least" requirement take into account the unit type being added
• Make unit version of "requires at least" requirement pass execution up to the matching parent method

[ibboard]

In [880]:

Re #27: Unit requirements

• Add first test for getting requirements from race

[ibboard]

In [881]:

Re #27: Unit requirements

• Add base interface for all requirements and extend it in existing requirements
• Add stub method for getting requirements of race (UnitTypes need to be able to add them first before testing goes further)

[ibboard]

In [882]:

Re #27:

• Start testing adding requirements to unit types

[ibboard]

In [883]:

Re #27: Unit requirements

• Obsolete methods using the old requirements system
• Switch to new IRequirement objects

[ibboard]

In [884]:

Re #27: Unit requirements

• Test getting all unit requirements for race

[ibboard]

In [885]:

Re #27: Unit requirements

• Implement getting all requirements from unit types of race

[ibboard]

In [886]:

Re #27: Unit requirements

• Initial rebuild of tests so that we check for "N/A" in more of the appropriate cases for adding units

[ibboard]

In [887]:

Re #27: Unit requirements

• Rebuild base "at least" requirement to say "N/A" when added unit isn't constrained
• Remove duplicate code from "unit requires at least" requirement and override where necessary

[ibboard]

In [891]:

Re #27: Unit requirements

• Add unit test for unit requirements in opposite order
• Add unit test to make sure that requirement doesn't lock to first result, even after changes

Also:

• Clean up line endings to meet policy

[ibboard]

In [892]:

Re #27: Unit requirements

• Start writing tests for requirement handler
• Add mocks to support tests

Note: NA test currently fails (expect pass but get fail)

[ibboard]

In [893]:

Re #27: Unit requirements

• Add initial requirement handler class
• Add method to get requirements for army (currently falls back to Race)

[ibboard]

In [894]:

Re #27: Unit requirements

• Tidy up line endings
• Fix unit tests to mask (logical AND) instead of ORing

[ibboard]

In [895]:

Re #27: Unit requirements

• Bit mask the values with a bitwise AND rather than an OR

[ibboard]

In [896]:

Re #27: Unit requirements

• Add tests for mixed requirements
• Add tests for adding units

[ibboard]

In [897]:

Re #27: Unit requirements

• Implement check for adding units to army

[ibboard]

In [899]:

Re #27: Unit requirements

• Make sure that units return their limits as requirements on the army

[ibboard]

In [900]:

Re #27: Unit requirements

• Initial work to try to make unit types return requirements for count limits
  • Add requirements when limits aren't defaults
  • Start adding equality/hash code methods

[ibboard]

In [932]:

Re #27: Unit requirements

• Remove old requirements

[ibboard]

"-1" requirement should mainly be handled by UnitRequiresAtLeastNUnitsRequirement class (you can have any number as soon as you have N of the specified units, defaulting to 1) - OR option isn't handled yet. Schema to be added under #347.
"-2" requirement should now be handled by UnitRequiresNoMoreThanNOfUnitTypeRequirement (you can have any number as long as you have no more than N, defaulting to 0) - OR behavior isn't an important change and just requires separate requirements. Schema to be added under #348.

[ibboard]

In [934]:

Re #27: Define unit requirements

• Remove remaining references to old Requirements namespace

[IBBoard <dev@…>]

In [3882b533d99d3a578dba06238c74fdfabbfcc134/IBBoard.WarFoundry.API]:

Re #27: Define unit requirements

• Add ID to requirements so that it isn't just defined in factories
• Make factory use ID from requirement class to avoid duplication and possible mismatch

[IBBoard <dev@…>]

In [8f512574031669bd28917a5870e19231a023d6bd/IBBoard.WarFoundry.API]:

Re #27: Define unit requirements

• Move definition and documentation of ID up to interface to ensure it is everywhere

[ibboard]

Some of the requirement ideas have been moved out to ticket:399 because they're related to equipment more than units.

[ibboard]

(In #271) Dupe - better explained in #396.