Add Victoria3Tools package

[dementive]

• I'm the package's author and/or maintainer.
• I have have read [the docs][1].
• I have tagged a release with a [semver][2] version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **
• Any commands are available via the command palette.
• Preferences are listed in the menu and the command palette, and open in split view.
• If my package is a syntax it doesn't also add a color scheme. ***

My package is Victoria3Tools — A plugin for Victoria 3 scripting that has a syntax, auto completion, validation, go to definition, and a ton more features.

There are no packages like it in Package Control.

[packagecontrol-bot]

Automated testing result: ERROR

Repo link: Victoria3Tools
Results help

Packages added:
  - Victoria3Tools

Processing package "Victoria3Tools"
  - ERROR: Invalid JSON (with comments)
    - File: Default (Windows).sublime-keymap
    - Exception: Expecting value: line 7 column 1 (char 6)
  - ERROR: Unhandled exception in 'check' routine
    - Exception: Expecting value: line 7 column 1 (char 6)
  - WARNING: The package does not contain a top-level LICENSE file. A license helps users to contribute to the package.
  - WARNING: '.no-sublime-package' is defined. Please verify that it is *really* necessary

[braver]

I'm sorry we haven't given a lot of feedback yet. This and ImperatorTools are massive packages. I understand they're aimed at providing tools around certain games ... but not much more I'm afraid. Both packages also seem to collect various syntaxes (e.g. for shaders) that might already be available. And the new syntaxes all seem to have various issues: simple ones like missing suffixes, very non-standard scope names ... and maybe more (again, there is a lot here!). The .no-sublime-package file seems to be explained by the bundled dependency to "convert dds" (which makes me wonder if this will run on all platforms, as specified in the entry here, or just Windows).

In short, both packages are very ambitious and probably need a bit of work still to get them to the point where we can add them to package control. If you're ok with that, I would suggest starting on improving the syntaxes, and maybe splitting out the shader syntaxes etc (and checking if they're not already on package control).

[dementive]

Hey there thanks for the feedback, the plug-ins both certainly have tons of features and I'll be happy to make any changes you think are needed. I've been wanting to get it on package control so all my users can get the convinient automatic updates from it. A lot of the features are extremely specific to the syntax found in these games you're right they don't provide much outside of situations where the user is doing scripting for these games. So I've been careful to provide settings to toggle off all features as well as checks in the code to ensure plug in code is only running in relevant views. I also have checks to run windows specific dependencies under wine on other platforms or using a path in settings to provide an alternative executable so 99.9% of the features are cross platform (I personally use this on both windows and Linux).

As for the syntax changes you suggested I can't really do those because the python code and syntax definition are very tightly coupled. A lot of plugin features are provided via syntax scopes which is why you see so many "non standard" scope names. However, the main components of the syntaxes that aren't extremely context specific or linked to plugin code do use standard syntax names and have been thoroughly tested on tons of different color schemes. The imperator script syntax in particular probably looks pretty horrifying but it works very well and highlights paradox game syntax pretty much perfectly.

As for the shader syntax you are correct that one is actually based on the HLSL shader syntax package however the syntax for paradox game shaders has a lot of extra components on top of hlsl and is basically it's own separate language. There could be some benefit to splitting it into a 3rd package separate from both imperator tools and vic3 tools but each game has slightly differences in their implementation which is why I keep different versions that look similar in both.

If you have any other feedback I'd be happy to fix things up, I get the plugin is kinda huge and does a lot of odd things at times so no rush.

[braver]

If you’re just looking for the auto update feature and have a user base you can interact with directly, you should consider simply hosting a repository json file somewhere (e.g. on GitHub). You can tell your users to do “add repository”, fill in the URL to that file, and the package control package will just handle that transparently: users will be able to discover, install and auto-update your packages. The main benefit for you is that you don’t need to go through the review process here, and you can do things in your package that wouldn’t normally get approved. The only real downside is that the general public doesn’t get to discover your packages on the package control website, but in some cases that’s actually not important.

[dementive]

Huh I didn't really realize package control would handle additional repositories like that but it makes sense. That will probably be the way to go I agree with you it'll be way easier to setup for me, my users will get what they need, plus you guys won't have to review my awful code so everyone wins. Considering I do some horrifying things like inject new scopes into color schemes and dynamically generate the syntax definition it's probably unlikely it'd ever get merged here either. So I'll close these and set those local repos up, thanks for the feedback :)

[braver]

Excellent! Yes, this is a somewhat less immediately obvious feature of package control, but super useful. Where I work we use it to distribute some packages around internal tools.

See also https://packagecontrol.io/docs/channels_and_repositories