OpenXcom Forum
Modding => Tools => Topic started by: SupSuper on August 30, 2018, 02:54:16 am
-
I made an extension for Visual Studio Code that checks your rulesets for syntax errors so you can catch them as you type instead of having to wait for OpenXcom to crash/spew nonsense/do nothing when you make a typo. It looks like this:
(https://i.imgur.com/Cgjd8k0.gif)
I figured it was more useful to extend a familiar text editor than trying to make an entirely separate tool. If this is worth developing further let me know.
Installation Instructions
1. Install Visual Studio Code (https://code.visualstudio.com/) if you don't already have it.
2. Install the OpenXcom Ruleset Tools extension (https://marketplace.visualstudio.com/items?itemName=openxcom.ruleset-tools) and follow the instructions.
3. Just open any .rul file and edit away.
Recommended Usage:
- Use File > Open Folder (or Open With Code in explorer) to open an entire mod at a time, so your workspace is preserved per mod.
- Open the View > Problems window to get a listing of all the errors in the currently open files.
- Use Trim Trailing Whitespace to fix tab errors (this can be done automatically in the Preferences).
What's Visual Studio Code? Isn't that some kind of IDE?
Despite the name, VSCode (for short) is just a fancy text editor in the vein of Notepad++/Sublime/Atom/etc. It's not related to Visual Studio (the IDE) which we use for developing OpenXcom.
It can be extended to be very powerful, but you don't need to be a programmer to use it. I know we've always recommended Notepad++ for YAML, but it's become kinda lackluster over the years.
Why not <insert your favorite editor>?
VSCode is free, cross-platform, and honestly it was the easiest to extend. It already had a powerful YAML extension available so I just had to build on that. If you'd rather port it to <insert your favorite editor> the source is here: https://github.com/OpenXcom/vscode-ruleset
-
Very cool! I just use Notepad++ though. It doesn't do all that, but it does some of it at least.
I wonder if one could use this to scan for new rules they didn't know about?
-
+100
-
Its totally great! im using it full time for modding. one question - is there any way to add custom commands? as it counts all OXCE syntax as an errors.
-
Yes it should allow as SupSuper careate it anybody can alter it to fit it goals.
btw SupSuper maybe add this file to `docs` folder in oxc repo? This could be source of truth for ruleset available for users.
When someone add new ruleset he need update this file, some thing like this I did for oxce documentation.
-
Yes it should allow as SupSuper careate it anybody can alter it to fit it goals.
btw SupSuper maybe add this file to `docs` folder in oxc repo? This could be source of truth for ruleset available for users.
When someone add new ruleset he need update this file, some thing like this I did for oxce documentation.
Arguably you could count this as the "source of truth": https://github.com/OpenXcom/vscode-ruleset/tree/master/schemas
Though it's already out-of-date :( I'm trying to figure out a way of having versioning and OXC/OXCE without making a mess of things.
-
To reduce my work needed for describing every possible script function and its parameters I made hack, hole metadata need to parse string can be dump in semi human readable format. Something similar could be done for ruleset.
This probably would need some metaprograming or warper that will at once describe format and load data.
e.g.
void generateSchema()
{
_schema = Schema<T>();
_schema.field(&T::_id, "id of something");
_schema.field(&T::_type, "type");
_schema.field(&T::_weapon, "default weapon");
}
void load(Yaml::node& n)
{
_schema.load(this, n);
}
Yaml::node save() //if we expand this do saves too
{
return _schema.save(this);
}
std::string dump()
{
return _schema.dump();
}
And then source of truth will be `oxc.exe --dump=filename.json`
[ps]
`dump()` probably should dump YAML too, because it will be more compossible.
-
Trying this out tonight, i am making HEAPS of errors in my first Ruleset so i need all the help i can get :)
I have installed VS2017 Community edition, i have also followed the link but the Download Buttone does nothing, how do i install and Use this, is there a video tutorial? OK, trying CSCODE instead. :P
I have found and fixed more errors tonight since installing this ruleset checker than i have in the last 2 weeks combined, this is GREAT!!!!!!!
SupSUper - Question, does this only know about Vanilla commands? I noticed the AllowKneel command from OXCE is marked as a issue, i have ignored it for now.
-
When I find some time I will fork this validator and add OXCE specific properties.
-
OpenXcom Extended support is here! It's a
Christmas New Years miracle! After updating the extension (should happen automatically next time you run VSCode) just go into your Settings and pick your preferred version. If you run into any bugs let me know.
(https://i.imgur.com/AauJnNp.gif)
-
randomProducedItems, refund and other OXCE .rul properties aren't accepted by the ruleset tools.
-
Two posts above is a visual guide how to switch between OXC validation and OXCE validation.
-
Two posts above is a visual guide how to switch between OXC validation and OXCE validation.
Still doesn't work. keeps highlighting those as invalid
-
.
-
What the heck?
It just works now?
Did the configuration change take forever to take place?
-
Looks like "refNode" still not supported.
-
No clue if this is the right spot. I would like to report a few false positives shown by the OpenXcom Ruleset Tools (https://marketplace.visualstudio.com/items?itemName=openxcom.ruleset-tools). Some of these are related to how mod: - index: are handled as well as a list being allowed for customArmorPreviewIndex.
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.
items:
# No Warning here
- type: STR_SOME_ITEM
accuracyMultiplier:
firing: 1
accuracyMultiplier: | probably needs extra handling.
items:
# Warning: Use syntax from the code field above
- type: STR_SOMETHING
accuracyMultiplier: | # Works fine in Extended 7.5.8
return bonus;
-
Yes, this is the right spot.
Thanks for the report.
I'll fix it before the next release.
-
It appears moveCost for armors isn't supported.
-
It appears moveCost for armors isn't supported.
Of course.
moveCost is not an officially released feature yet.
-
Of course.
moveCost is not an officially released feature yet.
Oh. I was not aware of that.
-
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) (https://github.com/OpenXcom/vscode-ruleset).
For the purpose of creating said workflow I am using Spectral (https://www.npmjs.com/package/@stoplight/spectral-cli) 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 (https://www.npmjs.com/package/json-merger).
// 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
//AlienRace.json > properties > retaliationMissionWeights
"retaliationMissionWeights": {
"$ref": "WeightedOptions.json#/definitions/Map"
and for WeightedOptions.json
{
"$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 (https://www.npmjs.com/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?
-
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 (https://marketplace.visualstudio.com/items?itemName=openxcom.ruleset-tools)
There are results for four kinds of validations that seem to produce false positives
First three:
vaporColorSurface: {mod: 40k, index: 3}
vaporColor: {mod: 40k, index: 1}
moveSound: {mod: 40k, index: 828}
VS Code Result: Incorrect type. Expected "integer".
The reference (https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)#Items#) says that this should be possible and the game works as expected.
Fourth:
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.
-
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
-
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) (https://github.com/stoplightio/spectral/blob/develop/docs/guides/4-custom-rulesets.md) need to be added to the bundled/dereferenced ruleset file to avoid some false positives.
-
Hellow, I think I have a false positive in eventScripts
xcomBaseInRegionTriggers: [STR_LIST]
Expected "object"
Absolute great tool, thanks
-
Hellow, I think I have a false positive in eventScripts
xcomBaseInRegionTriggers: [STR_LIST]
Expected "object"
Absolute great tool, thanks
That's because that property is not really a list by yaml standards, it's what I believe is called an associative array (I could be wrong), but many people would probably get confused by that term. So here is what it should look like:
xcomBaseInRegionTriggers:
STR_REGION_1: true
STR_REGION_2: false
and no, these cannot be defined within square brackets. You can specify as many regions with either true or false as per your needs.
If you still want it in a single line, I belive this should work for your example:
xcomBaseInRegionTriggers: {STR_LIST: true}
-
Thank you very much! Mine seemed to work, but my fantasy world mod only has one region at the moment :P
..the example below throws an error in VS btw
-
It might work, but probably because the property is considered empty for not having at least 1 key:falue pair in it and thus ignored in-game
Not sure why you're getting an error with the 2nd example, as I've tried it in VSC before even suggesting it and tested in-game too.
-
Yes, it works fine. I wrote it wrong.
I just read the online references a little more carefully and it is explained well above in researchTrigger. I had skipped over it. Sorry, the posts could be deleted and I should always give more time to research. This is a good example.