[WIP] Jebnix - A kOS Alternative

[Rokker]

I'll do KS over JS or lua any day. Only issue I had with KS was the fact that I kept using semicolons instead of periods, but that's not a big deal.

If kerboscript gets dropped, lets change to MEL! (or Ch, or Rexx, or Squirrel, or AngelScript, etc)

You win the award for naming the most programming languages that I have never heard of. If he were going to base it off an existing language, I would recommend lua, C ( or any of its children languages including Java, JavaScript, C++, C#, possibly Perl,) BASIC (Which I love for its "DO... LOOP{UNTIL|WHILE}" function), possibly even something like TIBasic from the Texas Instrument programming calculators. Just something that is extremely common, that a lot of people have come across at least once in their lives, that a lot of people interested in this would already know or if they don't know it, would be extremely easy to learn. Oh, except html. I know html is very common and whatnot, but I feel it wouldn't work well at all for the purpose of a programmable autopilot.

[Sacred Aardvark]

You win the award for naming the most programming languages that I have never heard of.

MEL is for Maya (a 3d program), iirc Ch is a scripting language for use with C (or something like that, my memories are a bit vague) and I think Squirrel was used in Portal for some events. (Rexx and AngelScript I just ran into in google while I was checking what language AE uses for expressions (it's JS btw) )

Ofc MEL is similar to Perl and Squirrel apparently has a C like syntax, so the whole point I was making is a bit vague

If he were going to base it off an existing language, I would recommend lua, C ( or any of its children languages including Java, JavaScript, C++, C#, possibly Perl,) BASIC (Which I love for its "DO... LOOP{UNTIL|WHILE}" function), possibly even something like TIBasic from the Texas Instrument programming calculators.

Java is the only one I'd vehemently oppose, coding that always felt like I was shooting myself in the leg (i know it has its supporters though). Possibly C# too since from what I've seen it looks like an outside-of-marriage child of Java and C++ (so you know, only hitting yourself in the leg? since c++ is nice), but I don't know much about it. Basic would be fun for the "oldskool" lolz. (though I've heard a saying that the easiest way to ruin an upcoming programmer is teach them basic (hey, maybe that's why I suck? ))

Just something that is extremely common, that a lot of people have come across at least once in their lives, that a lot of people interested in this would already know or if they don't know it, would be extremely easy to learn. Oh, except html. I know html is very common and whatnot, but I feel it wouldn't work well at all for the purpose of a programmable autopilot.

I'm a bit torn on this. Part of me wants a language I already know for ease of start, while another part wants some real language I don't know so I'll have incentive to learn it and a third part wants something completely made up because it's Kerbals after all... I'm just glad I'm not the guy who has to make the call

Though since the plan to my understanding is that Jebnix will be able to support multiple languages via additional dll's, there's potential for everyone to be happy (assuming someone will code the dll for <desired language> )

[edit] that's funny, ******* child got censored. Does that mean I can't call a female dog a ***** ?

[edit 2] okay I'm far too amused by this, I think my blood sugar is a bit low (or high? anyhoo). As you were

Edited February 1, 2014 by Sacred Aardvark

[Rokker]

MEL is for Maya (a 3d program), iirc Ch is a scripting language for use with C (or something like that, my memories are a bit vague) and I think Squirrel was used in Portal for some events. (Rexx and AngelScript I just ran into in google while I was checking what language AE uses for expressions (it's JS btw) )

Ofc MEL is similar to Perl and Squirrel apparently has a C like syntax, so the whole point I was making is a bit vague

Java is the only one I'd vehemently oppose, coding that always felt like I was shooting myself in the leg (i know it has its supporters though). Possibly C# too since from what I've seen it looks like an outside-of-marriage child of Java and C++ (so you know, only hitting yourself in the leg? since c++ is nice), but I don't know much about it. Basic would be fun for the "oldskool" lolz. (though I've heard a saying that the easiest way to ruin an upcoming programmer is teach them basic (hey, maybe that's why I suck? ))

I'm a bit torn on this. Part of me wants a language I already know for ease of start, while another part wants some real language I don't know so I'll have incentive to learn it and a third part wants something completely made up because it's Kerbals after all... I'm just glad I'm not the guy who has to make the call

Though since the plan to my understanding is that Jebnix will be able to support multiple languages via additional dll's, there's potential for everyone to be happy (assuming someone will code the dll for <desired language> )

[edit] that's funny, ******* child got censored. Does that mean I can't call a female dog a ***** ?

[edit 2] okay I'm far too amused by this, I think my blood sugar is a bit low (or high? anyhoo). As you were

I would prefer Java the most really since I took it as a high school course and it is one of 2 programming languages I have actually learned to a good extent (the other being a horrible, math-centric language known as MATLAB that I had to learn for my freshman year of college.) As for the made up Kerbal one, that would just be take a programming language, take all the commands, translate their words to spanish and write them backwards.

[Sacred Aardvark]

I would prefer Java the most really

http://thumbs.dreamstime.com/z/get-back-devil-spawn-23805742.jpg

[edit] holycrapthatwasbig, into a link you go.

j/k, you're entitled to your opinion

As for the made up Kerbal one, that would just be take a programming language, take all the commands, translate their words to spanish and write them backwards.

As far as solutions go, that's actually kinda elegant. It'd cover two of my three divided desires, you'd have the familiar design of a real language with the newness of "made up" commands.

Doubt anyone else would like it though

[woodywood245]

Just out of curiosity will this use the same mod plugin system, so that mods written to work with kOS will work with this without being changed?

Yes, I'm planning on using the same plugin system, at least for compatibility purposes. I may or may not implement another, less bizarre setup, but I haven't decided for sure.

[woodywood245]

Jebnix Language

The original goal of Jebnix was to be a kOS replacement, using an improved version of the Kerboscript language. That goal still exists, and is not changing. I started working on this project three months before I announced it.

The Jebnix codebase is now nearly 4000 lines of code and comments. Just the scripting engine has reached more than 2100 lines. It's not that long, but that's weeks of work dedicated to a single project that I'm working on in the little spare time I have.

The language I'm implementing is Kerboscript++. End of story.

I may, in the future, as part of the idea of allowing the code to be compiled, add additional languages by merging a separate, ongoing project into this one, which will have a variety of language options, including a C-like language, and a BASIC-like language. This is not a guarantee, and you probably shouldn't bet on it.

If you'd prefer an immediate alternative to Kerboscript, there's another user named secretformula who's working on a scriptable guidance system called JsKsp, which is going to be implemented for JavaScript. I don't know the state of that project. There's also this: http://kerbalspaceprogram.com/agc/, the Automated Guidance Computer, which has some interesting features, and the language is LISP. And of course, there's the classic, ProgCom http://kerbalspaceprogram.com/0-18-4-progcom-cpu-emulator/, which lets you write everything in an assembly language.

I'm not saying these are good alternatives, and I'm not saying that my decision to write this thing for KerboScript is a great idea. I chose KerboScript because it was something that all kOS users are familiar with, and because it's simple and inflexible syntax makes it so easy to parse. The goal of the language was to be something easy for non-programmers to pick up. I don't know if that's actually what happened, and I know the language drives real programmers crazy, but this is what I'm doing, plain and simple.

[Camacha]

I feel it is going to get very hard to choose the best alternative pretty soon

[Garek]

I feel it is going to get very hard to choose the best alternative pretty soon

In my opinion, this depends on which of them, if any, gets support from/for mods like RemoteTech 2 and Infernal Robotics.

[Camacha]

In my opinion, this depends on which of them, if any, gets support from/for mods like RemoteTech 2 and Infernal Robotics.

Yes, that will be a big factor, or maybe flexibility in general. I am just a bit scared of a scenario where two or three alternatives all provide really great features, just not together in one package. At best that would mean using more kOS units at the same time, probably tailoring code for them, at worst it would mean simply having to pick one and leaving the rest out.

[woodywood245]

In my opinion, this depends on which of them, if any, gets support from/for mods like RemoteTech 2 and Infernal Robotics.

I'm planning on having mod support for RemoteTech 2, and possibly Infernal Robotics, but I want to get everything working first. I will definitely have mod support for RasterPropMonitor, however I'm not exactly sure how much you'll be able to do through RPM yet. Keyboard support would be nice, but if not, I do have alternate plans. Either way, Jebnix will ship to work on RPM.

Edited February 10, 2014 by woodywood245

[djungelorm]

Love the modular design - hope this all comes to fruition!

I'd been toying with the idea of writing a remote procedure call server for KSP, so that I can write python scripts to control my craft - then I came across this I'd be happy to implement a language extension to add python support into Jebnix once it gets to that stage.

My RPC server idea was to implement a TCP server that runs inside KSP and listens for requests (e.g. get orbital data, set heading... serialized using something like Google's protocol buffers) and returns responses along the same communication channel. This interface would completely separate the server from whatever language you want to write scripts in. You'd be able to write programs in any language (as long as it supports protocol buffers and can communicate over TCP). It'd also allow you to run your script in the native environment for that language (e.g. through the standard python interpreter) and also from wherever you like (thanks to the TCP server).

This RPC server might also work well as a "scripting engine" for Jebnix itself. It could expose commands from the Jebnix interpreter to the outside world via the TCP server.

Or maybe I should do this as a separate mod? What do you think?

[woodywood245]

Love the modular design - hope this all comes to fruition!

I'd been toying with the idea of writing a remote procedure call server for KSP, so that I can write python scripts to control my craft - then I came across this I'd be happy to implement a language extension to add python support into Jebnix once it gets to that stage.

My RPC server idea was to implement a TCP server that runs inside KSP and listens for requests (e.g. get orbital data, set heading... serialized using something like Google's protocol buffers) and returns responses along the same communication channel. This interface would completely separate the server from whatever language you want to write scripts in. You'd be able to write programs in any language (as long as it supports protocol buffers and can communicate over TCP). It'd also allow you to run your script in the native environment for that language (e.g. through the standard python interpreter) and also from wherever you like (thanks to the TCP server).

This RPC server might also work well as a "scripting engine" for Jebnix itself. It could expose commands from the Jebnix interpreter to the outside world via the TCP server.

Or maybe I should do this as a separate mod? What do you think?

I've been wanting something like this for quite a while, but I don't have the expertise to implement it (network programming is a field that I'm almost completely unfamiliar with). There's a kOS variant that has the ability to use the kOS console remotely, but it's quite buggy and wasn't very usable.

When the time comes, I'd be happy to help you implement this for Jebnix to make it as streamlined as possible.

[erbmur]

I have had a read through the previous posts but didn't seem to find a mention about this, if I missed it I apologies in advanced:

What are peoples thoughts on/the ability to have running programs on vessels that are not the active vessel? For example, a probe would be able to perform course corrections midway through a planet transfer without having to set an alarm/switching to the vessel?

[Dunbaratu]

I have had a read through the previous posts but didn't seem to find a mention about this, if I missed it I apologies in advanced:

What are peoples thoughts on/the ability to have running programs on vessels that are not the active vessel? For example, a probe would be able to perform course corrections midway through a planet transfer without having to set an alarm/switching to the vessel?

My thought is that I'd love to have it, but that's combined unfortunately with the belief that it's completely and utterly impossible for a mod to do that because the base KSP game makes it impossible to alter the course of objects that have been put on rails, and furthermore it's actually impossible for the parts the vessel is made of to even "exist" so to speak. I have no idea what the internals of Jebnix do, but if it's anything along the lines of "for each computer part that exists on a vessel somewhere, execute some of its program right now." then there's no way this could be implemented because the computer part wouldn't even exist in the physics engine for KSP at all when the vessel is on rails. That would mean that even if you're talking about doing something with the computer program that isn't going to change the craft's path, you still can't execute code on the computer part because the computer part itself isn't even loaded into KSP's list of "all the parts that exist right now" data structure.

On the other hand, one thing that would be handy would be a hook between Kerbal Alarm Clock and Jebnix that would allow a Jebnix program to set/remove alarms in Kerbal Alarm Clock. It would be nice to have something where a program could, say, calculate the right moment for a Hohmann transfer burn, set the manuever node for it, and also make Kerbal Alarm clock set an alarm a few minutes before the burn.

[erbmur]

My thought is that I'd love to have it, but that's combined unfortunately with the belief that it's completely and utterly impossible for a mod to do that because the base KSP game makes it impossible to alter the course of objects that have been put on rails, and furthermore it's actually impossible for the parts the vessel is made of to even "exist" so to speak. I have no idea what the internals of Jebnix do, but if it's anything along the lines of "for each computer part that exists on a vessel somewhere, execute some of its program right now." then there's no way this could be implemented because the computer part wouldn't even exist in the physics engine for KSP at all when the vessel is on rails. That would mean that even if you're talking about doing something with the computer program that isn't going to change the craft's path, you still can't execute code on the computer part because the computer part itself isn't even loaded into KSP's list of "all the parts that exist right now" data structure.

So basically what you are saying is that the kerbol system is in fact inside a black hole, and everything that happens is happening super slowly because it is proximity to the center, and when it eventually reaches it, Jebnix will be released?

[jxi24]

On the other hand, one thing that would be handy would be a hook between Kerbal Alarm Clock and Jebnix that would allow a Jebnix program to set/remove alarms in Kerbal Alarm Clock. It would be nice to have something where a program could, say, calculate the right moment for a Hohmann transfer burn, set the manuever node for it, and also make Kerbal Alarm clock set an alarm a few minutes before the burn.

Even better would also be for Jebnix to have the ability to automatically switch to said vessel and preform the action and then return to the previous vessel. Which I do not know if it is even possible to do, but would be extremely useful.

[Camacha]

Well, to be honest, a number of things have been called (nearly) impossible and achieved, among which multiplayer, life support for all vehicles (even non-active ones) and tracked vehicles. Even though there are some obvious problems, I think saying it is impossible has proven to be dangerous

[Dunbaratu]

Well, to be honest, a number of things have been called (nearly) impossible and achieved, among which multiplayer, life support for all vehicles (even non-active ones) and tracked vehicles. Even though there are some obvious problems, I think saying it is impossible has proven to be dangerous

I didn't say impossible. I said impossible *without changing KSP itself*. The limitation that's causing the current impossibility is coming from the core game explicitly denying attempts to do it. Although when you mention KMP, it does occur to me that while KSP cannot do this, multiple instances of KSP, all attached to a KMP server, might be able to if you run a seperate instance of KSP for each 2.5km radius zone that you want to run code in, and have them all report their changes to a KMP server. But that would still technically mean KSP isn't doing it. (KMP is).

It may be possible after KSP implements their own multiplayer, but then like I said that would be a case of changing KSP itself. And I never said it was impossible - I said it was impossible *without changing KSP*. In other words, Jebnix on its own would be powerless to do it.

Edited February 15, 2014 by Steven Mading

[Camacha]

I didn't say impossible. I said impossible *without changing KSP itself*.

I still respectfully disagree, there are different roads that lead to Rome I remember Squad scratching their heads when it came to tracks or scaling up the universe. Both were viewed as impossible, both have been achieved by modders.

I think it is hard to ascertain a difference between modding KSP and changing KSP itself anyway. That is more of a semantic discussion than a real hard seperation.

[Dunbaratu]

I still respectfully disagree, there are different roads that lead to Rome I remember Squad scratching their heads when it came to tracks or scaling up the universe. Both were viewed as impossible, both have been achieved by modders.

I think it is hard to ascertain a difference between modding KSP and changing KSP itself anyway. That is more of a semantic discussion than a real hard seperation.

I don't think it's a difficult thing to separate at all:

Is it accomplished entirely by making calls into KSP's current API? Then it's a thing a mod can do without KSP itself changing.

Did it require doing something besides just making calls into KSP's current API? Then it's a thing a mod can't do without KSP itself changing. (Note changing something about the API itself counts as KSP changing, which is why I was careful to use the word "current" the way I did.)

[Camacha]

I don't think it's a difficult thing to separate at all

Of course, that is an easily defensible definition, especially when you have a programming background However, there are some other definitions of changing KSP itself that are quite reasonable too: any change to KSP - including art and assets, any change that requires code or any change that only Squad can make. All of those definitions are defensible and that is why I mentioned semantics.

Anyway, I think we are pretty much in agreement anyway: running kOS on multiple units in different places is a tall order, but not impossible by any means. Right?

[mic_e]

Just to demonstrate that it would be possible: eggrobin's Principia N-body physics mod demonstrates that modifying an on-rails vessel's trajectory is very well possible (though a lot of work and hacking is involved), and course correction fuel could be managed separately by the mod and then applied as soon as the vessel is loaded again.

It would be very, very ugly and very, very much work to implement, though.

[KvickFlygarn87]

Here's a suggestion: Orbital archives - You can move your scripts to satellites in orbit. To not make this redundant, limit the storage in the normal archives and force line of sight where you want to move it.

Also, hard drive part - larger storage.

Nobody seemed to read this, so here it is again!

[Dunbaratu]

Anyway, I think we are pretty much in agreement anyway: running kOS on multiple units in different places is a tall order, but not impossible by any means. Right?

I actually don't think we are in agreement. I'm saying that it's unreasonable to try to fix the problem in a mod when the problem is caused by the main stock game, at a very deep level of that main stock game. It would be on par with trying to make a 64-bit version of KSP for Windows, by adding a mod.

[Camacha]

Woodywood, how do you see the changes being made to the language by Erendrake combining with your work? Are you planning to follow his changes and additions, or are you taking Kevin's kOS as canonical and running with it from the point he left off?

I'm saying that it's unreasonable to try to fix the problem in a mod when the problem is caused by the main stock game, at a very deep level of that main stock game.

It is probably the only way it is going to happen. Reasonable or not, if multiple kOS units running at the same time is the goal, that is what needs to be done.