Wookie Commandos upgrade card requires multiple slots

[migdol]

Issue

Current Wookie Commands entry in upgrades.js suggests it requires a single Crew slot. Actual card requires two Crew slots.

  {
    "image": "upgrades/Crew/wookiee-commandos.png",
    "text": "When attacking, you may reroll your [Focus] results.",
    "name": "Wookiee Commandos",
    "xws": "wookieecommandos",
    "points": 1,
    "slot": "Crew",
    "faction": "Rebel Alliance",
    "id": 315
  },

A correction to this will require modifying current upgrade schema as it currently supports only one slot to be defined.

See upgrades.json

    "slot": {
      "description": "The slot used by this upgrade.",
      "$ref": "definitions.json#/definitions/slot"
    },

Recommendation

Remove the upgrades schema's entry for slot, and clone the entry for slots found in the pilots schema.

Here's an example of the change applied to the Wookie Commandos entry:

{
  "image": "upgrades/Crew/wookiee-commandos.png",
  "text": "When attacking, you may reroll your [Focus] results.",
  "name": "Wookiee Commandos",
  "xws": "wookieecommandos",
  "points": 1,
  "slots": [
    "Crew",
    "Crew"
  ],
  "faction": "Rebel Alliance",
  "id": 315
},

[migdol]

Alternatively, the original slot value could remain to define the card's categorization. Then the card's cost could be defined under a new entry:

{
  "image": "upgrades/Crew/wookiee-commandos.png",
  "text": "When attacking, you may reroll your [Focus] results.",
  "name": "Wookiee Commandos",
  "xws": "wookieecommandos",
  "points": 1,
  "slot": "Crew",
  "cost": [
    "Crew",
    "Crew"
  ],
  "faction": "Rebel Alliance",
  "id": 315
},

[grahamgilchrist]

Just to add an extra vote for resolving this issue. It exists for several cards now including Bomblet Generator and Emperor Palpatine.

The first suggestion seems sensible and cleaner, but less backwards compatible.

The latter suggestion is good for backwards compatibility if that is required, but I can't envision a situation where a card would be defined as a particular type, but require a different slot.
But then again we never know what FFG will do to surprise us!

[urbknu]

I like suggestion 1, it is clean and follows, as you mentioned, the pilots schema.

Backwards compatibility leads to cluttering, which would be unfortunate for the health of the project.
Existing projects using xwing-data should have local clones of xwing-data, or refer to the latest release, 0.52.0. That will give them an opportunity to implement the required change before the they fetch the latest release.