SublimeKSP Updates (current version: 1.19.0)
- Thread starter EvilDragon
- Start date
OP
OP
EvilDragon
KSP Wizard
Updated for 1.17.0 release!
OP
OP
EvilDragon
KSP Wizard
Updated for 1.17.1 release!
OP
OP
EvilDragon
KSP Wizard
Updated for 1.17.2 release!
AudioBrewers
Are you listening?
Hmmm... So it's been some months since I've opened SublimeKSP but today I tried to compile a file that used to work perfectly fine and found what seems to be a change in the way SublimeKSP behaves when compiling, maybe @EvilDragon can help me...
So I had made a modular "import as", i.e. Import the same file as first, as second, as third, to then use first.function second.function, third.function... this used to work perfectly fine in the past, and now I get an error
Screenshot below:
Am I mising something? the above code used to work perfectly fine and now it doesn't
It says "second.init_function has not been declared!", so clearly in "first" everything runs normal and the compiler crashed in "second".
If I remove "second" and leave only "first" it works... Any ideas?
So I had made a modular "import as", i.e. Import the same file as first, as second, as third, to then use first.function second.function, third.function... this used to work perfectly fine in the past, and now I get an error
Screenshot below:
Am I mising something? the above code used to work perfectly fine and now it doesn't
It says "second.init_function has not been declared!", so clearly in "first" everything runs normal and the compiler crashed in "second".
If I remove "second" and leave only "first" it works... Any ideas?
OP
OP
EvilDragon
KSP Wizard
There are some issues with namespaces that we have tracked, however not fixed yet. I would suggest not using namespaces for the time being. Sorry!
AudioBrewers
Are you listening?
Ok, thank you! Do you know the latest version that worked? Or should I roll back to whatever pre-23?
OP
OP
EvilDragon
KSP Wizard
Truthfully it's been quite some versions now... I don't recall when things started going weird to be honest.
Hello everyone!
I have updated the original plugin that's available on my web page for K7.7. It doesn't include the various other new additions added to the version available on Github, so most people will probably want to continue to use the one on Github.
But I thought I'd upload it in case it's of some use - perhaps as reference (I just hope it won't cause confusion).
New:
* continue statement
* sort function with variable number of arguments
* in_range support for real
* new boolean operator xor
* new bitwise operator .xor.
* mod operator with support for real numbers
* new UI widget types
* abs function supports both integer and real numbers and has dynamic return type depending on its argument type
* new builtin functions and variables
* updated function signature for builtin functions that now return async IDs
There's not yet any specialized support for the "const" modifier, so this version of the transpiler will still try to inline all usages of constants itself and complain if an initialization expression doesn't seem "constant enough" which is a small limitation.
PS. I think the version on Github got the operator precedence wrong for the new bitwise .xor. operator (search for "precedence" in the ksp_ast.py and ksp_parser.py files to find the relevant sections and compare with my version. The ".or." operator should have lower precedence than ".xor." according to my experiments). DS.
Cheers,
Nils
I have updated the original plugin that's available on my web page for K7.7. It doesn't include the various other new additions added to the version available on Github, so most people will probably want to continue to use the one on Github.
But I thought I'd upload it in case it's of some use - perhaps as reference (I just hope it won't cause confusion).
New:
* continue statement
* sort function with variable number of arguments
* in_range support for real
* new boolean operator xor
* new bitwise operator .xor.
* mod operator with support for real numbers
* new UI widget types
* abs function supports both integer and real numbers and has dynamic return type depending on its argument type
* new builtin functions and variables
* updated function signature for builtin functions that now return async IDs
There's not yet any specialized support for the "const" modifier, so this version of the transpiler will still try to inline all usages of constants itself and complain if an initialization expression doesn't seem "constant enough" which is a small limitation.
PS. I think the version on Github got the operator precedence wrong for the new bitwise .xor. operator (search for "precedence" in the ksp_ast.py and ksp_parser.py files to find the relevant sections and compare with my version. The ".or." operator should have lower precedence than ".xor." according to my experiments). DS.
Cheers,
Nils
OP
OP
EvilDragon
KSP Wizard
Wow, the man is alive! :O
Yeah I wonder how different your fork is vs nojanath one that became de facto mainline release (helped by the fact it's directly available from Sublime's Package Control)... EDIT: Yeah, wow, it's super duper very different. Lots of things are missing! ^_^;
(BTW the operator precedence I think matches how it is in Kontakt internally. But I'm all ears if you have some repro cases etc.!)
Yeah I wonder how different your fork is vs nojanath one that became de facto mainline release (helped by the fact it's directly available from Sublime's Package Control)... EDIT: Yeah, wow, it's super duper very different. Lots of things are missing! ^_^;
(BTW the operator precedence I think matches how it is in Kontakt internally. But I'm all ears if you have some repro cases etc.!)
Btw. I intended to write "real numbers" - not for it to be in the sense of "for real man"
on init
message(1 .or. 1 .xor. 1)
end on
This will yield different results depending on whether it's pasted into Kontakt as is or compiled first.
Kontakt interprets the expression as 1 .or. (1 .xor. 1) which equals 1.
The compiler version on Github currently will interpret it as (1 .or. 1) .xor. 1) which equals 0.
Just thought I'd mention this since I ran some tests myself before arriving at the exact operator precedence. I'd make a proper pull request if I just had a bit more time to spare.
A big thanks by the way to everyone who has continued to develop the plugin.
Last edited:
OP
OP
EvilDragon
KSP Wizard
Thanks, will fix this!
OP
OP
EvilDragon
KSP Wizard
Updated for 1.18.0/1 release!
maxchristensenaudio
Observant Sound
OP
OP
EvilDragon
KSP Wizard
Hm that's curious. Could be because of addition of .sublime-color-scheme files in the package (until now we had .tmTheme files in there and that's what you had set). Anyways try to manually set the color scheme again, see what happens.
Norwayguy
Member
i get this whenever I open sublime since the update . Is there an easy fix? there are no colors anymore Version 1.18.1
. i tried getting more color schemes from package control. the color schemes change to background colors. they show as correctly installed but there are no colors for code types
ksp isnt a choice anymore for code type in the bottom right
. i tried getting more color schemes from package control. the color schemes change to background colors. they show as correctly installed but there are no colors for code types
ksp isnt a choice anymore for code type in the bottom right
Attachments
Last edited:
Same for me.
maxchristensenaudio
Observant Sound
How do I set the colors? I've only set themes so far.
I rolled back to the previous commit and the error message goes away. But even here somthing seems weird. If I go down the list of KSP themes, the selector UI box seems to bug out. The box disappears, and áll the theme options strings get crammed together.
I rolled back to the previous commit and the error message goes away. But even here somthing seems weird. If I go down the list of KSP themes, the selector UI box seems to bug out. The box disappears, and áll the theme options strings get crammed together.
OP
OP
EvilDragon
KSP Wizard
Hmmm ok so looks like there's some clash between the old .tmTheme files and new .sublime-color-scheme files, they don't require the path to the package in them. So for example:
should be:
in KSP.sublime-settings file.
There also seems to be a minor issue in .sublime-syntax file (an extra newline where it shouldn't be), so I'm gonna have to push a small update for that.
"color_scheme": "Packages/KSP (Kontakt Script Processor)/KScript Dark.sublime-color-scheme"should be:
"color_scheme": "KScript Dark.sublime-color-scheme"in KSP.sublime-settings file.
There also seems to be a minor issue in .sublime-syntax file (an extra newline where it shouldn't be), so I'm gonna have to push a small update for that.
