Dystopian Wars v3.19.03 validation errors don't marry up to those in Battlescribe

[Void-kraken]

Reproduced using Chrome Os on Chromebook Coral, Bluescribe v0.6.2

Steps to Reproduce

1. Download/update Dystopian Wars to v3.19.03 (latest version)
2. Create a new Roster
3. Add an Englightened faction, Enlightened Frontline Battlefleet
4. Hover over the Validation errors

The selection above results in correct validation errors (the battlefleet requires a Flagship and at least one Surface unit), but the other errors presented are invalid/not appropriate here. They ARE valid errors for other battlefleet selections, though.

These validation checks work correctly in the same scenario in Battlescribe, so on the surface it looks like an error in parsing the data files on the Bluescribe side, but I can't rule out the possibility it's a datafile issue that Battlescribe manages to ignore.

There are multiple similar scenarios to the above specific case, across factions and battlefleet selections - I'm hoping this one example is enough to signpost to the issue, but can provide/create more examples if needed!

[Void-kraken]

Updaitng to reflect that this reproduces in 0.7.0 as well. The specific exampe above has three validation errors showing:

• Correct/Expected
  -- Must have a Flagship selection
  -- Must have a Surface unit selection
• Not Expected
  -- Must have a Submerged unit selection

I think the issue improved from 0.6.2, as this doesn't feel like all the errors I was seeing before, but it's still not quite right.

[BlueWinds]

A single precise example (as you've given here) is perfect for tracking down bugs; fixing it in one place will usually fix it everywhere else as well. Just wanted to thank you for the detailed issues you've been logging. :) Looking into this one now.

[BlueWinds]

So this looks to me to be a data issue. Specifically, there are multiple categoryLinks in the data file that share an ID.

Eg:

<forceEntry id="b8ee-5f4d-72bc-d13e" name="Cetacean Operations Battlefleet" publicationId="908d-6feb-2e9e-843b" hidden="false">
  ...
        <categoryLink id="bcb8-14dc-bf98-76e0" name="Origen Class" hidden="false" targetId="3cd7-1178-4630-ab3b" primary="false">
          <constraints>
            <constraint field="selections" scope="force" value="1.0" percentValue="false" shared="false" includeChildSelections="true" includeChildForces="false" id="d3dd-0c0b-82d9-d064" type="max"/>
          </constraints>
        </categoryLink>

<forceEntry id="e449-391b-dc2e-c2b7" name="Autonomous Reserch Battlefleet" publicationId="908d-6feb-2e9e-843b" hidden="false">
  ...
        <categoryLink id="bcb8-14dc-bf98-76e0" name="Origen Class" hidden="false" targetId="3cd7-1178-4630-ab3b" primary="false">
          <constraints>
            <constraint field="selections" scope="force" value="1.0" percentValue="false" shared="false" includeChildSelections="true" includeChildForces="false" id="d3dd-0c0b-82d9-d064" type="min"/>
            <constraint field="selections" scope="force" value="1.0" percentValue="false" shared="false" includeChildSelections="true" includeChildForces="false" id="82d2-90fe-0cf5-8d5e" type="max"/>
          </constraints>
        </categoryLink>

Notice how both categoryLinks have id="bcb8-14dc-bf98-76e0".

BlueScribe requires that IDs be unique within a .cat / .gst file; if there are duplicates, the last one wins (in this case, the Origen Class categoryLink from the Autonomous Reserch Battlefleet, which has a min as well as a max constraint).

[BlueWinds]

Looks like roster other editors don't run into the same issue, but it's pretty well baked into how BlueScribe "thinks about" data, I'm not even sure how I'd approach changing it without rewriting the app.