Saturn - yet another kOS IDE

[Dunbaratu]

A few of the bits of syntax are going to be especially hard to get by examining the code because they literally don't exist anywhere inside kOS's code. I'm speaking of the things like SHIP:SOLIDFUEL or STAGE:SOLIDFUEL.

Any of the resources (the values that appear in the game when you click the upper-right corner of the screen in flight and pulldown the box with the monoprop, electric charged, etc) are found by simply querying the KSP API to ask it. The VESSEL class just has a check that says "If the suffix wasn't found in any of these hardcoded values, try asking the KSP API if it knows of a resource that goes with that word. If so, go query it for the resource." So things like SOLIDFUEL, LIQUIDFUEL, OXIDIZER, and so on, no amount of reading the kOS C# code will ever find them, no matter how the code is restructured.

[Rosco P. Coltrane]

That's very nice to know! Thanks for the info!

Right now it wouldn't be a problem because the syntax checker only checks syntax, so it doesn't really care if the suffix doesn't exist as long as you wrote something after the colon. But it's important for the auto-completion and future semantic checking... hmm... That's quite a big problem... ddddarrrnnnnn.

[Rosco P. Coltrane]

Ok, so here's version 0.3.

This version adds syntax checking, both real-time (can be disable in Settings) and as part of the program packer. I'd look at it as the first iteration of something, which means I'd look at it as something that works most of the time, but can also not work at all.

So don't take it too seriously. There might highlight errors where non exists or not highlight errors that do exist.

Also, I'm still experimenting on where to show the errors. So for example this too approaches:

One is more obnoxious but very visible, the other is more easy on the eye but not necessarily visible or accurate (the error is not on the "}" but on the line before, the dot is missing).

BTW, in a very Microsoft way I tell you this: I know some suffixes wont show up in the auto-completion list. Specially for variables that are used in a for loop. So if you have something like "for eng in enginelist", invoking auto-completion for "eng:" will show nothing. I have to fix this, I know, not much time to do it lately.

[Dunbaratu]

BTW, in a very Microsoft way I tell you this: I know some suffixes wont show up in the auto-completion list. Specially for variables that are used in a for loop. So if you have something like "for eng in enginelist", invoking auto-completion for "eng:" will show nothing. I have to fix this, I know, not much time to do it lately.

I don't think you CAN fix it, because the LIST type holds any generic kOS object of any type and, this is the important bit, is not required to hold heterogeneous types.

Keep in mind that this is legal:

SET mylist to LIST().

set mylist:ADD to V(1,0,0).

set mylist:ADD to 5.1.

set mylist:ADD to V(0,1,0).

Now, after having done that, is "thing:X" valid inside a "FOR thing in mylist {...}"? The answer is: yes it is on the first and third iteration but not the second one.

[Rosco P. Coltrane]

Yes, you're right about that.

My idea (though I haven't given it a lot of thought) was to have at least some sort of idea about what the list is all about. So if the variable was first set with a "list engines" then it probably holds engines... Might hold something else, or one of it's element might, but I guess it's better than nothing. Most of the time the user goes Ctrl-space while iterating a list, he probably means to iterate through the original set of items. If not, he's toasted. But that's life.

This of course only applies to lists created with the "list" command or any other recognizable source. If not then the user is on his own once again. Which makes the whole thing a little useless... we'll see how it goes once I have the semantic checker merged with the rest of the stuff (which will also handle this sort of thing). I'm also concerned about the impact this might have on the speed. It will be an optional feature for sure.

[erendrake]

Really cool work you have been doing. I am excited when we have fewer bugs and i can spend a little time playing KSP with kOS and your editor

[Dunbaratu]

I don't think you CAN fix it, because the LIST type holds any generic kOS object of any type and, this is the important bit, is not required to hold heterogeneous types.

Keep in mind that this is legal:

SET mylist to LIST().

set mylist:ADD to V(1,0,0).

set mylist:ADD to 5.1.

set mylist:ADD to V(0,1,0).

Now, after having done that, is "thing:X" valid inside a "FOR thing in mylist {...}"? The answer is: yes it is on the first and third iteration but not the second one.

Just an addendum to this, although it's not necessarily about Saturn itself:

Because you can do this - make heterogeneous collections like LIST() - it would be nice if kOS supported some sort of an isType() function to help with iterating over such lists. (if this thing is a vector do this, else to that).

[erendrake]

Just an addendum to this, although it's not necessarily about Saturn itself:

Because you can do this - make heterogeneous collections like LIST() - it would be nice if kOS supported some sort of an isType() function to help with iterating over such lists. (if this thing is a vector do this, else to that).

I think it would be a better idea to not make heterogeneous lists in your code. I almost enforced this in the list structure with generics.

[Dunbaratu]

I think it would be a better idea to not make heterogeneous lists in your code.

Object Inheritence. More than one kind of Target, more than one kind of Part, etc.

[Rosco P. Coltrane]

Really cool work you have been doing. I am excited when we have fewer bugs and i can spend a little time playing KSP with kOS and your editor

Thanks! Me too. Darn real life, I haven't booted KSP to actually play in ages... Just a little after the ARM patch to capture an A roid and that was it.

[marianoapp]

We could eventually expose an API in kOS to allow access to the built-in parser, that way Saturn can parse the code and get an AST that is up to date with the latest changes in the syntax.

[Rosco P. Coltrane]

That could also work... hmm...

Right now my strategy is to go DIFF'ing the parser code after a new release and it looks like it is going to work reasonable well. I rewrote my parser to be a copycat of yours for that reason.

The problem is keeping track of suffixes. The ones present in the code could eventually be extracted by a set of scripts... sort of, I guess... Some are harder than others to get but I guess I'll add and add and add extraction "schemes" and eventually the script will get 100% of them (not that it's hard to do it by hand, but you know, more prone to errors). The ones not present in the kOS code but queried to KSP it self, that's another matter. I should play more honestly, I would know those by heart.

My hope right now is that you guys get tired before I do and stop adding stuff!

EDIT: What, another "argento"?!

Edited May 10, 2014 by Rosco P. Coltrane

[marianoapp]

Well since you are already using our formal grammar then there's no need to expose the parser itself.

What, another "argento"?!

Yeah! And we are also both working in related projects... what are the odds, right?

Edited May 10, 2014 by marianoapp

[Dunbaratu]

Well since you are already using our formal grammar then there's no need to expose the parser itself.

The grammar file doesn't contain enough information on its own. For example it tells you that a function call is some identifier followed by a left parenthesis followed by a list of arguments followed by a closing parenthesis. It does NOT tell you which identifiers are functions, however. It won't tell you that MIN(x,y) is a built-in function but ASDF(x,y) is not. Similarly it will tell you what an identifier looks like, but not that "STEERING" is a magic built-in identifier while "PILOTING" is not. A lot of the information Rosco needs isn't in that file.

This is why I support the idea of not using literal strings directly in the file, but instead using strings defined in a single "identifier file" that's just a simple C# class listing all the language strings that are exposed to a user of kOS (and perhaps their intended syntax in some way), and when you add a new suffix, or a new bound variable, you do it by adding the identifier to the identifier file first, then use the name you gave it there.

[Rosco P. Coltrane]

Just in case someone's wondering, no, this is not dead. I've been extremely busy, in fact right now I'm overseas and will continue to be for quite some time. Between that and other hobbies that keep popping up and taking time I almost haven't touched the code in a month (or two?). But, patience, we'll get there at some point.

[Laminator]

I really hope we´ll see an update for this excellent tool pretty soon

Thanks for developing & sharing it!

[Rosco P. Coltrane]

I can say I'm out of the water and back at work and picking up things where I left them. The semantic checker is coming off nicely and of course I have to bring the code up to date with kOS... and download KSP 0.24 that I haven't checked yet.

See you around.

[Dunbaratu]

There are some ideas that are currently fuzzy that are floating about in my head that I'd like to hash out with @erendrake about how we might make the kOS language compiler a bit more "regimented" in that all terms and keywords should be registered in some consistent way. This would help not only for your editor to have help with syntax highlighting (and in a way that programatically can be updated when the language evolves without human manual labor), but also for syntax error detecting (i.e. user tries to use a variable name that is also a built-in variable name - a case that is currently uncaught.)

[Rosco P. Coltrane]

Having that stuff outside compiled code would certainly be very nice. Then Saturn could just "fetch" all that data directly from the GameData folder at startup / "first boot" and it would be up to date no matter what... and I wouldn't have to move a finger

But more realistically speaking, it would be pretty good to at least have that info in some condensed form in fewer places, or written in such a way that having a script extracting it would be very feasible.

EDIT: ha, forgot again about those suffixes that come directly from KSP and not from kOS. Darrrrrn.

Edited August 17, 2014 by Rosco P. Coltrane

[Dunbaratu]

EDIT: ha, forgot again about those suffixes that come directly from KSP and not from kOS. Darrrrrn.

Do you mean the part resources, like LIQUIDFUEL?

I think you can print the comprehensive list of them with:

(csharp code)

PartResourceDefinitionList resources =  PartResourceLibrary.Instance.PartResourceDefinitionList ;

foreach (PartResourceDefinitionList res in resources)
{
    UnityEngine.Debug.Log("There is a resource called: \"" + res.resourceName + "\"." );
}

So in principle we should be able to add them to some programmatic storage of names.

Edited August 17, 2014 by Steven Mading

[erendrake]

Do you mean the part resources, like LIQUIDFUEL?

I think you can print the comprehensive list of them with:

(csharp code)

PartResourceDefinitionList resources =  PartResourceLibrary.Instance.PartResourceDefinitionList ;

foreach (PartResourceDefinitionList res in resources)
{
    UnityEngine.Debug.Log("There is a resource called: \"" + res.resourceName + "\"." );
}

So in principle we should be able to add them to some programmatic storage of names.

one possible issue is that many addons, like TAC, Interstellar, Kethane. Add their own resources.

that pain is offset by the fact that each mod declares their resources in flat files. so you should already be able to scrape all of the resources from the gamedata folder.

[Rosco P. Coltrane]

Ok, I give up.

I just can't catch a break. I thought I could find a balance with other stuff and allocate free time to work on this, but as things turned out, I can't. I'm sorry for those that followed this waiting to have some decent half finished program some day, but I just don't have the freaking time and it starting to feel more like a burden than a hobby, and that can't be right.

As to why I don't have the time, sort of provide a justification, I of course have to work every day and have a life and all that mandatory things you do every day, but then I also have more hobbies, maybe too many of them. And as I just discovered, software is not one of them anymore?... Strange, as it has been my main hobby since I was 16 and my real job for the past 7 years... But things apparently change. Dunno.

Anyway... Sorry. See you around if I somehow come back to play KSP some day... I hope. My last real playtime was around 0.20.

[Drew Kerman]

bummer! But so it goes. As it is, the IDE is still waaaay better than a plain text editor and I use it for all my scripts. So thanks for your work!

[immelman]

Thank you for taking the time to write this. It's making learning KOS a lot less painful...

[Montserrat]

Yup guys, noobie here.

I must be a total idiot but i cant make the program work, i want to open my scripts from the archive, but every time i try i got error: "KSP folder no found.Please go to the settings and make sure it's set."

I have no idea qhat im doing wrong, of course i've set de ksp directory one thousand times, saved, closed and opened the saturn....unchecked the "read only" check in the ksp folder...Can someone write the exact instrucctions to install it for me? i'm feeling like an idiot...

Thanks in advance....