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.