JebmaScript - KOS Alternative using Javascript

[JoerT]

I've recently 'discovered' KOS, and I absolutely love what it lets me do. While mechjeb feels like cheating, getting the same effect through a program I've made myself feels very good.

The issue I have with KOS tho, is that it's tricky and hacky to make reusable code. You can make various scripts and pass in some parameters, but the way this works feels a bit dirty to me. I see the charm of having a system feel Apollo era, but I'd rather have something more.. clean I guess. Also, the syntax of KOS, with a DOT as line terminator and odd control structures (UNTIL, WHEN THEN and IF without THEN) makes it very hard for me to write code that works right off the bat.

Disclaimer! Mad props to the developer(s) of KOS. I love what they made and really hope they keep it up. I do NOT mean to bash KOS. I just have a personal preference which is not fully matched by KOS.

I'm a web-developer and work with javascript extensively. I love javascript and the way it works with closures. I thought it would better suit my needs.

After searching around the web a bit, I found a couple of fledgeling projects trying to do the same thing, but I couldn't find any finished addon.

This all made me poke around in add-on development for the first time. I fired up Visual Studio and after a bit of hacking and brushing up my C# I've got a working Javascript interpreter running inside KSP, printing all kinds of trash to the console. It's a long way from anything half useful, but so far I think this really has a chance of actually working.

The plan is to make the thing very much event driven. Loops would work by hooking into an update event, which gets called at regular intervals.

I was wondering if anyone else thinks this is a good idea, or if I would be making this just for me (which would be fine by the way).

What I want to avoid, is reinventing the wheel, so if anyone knows about a similar or identical addon, please yell ;p

[Kerbart]

There's a remote procedure call add-in that communicates through a tcp/ip connection; theoretically you can hook up anything "on the outside" provided you write an interface for it.

There hasn't been a lot of work on it lately, sadly. The standard interface is in Python which works fine for me but I'm sure if you want to sink your teeth into it you can write an ecmascript/javascript interface for it.

At the very least you could use it to see how something like this *could* work and reverse engineer a new version. Include a Python interface when you do, please.

[Van Disaster]

Well, personally I'd rather it was Lua - it also has closures, it's a very small language, and as far as I can tell, designed for embedding ( MJ once shipped with embedded lua ) - but if you really want to try javascript, why not.

[Dunbaratu]

Hey, one of the two active devs for kOS here. Just in case you don't know kOS's current design (although this is not the original design by Nivekk, who no longer maintains the project), is that kerboscript is merely the default language that is bound to the low level virtual machine's opcodes,. Once it compiles to those opcodes in an almost JIT way (not quite JIT), then the program just executes off those opcodes alone, ignoring the higher level script it came from.

The point being that in principle it should be possible to compile more than one language down into those virtual opcodes, even though we haven't had the time to address that and give it a try yet. There is someone trying to make a .NET converter that will take a C# .NET DLL file and convert its opcodes over into kOS opcodes, but it's kind of hard because some of the limitations of kerboscript are also limitations of the underlying virtual machine itself, like not having a means of making local variables for example.

If you want to make a new system from scratch, I'd love that and enjoy the "competition", so to speak - as it would force us to keep pushing.

But alternatively, if you want to look into the possibility of making a javascript compiler FOR kOS we'd be happy to work with you on that.

The reason I mention it is that a heck of a lot of what goes into kOS isn't *really* about the language itself and instead is a bunch of utilities connected to the interface between the language and the stock game. Making the in-game terminal window work, making the new telnet feature work, dealing with the lock steering mechanism and connecting it to KSP's API, etc. If you start a new project from scratch, there's a lot there that you'd have to re-implement.

While there might be a lot of headache around trying to work together (especially since we'd probably need to do a lot of stuff at the low level to change the opcodes, but we'll have to do that anyway as I'm in the midst of designing a function call (with local variables finally) system for kerboscript.

Another possibility may be to try to split kOS apart into two different mods - one that is the language and one that is the utilities (like the terminal and autopiloting system and so on), so that the utilities part of it can become a shared thing used by more than one mod (sort of like how RasterProp Monitor works).

Anyway, I'm just throwing ideas out randomly here. I have no idea just how workable this all really would be.

As for if you do want to go do it from scratch, here's a few things to keep in mind that we've run into in kOS that you'll run into as well and want to consider what you'd like your solutions for them to be:

1 - Unity and KSP are not threadsafe, so you must do one of two things:

1.A - Break up your script's running into small chunks that can be run a little bit per Update() or FixedUpdate() callbacks (depending on which you want to use - kOS uses Update() which is wrong and we have to change that some day to FixedUpdate()). The main Unity program runs all in one thread, and makes calls into your mod's update or fixedupdate callback methods. These callbacks MUST NOT take too long to run, and mustn't ever perform any blocking I/O activity like waiting for a keypress, or waiting for network traffic. Thus if your user writes a long-lasting loop in their script, you have to find a way to execute that loop a bit a few chunks at a time and save the state of things between chunks. (For example if you have the C# code "while (true) {}" in one of your callbacks, you actually freeze the entire KSP game because everything your mod is doing is in the same thread as the main game.) kOS achieves this by compiling the kerboscript into lower level opcodes and then lets the virtual machine only run a fixed number of the opcodes per Update() call.

1.B - The other approach would be to run your script in a separate thread that can just run as fast as it feels like, but then to do that you must make sure it never makes any use of any Unity or KSP API calls directly from the script's thread. What you'd probably have to do then is devise some sort of queue or stream of marshalled API call parameter information that is used to pass these requests from your script thread to your main Update() or FixedUpdate() callbacks, which DO run in Unity's main thread, which can answer them, put the answer back out on the stream or queue, and let the script's thread then see them and act on them. While conceptually cleaner maybe, it's a heck of a lot more work because you then have to pass back a LOT of data that way for a bunch of different things. Every time the script tries to read the ship's position, or velocity, or mass, or fuel remaining, or tries to alter the throttle, or set the steering controls, it's going to have to do it through this system, and that means you have to design how all of that is going to get marshalled up and sent from one thread to the other.

2. Unless you pay money to Unity for the professional development suite, you CANNOT add your own fonts to the game for your mod. The free development suite doesn't allow you to because it requires the creation of an asset bundle. It won't let you read a TTF file directly, **EVEN THOUGH the Unity documentation says it works without mentioning the fact that it doesn't in the free version, grumble!**. You just can't. The fact that this is the case is not well documented, and took us a long time to figure out. I don't begrudge Unity for having features that only work in the professional version, but they should freaking TELL YOU in their documentation when their instructions won't work without it. Anyway, the fact that you can't add your own fonts becomes a problem with the terminal window. SQUAD has a few fonts you can use in their own asset bundle that the game ships with, but they never put a monospaced font into their bundle of fonts. If you want a monospaced font to appear anywhere in the game, you end up either having to buy professional (expensive) Unity, or you have to fake it by manually painting rectangular zones from a template bitmap file into coordinates of the window, which is what kOS does.

3. The internal coordinate system of KSP is notoriously messy because it keeps changing depending on circumstance and the XYZ axes don't stay put in the same orientation throughout the life of your campaign savegame. It's fine if only modders have to deal with it, but if you want to expose users who write their own scripts to it, they'll complain that your mod is all broken and messed up when in fact that's what KSP's system *really does* look like. You'll need to deal with finding a way to mask some of the ugliness away. (kOS doesn't fully succeed at this but it helps a little bit by always making it look to the script as if the universe's origin is centered on the CPU's ship whether it is or not).

4. Some parts of the KSP API make the assumption that you are only interested in working with the "active vessel", which is the one the player is in control of. Once you introduce autopilots into the picture, they can be operating on other nearby vessels that aren't the "active" one. We've tried as hard as we can in kOS to make the rule be that everything you affect about the ship is affecting the ship the CPU part is attached to, which might NOT be the one the player is in control of.

Well, there's others, but I've let this post get too long.

The tl;dr version is this: There's a lot of code inside kOS that isn't dependent on the fact that the language is kerboscript. There may be an opportunity to do some useful sharing of work here.

The person to contact is erendrake. He handles most of the high-level archetecture stuff like organizing the code tree, and dealing with the integration of DLLs and so on. I get down into the nitty gritty of things like parsers and opcodes and telnet RFCs, and so on. I'm more of a C++/Java programmer used to UNIX and makefiles and so on. Erendrake is more into how C# does things and I only learned C# specifically FOR doing kOS, so the way that Microsoft designed all that to work feels entirely alien (and a times very wrong) to me.

You should *definitely* contact erendrake and discuss possibilities of shared work in some fashion or another. He's usually very much in favor of that sort of thing. One caveat, though, is that kOS is licensed under GPL3, and that legally requires that if its code is ever mixed together with other code into the same codebase, that the other code has to be GPL3 as well. The fact that it uses GPL3 quite *literally* cannot ever be changed by us because it contains code from an original author who fell off the face of the internet a while ago and we have no idea how to contact him. Without permission from him, it would be illegal to change the license under which he chose to release his code.

Edited February 27, 2015 by Steven Mading

[erendrake]

Both kOS devs here with the same message. We have wanted to have support for other languages in kos so if you want to join forces we would love to help you add this to kos. I want KOS to be a tool to help people learn to code and Javascript would be my first choice for an additional language.

Like Steven said, if you don't want to join us we are happy for the competition ☺

[JoerT]

Hey Steven, erendrake,

Thanks for your prompt and insanely detailed reply. Judging by all that, I'm starting to thing that this thing may be more involved than I'd like it to be. Hooking JS into KOS sounds amazing tho.

For now, I'm still experimenting with this thing and getting my feel for c# again. Got a few things that I'd like to try out and play with. I'll get back to you on where we may go from here.

Currently a bit busy with things, but when I find a bit more time I'll post a more indepth reply to your post Steven.

Thanks for taking this so good by the way. I was a bit worried that my starting this project would not be appreciated by you guys.

[CoffeeKills]

Did you get it working?

[Stone Blue]

Wow... I didnt even realize how old this thread was till I saw the difference in timestamps between CoffeeKills' post & JoerT's... lmao

Talk about necro...

Edited December 26, 2015 by Stone Blue

[MK3424]

Okay, we now have kOS and Jebmascript.... what's next? Mua (Mun Lua)?

[CoffeeKills]

3 hours ago, Stone Blue said:

Wow... I didnt even realize how old this thread was till I saw the difference in timestamps between CoffeeKills' post & JoerT's... lmao

Talk about necro...

Lol you here for sloppy seconds mate?

Edited December 26, 2015 by CoffeeKills
.

[Stone Blue]

Nahh... KerbScript... lol

[Nova1000]

Hi, is this api available for use?

Edited February 12, 2018 by Nova1000

[VR_Dev]

I don't know anything about compiling languages down into virtual opcodes, but I am working on a technique to control KSP plugins from the Unity editor, using memory mapped files. I was experiencing lag using kRPC, so I decided to try and build a faster solution.

I detail as much as I can in the thread, would love to chat with someone about getting mMap files to work in .net 3.5.

 

 

Edited February 13, 2018 by VR_Dev