Ruleset Validator for VSCode v0.9.36

[Nord]

Looks like "refNode" still not supported.

[Buscher]

No clue if this is the right spot. I would like to report a few false positives shown by the OpenXcom Ruleset Tools. Some of these are related to how mod: - index: are handled as well as a list being allowed for customArmorPreviewIndex.

Code: [Select]

items:
  - type: STR_SOME_ITEM
    vaporColorSurface: {mod: 40k, index: 2} # Warning: Expected Integer # Works fine in Extended 7.5.8

armors:
  - type: STR_SOME_ARMOR
    moveSound: {mod: 40k, index: 700} # Warning: Expected Integer # Works fine in Extended 7.5.8
    customArmorPreviewIndex: [{mod: 40k, index: 560}, {mod: 40k, index: 561}, {mod: 40k, index: 562}] # Warning: Expected Integer # Works fine in Extended 7.5.8
    layersDefaultPrefix: 20 # Warning: Expected string # The value 20 is not nice but works in Extended 7.5.8

Also if one changes the accuracyMultiplier as a script and it's not part of scripts: and doesn't use the normal syntax, f. ex.

Code: [Select]

items:
# No Warning here
  - type: STR_SOME_ITEM
    accuracyMultiplier:
      firing: 1

accuracyMultiplier: | probably needs extra handling.

Code: [Select]

items:
# Warning: Use syntax from the code field above
  - type: STR_SOMETHING
    accuracyMultiplier: | # Works fine in Extended 7.5.8
      return bonus;


[Meridian]

Yes, this is the right spot.

Thanks for the report.
I'll fix it before the next release.

[The Offensive Lemon]

It appears moveCost for armors isn't supported.

[Meridian]

It appears moveCost for armors isn't supported.

Of course.
moveCost is not an officially released feature yet.

[The Offensive Lemon]

Of course.
moveCost is not an officially released feature yet.

Oh.  I was not aware of that.

[Buscher]

Hi,
I have been trying to create a github workflow for linting rul files and I don't get how some particular details work for the OpenXcom Ruleset Tools (vscode ruleset yaml validator).

For the purpose of creating said workflow I am using Spectral which gave the best results so far. Except that it can't deal with the recursive bits in the json files (vscode-ruleset/schemas). As a consequence it will create false positives as described below.

So far I understood that I need to merge the oxc bits into oxce-merge. That works well enough with the JSON merger.

Code: [Select]

// merger.js
// put it in vscode-ruleset/schemas/oxce-merge
// run with: node merger.js

const jsonMerger = require("json-merger");
const fs = require("fs");

var result = jsonMerger.mergeFiles(["AlienRace.json", "../oxc/AlienRace.json"]);
fs.writeFileSync("AlienRace.json", JSON.stringify(result, null, 2));

Inside the AlienRace.json there is a setting retaliationMissionWeights

Code: [Select]

//AlienRace.json > properties > retaliationMissionWeights
    "retaliationMissionWeights": {
      "$ref": "WeightedOptions.json#/definitions/Map"

and for WeightedOptions.json

Code: [Select]

{
  "$id": "https://openxcom.org/schemas/oxc/WeightedOptions.json",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "additionalProperties": {
    "type": "integer"
  },
  "definitions": {
    "Map": {
      "patternProperties": {
        "^\\d+$": {
          "$ref": "#" // <-------------- is this a circular reference to WeightedOptions.json ?????
        }
      },
      "additionalProperties": false,
      "type": "object"
    }
  }
}

When I use bundle or dereference of the node package @apidevtools/json-schema-ref-parser, the circular reference is either adapted with bundle in such a way that it persists and therefore Spectral ignores it or the dereference deletes the entry for retaliationMissionWeights altogether meaning that Spectral will try to use a standard value (string) to lint retaliationMissionWeights creating a false positive.

Is there something I am missing or do you have different ideas what I could try?

[Buscher]

Different topic:

While linting ROSIGMA with yamllint I got to have a deeper look in the validation results produced by OpenXcom Ruleset Tools v0.9.35

There are results for four kinds of validations that seem to produce false positives
First three:

Code: [Select]

vaporColorSurface: {mod: 40k, index: 3}
vaporColor: {mod: 40k, index: 1}
moveSound: {mod: 40k, index: 828}
VS Code Result: Incorrect type. Expected "integer".
The reference says that this should be possible and the game works as expected.

Fourth:

Code: [Select]

customArmorPreviewIndex: {mod: 40k, index: 52}
VS Code Result: Incorrect type. Expected one of array, integer.

This can be an integer or an array for normal values. This works in the game as expected.

Would be great if those false positives could be looked at. Thanks.

[Meridian]

Is there something I am missing or do you have different ideas what I could try?

Try asking SupSuper, probably best on Discord.

Would be great if those false positives could be looked at. Thanks.

Fixed in v0.9.36: https://github.com/OpenXcom/vscode-ruleset/commit/33984cd00d4d97a36b750579fbd511d821e80706

[Buscher]

Thanks for fixing them  . I ran ROSIGMA through it and deleted all invalid rul syntax already.

As for the above I will try to take another poke at it later and ask Supsuper if I am not getting anywhere. For the curious I found that Spectral assumes a bit too much how yaml has to look (it takes JSON as a reference), so Parsing Options (incompatibleValues) need to be added to the bundled/dereferenced ruleset file to avoid some false positives.