[WIP] Jebnix - A kOS Alternative

[woodywood245]

Jebnix - A kOS Alternative

A few months year and a half ago, I considered writing a kOS alternative that could do what kOS does and more. As the kOS situation deteriorated, I've decided it's about time I get to work. This thread is to serve as a place for discussion during the active development of this project. I want the kOS community and KSP community at large to be participants in the development of this mod. Without your support and encouragement, projects like this aren't possible. Also, I'm sure there are more than a few people that know the Kerboscript language even better than I do and can help me get the implementation details right.

Github Repository: https://github.com/griderd/Jebnix

Official (incomplete, more of a to-do list) Feature List: https://github.com/griderd/Jebnix/wiki/Official-Features

Goal: Jebnix will do everything kOS can do, using an enhanced version of the kOS language, while fixing many of the bugs and problems in kOS

I'm still working on the feature list, but this is what I hope to accomplish:

• Compatibility with KerboScript 0.9x
  
• An enhanced language capability. Think of it as KerboScript++.
  
• Simplified codebase. I'm starting from scratch,
  
• Formal language specification, and implementation details.
  
• Better error handling, which provides the script name and location of the error, and what the problem actually is ("Missing '.'", "Bracket mismatch", etc).
  
  
• Runtime exception handling. A TRY... CATCH block would be handy.
  
• ELSE and IF ELSE blocks.
  
• Enhanced WHEN... THEN capability. Unambiguously allows an entire block of code to be executed on a WHEN... THEN instance.
  
• Persistant WHEN... THEN. Sometimes you want to fire a WHEN... THEN event more than once, which means you usually have to put it in a loop. To avoid this, WHENEVER... THEN will do the same as WHEN... THEN but will not go away once it's been fired.
  
• Variable scope. Variables created with the LOCAL keyword would exist in their local scope. If defined inside of a block, they would be removed once the block ends. If defined in the global area of a script, they exist as long as the script is running. Variables created without the LOCAL keyword exist as global variables like normal.
  
• Arrays
  
• Return values. Scripts would be able to return values that could be assigned directly from scripts. You would no longer have to assign to a global variable before exiting. Instead, the "RETURN" keyword would be used. As a result, the RUN keyword would not be necessary to run a script.
  
  
  set x to subscript().
  
  // subscript.txt
  return apoapsis.
  

  
  In this script, x would be assigned the apoapsis. The RUN keyword becomes unnecessary with the parentheses there. The engine would see the parentheses, and based on context determine that this is a function call. It would then search the internal and external function lists for a function named "subscript". When it doesn't find it, it looks through the file list for a script called "subscript" and executes that instead. The RETURN keyword pushes the apoapsis onto the stack, and it is popped off again and assigned to x later on.
  

• New operators. Operators for not-equal, bitwise AND and OR, bitwise and logical NOT.
  
• Enumerators. Enumerators could be created in scripts, and would also be utilized in the runtime. STATUS would no longer return string values, but would return an identifier. These identifiers could still be compared to string representations for backwards compatibility.
  
• Boolean values. Boolean variables would be able to be assigned from TRUE and FALSE keywords and would not be string value anymore.
  
• Leaving scripts early. The RETURN keyword would also allow you to leave scripts early by simply using the RETURN keyword with no value.
  
• String escape sequences. Escape sequences in strings would be readily available. Imagine being able to put quotes in strings, and new line characters too!
  
• String operations. Functions like TOLOWER(), TOUPPER(), LENGTH(), and SUBSTRING() would be helpful.
  
• User prompts. Being able to prompt the user for input is important in any program. Even the Apollo astronauts had an "Are you sure?" prompt in their software.
  
• Extended math and physics functions.
  
• Expandable memory Instead of adding another computer because you ran out of space, just add a small "Memory module" part that would expand the existing volume.
  
• Distance delay. User input would be delayed by the appropriate time unless the craft had Kerbals. All COPY TO/FROM ARCHIVE calls would also have the delay. This could be turned off in a settings file. Perhaps direct compatibility with RemoteTech.
  
• Multitasking. Multiple scripts running, each on its own process, each with its own memory space (no sharing variables).
  
• Interprocess and intercomputer communication. Threads and computers could send and receive messages to each other without using a convoluted hack involving the LOG keyword.
  
• A MEMDUMP keyword that would dump the state of a process in a human-readable format to the ARCHIVE.
  
• Script names storable in variables as function pointers.
  
• Subroutines blocks with a SUB or FUNCTION keyword.
  
• Easier pitch/yaw/roll system
  

Library functions will include:

Basic math functions:

abs - Absolute value

mod - Modulus (though this can be achieved with the % operator)

floor - Rounds a number up to an integer.

ceiling - Rounds a number down to an integer.

round - Rounds a number.

round - Rounds a number to a given decimal place.

sqrt - Square root

Trig functions:

radtodeg - Converts radians to degrees

degtorad - Converts degrees to radians

sin - Sine function for degrees

cos - Cosine function for degrees

tan - Tangent function for degrees

sinr - Sine function for radians

cosr - Cosine function for radians

tanr - Tangent function for radians

asin - Arcsine function for degress

acos - Arccosine function for degrees

atan - Arctangent function for degrees

atan2 - Two-argument arctangent function for degrees

asinr - Arcsine function for radians

acosr - Arccosine function for radians

atanr - Arctangent function for radians

atan2r - Two-argument arctangent function for radians

Logarithmic Functions:

log - Logarithm base 10

logx - Logarithm base x.

ln - Logarithm base e.

Also provided are constant values:

pi - The value pi.

e - The value e.

GravitationalConstant - the gravitational constant (6.67384×10^-11 m^3 kg^-1 s^-2)

Jebnix will also include a modularized system. The Jebnix computer will exist in one DLL, while the KerboScript++ engine will exist in another DLL. This will allow me to modify one without disrupting the other, and for myself and others to interchange scripting engines, or add additional scripting engines to the existing system. More detail to come.

But kOS has gotten better! Why another one?

kOS has improved significantly over the last year, and continues to do so. However, there are still a variety of features that are missing and may never be added (user-defined functions, for instance). Some things, like functions, are left out of the current version of kOS because of architectural limitations: it would require an entire rewrite to implement those features. Jebnix is being written with a very different architecture, starting from the ground up.

Where I am Now

I am currently working on the scripting engine portion of the system. This includes the language parser and interpreter.

Testing: UNTIL/WHILE loops

Currently coding: Redesigning entire system to be compiled.

Detailed design: Compiled LOCK system

Preliminary design: FOR loops and FOREACH loops

Conceptualizing: Basic encapsulation

Edited February 7, 2015 by woodywood245
Updated info

[woodywood245]

At the moment, I'm working on my variant-type structure, which will handle operations between different types.

kOS is by definition a loosely-typed programming language, though I'm not entirely sure if it's implemented that way in kOS.

Most operators, such as subtraction, multiplication, and division, cannot be performed on string values. Bitwise operations cannot be performed on strings or floating-points. I prefer to control the implementation of operations myself because I know what the result will be, and so will the user.

I have two choices:

1. Throw an exception in the event an invalid operation is performed. Or...
   
2. Cast the variant to a valid type and then perform the operation. (Strings that cannot be parsed are interpreted as 0 or False depending on the type.)
   

[diomedea]

Let me wish every success with your endeavour. This is going to implement some of the improvements I needed and suggested for kOS.

Other features (I don't see yet in the OP) I would like Jebnix to support:

- multidimensional dynamic arrays of typed variables (typed variables being any kind Jebnix will support, so e.g. including vectors);

- allow input interaction with user (at least, a basic keyboard "INPUT" statement);

- ability to run compiled code (at least, include a pre-processor to parse kerboscript in advance, if possible optimize for execution speed, and store the parsed code while waiting for it to be run).

[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.

[woodywood245]

Let me wish every success with your endeavour. This is going to implement some of the improvements I needed and suggested for kOS.

Other features (I don't see yet in the OP) I would like Jebnix to support:

- multidimensional dynamic arrays of typed variables (typed variables being any kind Jebnix will support, so e.g. including vectors);

- allow input interaction with user (at least, a basic keyboard "INPUT" statement);

- ability to run compiled code (at least, include a pre-processor to parse kerboscript in advance, if possible optimize for execution speed, and store the parsed code while waiting for it to be run).

Arrays are definately going to be part of Jebnix. I forgot to add it to the list. Oops.

Also, user interaction is included with "user prompts" that already appears in the list. I was thinking of going with a PROMPT(), but INPUT works even better.

The compiled code thing is something I've thought about for a while, and I'm currently working on a separate, more complex scripting engine that would do that natively. A future update may incorporate the other scripting engine.

[diomedea]

Given the above, I wish I could be of help. Coding Jebnix parts would actually be far beyond my ability (at least for now), but I believe I may at least help with testing, and possibly some debugging in future.

Am I correct in guessing Jebnix is being developed in C#, just like kOS? If so, I will put some time in reading kOS sourcecode to have a start.

[woodywood245]

The only thing I'll probably need help with is writing the KSP UI, but I'm saving that for last. Testing is going to be done with the Windows console and a mockup console in a window.

The plugin is being written in C#, but I don't know how much reading kOS will help, since I am starting from scratch. The last few times I tried reading the kOS source code I couldn't make head or tails of most of it, and I've been programming for more than half my life, and been using C# as my primary language for close to five years. So good luck there.

I will be looking for testers and debuggers in the coming weeks, and will keep you in mind. I'm going to try to get as much done in the next couple weeks as I can, before the new college semester starts and I go back to class. Things will move more slowly then.

[John FX]

I hope this goes well for you. kOS is awesome and if you implement the features planned here then your mod will be more awesome.

return values...

arrays...

[nothke]

I am in full support of this mod.

What kind of parts are you planning to have? CPU and additive hard drives separately? In-line and radial? If you need my modeling services I'm available for a few parts.

[woodywood245]

I am in full support of this mod.

What kind of parts are you planning to have? CPU and additive hard drives separately? In-line and radial? If you need my modeling services I'm available for a few parts.

Thank you very much for your support! I am a big fan of your work!

I'd like to have CPU parts in 1.25, 2.5, 3.75, and 5 meter sizes, as well as a radial/probe part. I'd like hard drive parts to be radial and be able to fit on the CPU parts nicely so everything looks like it goes together.

I'd also like the CPU part to be somewhat reminiscent of the Saturn V Instrument Unit (http://en.wikipedia.org/wiki/Saturn_V_Instrument_Unit). I can make the parts, and while and I like modeling (but not texturing), I just don't particularly like making parts for KSP. Which is why I have a whole list of parts I'd like to make but at the same time, I don't really want to make them and write the code instead.

Edited January 7, 2014 by woodywood245

[diomedea]

I'd like to have CPU parts in 1.25, 2.5, 3.75, and 5 meter sizes, as well as a radial/probe part. I'd like hard drive parts to be radial and be able to fit on the CPU parts nicely so everything looks like it goes together.

I'd also like the CPU part to be somewhat reminiscent of the Saturn V Instrument Unit (http://en.wikipedia.org/wiki/Saturn_V_Instrument_Unit).

That would be really nice, and I have no doubt about nothke's ability to make those parts a reality. However, the Saturn V IU to me seems like a ring able to hold, support and power the instruments, rather than a cilinder "block" with a fixed set of instruments inside. That IU should actually allow, in KSP, to hold other instruments just as easily (to name, any part with existing mods that provide data and guidance, like MechJeb, Kerbal Engineer Redux, Protractor...as well as some of the measurement tools from standard KSP). Therefore, I believe this "unit" should be modelled as:

- a set of rings, in varying diameters, to hold and support instruments of different kinds (Jebnix or not related);

- a set of instruments, to be internally attached to a IU ring, to provide CPU power and harddisk storage, specific to Jebnix.

[check]

I'm all for this. I was very into kOS until it was abandoned (or but on hold, or whatever)... It has so much potential.

A couple of suggestions:

Goto statements.

The ability to plot points or lines or circles to make simple graphics.

Ability to read attitude from the nav ball and not KSPs raw, native, crazy, unhelpful coordinate system.

[woodywood245]

I'm all for this. I was very into kOS until it was abandoned (or but on hold, or whatever)... It has so much potential.

A couple of suggestions:

Goto statements.

The ability to plot points or lines or circles to make simple graphics.

Ability to read attitude from the nav ball and not KSPs raw, native, crazy, unhelpful coordinate system.

GOTO probably will never happen. Personally, I'm against them, and I'd like to move towards a more structured, procedural language with functions/methods/subroutines that can in themselves have their own functions. I thought about GOTO statements for a moment, but decided against it.

Eventually I do want to have a second, graphical UI for plotting and graphing, but that will have to come in the future. However, the plans do exist.

[woodywood245]

That would be really nice, and I have no doubt about nothke's ability to make those parts a reality. However, the Saturn V IU to me seems like a ring able to hold, support and power the instruments, rather than a cilinder "block" with a fixed set of instruments inside. That IU should actually allow, in KSP, to hold other instruments just as easily (to name, any part with existing mods that provide data and guidance, like MechJeb, Kerbal Engineer Redux, Protractor...as well as some of the measurement tools from standard KSP). Therefore, I believe this "unit" should be modelled as:

- a set of rings, in varying diameters, to hold and support instruments of different kinds (Jebnix or not related);

- a set of instruments, to be internally attached to a IU ring, to provide CPU power and harddisk storage, specific to Jebnix.

The set of rings in varying diameters to support instruments of different kinds already exists in the form of kothke's 6s tube system. There are only two sizes of that at the moment, and you have to open the doors to really get at what's inside. The idea with the IU for the model was more of a fun aesthetic throwback and less of a realism thing. Personally, I find a cylinder as thick as the kOS one a little cumbersome to look at when you consider that the AGC fit into a 2 cubic foot area.

Edited January 8, 2014 by woodywood245

[John FX]

That would be really nice, and I have no doubt about nothke's ability to make those parts a reality. However, the Saturn V IU to me seems like a ring able to hold, support and power the instruments, rather than a cilinder "block" with a fixed set of instruments inside. That IU should actually allow, in KSP, to hold other instruments just as easily (to name, any part with existing mods that provide data and guidance, like MechJeb, Kerbal Engineer Redux, Protractor...as well as some of the measurement tools from standard KSP). Therefore, I believe this "unit" should be modelled as:

- a set of rings, in varying diameters, to hold and support instruments of different kinds (Jebnix or not related);

- a set of instruments, to be internally attached to a IU ring, to provide CPU power and harddisk storage, specific to Jebnix.

I`ve been trying to get a proper interstage made as part of procedural fairings. If the jebnix could be a part to be added radially that would be great. The current kOS unit is sort of a ring but for very small craft.

I second having a `normal` coordinate system. Also some ability to directly control pitch up or down, roll left or right, and yaw left and right. [set ship:pitch to pitch-5. lock ship:yaw to nextnode. set ship:roll to 0.] would be cool.

[woodywood245]

I`ve been trying to get a proper interstage made as part of procedural fairings. If the jebnix could be a part to be added radially that would be great. The current kOS unit is sort of a ring but for very small craft.

I second having a `normal` coordinate system. Also some ability to directly control pitch up or down, roll left or right, and yaw left and right. [set ship:pitch to pitch-5. lock ship:yaw to nextnode. set ship:roll to 0.] would be cool.

I will look into a "normal" coordinate system, though "normal" is in the eye of the programmer. I will still have to maintain the standard coordinate system for backwards compatibility purposes, of course.

[deadshot462]

Good luck, this looks great. I was hoping someone would continue with the KOS-style update.

Could you add an option for a directional alt-radar? Instead of reading straight down, maybe read distance to ground from the ship's bottom depending on its orientation relative to the ground?

[nothke]

Good luck, this looks great. I was hoping someone would continue with the KOS-style update.

Could you add an option for a directional alt-radar? Instead of reading straight down, maybe read distance to ground from the ship's bottom depending on its orientation relative to the ground?

That just sounds like a normal laser rangefinder. I could make a rangefinder part that would output the distance to nearest object, something similar to lazor's lidar, but the data could be used in a Jebnix program. Hell, now I see something like a wiremod only for KSP xD Parts interconnected by the computer, screens, sensors.. =P

I'd also like the CPU part to be somewhat reminiscent of the Saturn V Instrument Unit (http://en.wikipedia.org/wiki/Saturn_V_Instrument_Unit). I can make the parts, and while and I like modeling (but not texturing), I just don't particularly like making parts for KSP. Which is why I have a whole list of parts I'd like to make but at the same time, I don't really want to make them and write the code instead.

That would be appropriate, yes, but the reaction wheel rings (the advanced 2m SAS part especially) are already reminiscent of the Apollo IU. About the modular system diomeda was talking about, interestingly, the early Apollo mockups had a sort of like a plug-in system where individual instruments would be inserted in a frame:

The apollo guidance computer on the other hand looked like this:

(the computer casing on the left, and the cockpit interface on the right)

The casing looks like something that could be radially attached to the ship in KSP =P

The Shuttle computer was designed to fit in one of the racks:

(older version on the right used 2 slots)

This format is quite similar to my MIX drawers

While on the ISS, astronauts simply use laptops (Thinkpad 750s with special cooling cause heated air doesn't move in microgravity) for controlling and displaying data of onboard systems and apparently there is a central computer too.

Edited January 8, 2014 by nothke

[HoneyFox]

I would hope to see some script system available on per-part basis... unlike kOS which seems to be for whole vessel.

so that we can write simpler and modular scripts, not a lot of things all combined in one script.

examples can be:

1. Write a simple script for solar panels so they automatically retract when getting into atmosphere.

2. Write a simple script for ladders to extend when the vessel is landed and retract automatically when it's not.

3. Write a simple script for lights so they switch on/off according to the lighting condition (whether sunlight exists or not).

... and maybe more.

[MaHuJa]

The last few times I tried reading the kOS source code I couldn't make head or tails of most of it, and I've been programming for more than half my life, and been using C# as my primary language for close to five years.

To me that is somewhat funny because looking at the kOS code (and creating the first .23 hotfix) was my first time touching C#, and I got a decent handle on how the code works.

I'm working on creating my own thing though, as a fork of kOS, but ditching kerboscript - at least as a main language, I'm undecided if I'll keep it as a fallback language for compatibility. Doing so would allow me to incorporate non-language improvements to kOS itself pretty easily.

[diomedea]

The set of rings in varying diameters to support instruments of different kinds already exists in the form of kothke's 6s tube system. There are only two sizes of that at the moment, and you have to open the doors to really get at what's inside. The idea with the IU for the model was more of a fun aesthetic throwback and less of a realism thing. Personally, I find a cylinder as thick as the kOS one a little cumbersome to look at when you consider that the AGC fit into a 2 cubic foot area.

Of course you're right, and I thought about it. Nothke's 6s tubes do work for this purpose. Clearly, we would want to see them in all diameter sizes, or to have them fitting diameter and height procedurally. But also, should those tubes be textured differently then a "all-purpose storage compartment", when used in this fashion? Yes or no, your's and nothke's take. What I really was about, is the modular system instead of those cylinder parts that kOS uses.

[diomedea]

I would hope to see some script system available on per-part basis... unlike kOS which seems to be for whole vessel.

so that we can write simpler and modular scripts, not a lot of things all combined in one script.

examples can be:

1. Write a simple script for solar panels so they automatically retract when getting into atmosphere.

2. Write a simple script for ladders to extend when the vessel is landed and retract automatically when it's not.

3. Write a simple script for lights so they switch on/off according to the lighting condition (whether sunlight exists or not).

... and maybe more.

That concept is interesting. I see that not much in the way of a "distributed intelligence" to each single part, but about specific actions for each part triggered by different events, all those "scripts" active concurrently within Jebnix CPU.

But to implement that, I hope those actions can be executed independently of the standard 10 action groups + standard switches, or we run out of possible actions pretty fast.

[John FX]

I will look into a "normal" coordinate system, though "normal" is in the eye of the programmer. I will still have to maintain the standard coordinate system for backwards compatibility purposes, of course.

When I say `normal` I mean, if you look at your navball, you could just type the numbers into KOS verbatim and it would point that way. Of course you would need to keep the current system for legacy, the main point in my post was direct relative control. Being able to say pitch the nose up 5 degrees or yaw right 10 degrees from your current position, which is currently impossible in KOS AFAIK. You currently either use SAS or set a heading and the program autosteers.

EDIT : One more thing that has always bugged me about KOS it the way it checks orientation without active engines. Currently it seems that it is only when there is an active engine can KOS can tell which way is up. If you just have a pod with seperatrons or a chute and landing legs then KOS will just spin wildly if you say `lock steering to retrograde` or similar until an engine is ignited. If you have no engines then that is it. No steering for you. Another reason I would like direct control over steering.

What I do like is the way it looks at engines for direction as that gives you your thrust vector and that is the way I want a GC to check for which way is up (especially with tweakables now) but when there are no engines I`d like it to have a backup which will take facing from either the active pod or docking port.

Edited January 8, 2014 by John FX

[diomedea]

Being able to say pitch the nose up 5 degrees or yaw right 10 degrees from your current position, which is currently impossible in KOS AFAIK. You currently either use SAS or set a heading and the program autosteers.

This would really be a major improvement over kOS. It would make programming much easier to be able to enter angles directly (Pitch, Roll, Yaw), instead of rotational vectors from a reference direction, as in UP + R(0,0,180) + R(0,pitch,0). It took me days to figure how kOS (and KSP) handles the internal frame of reference and it remains an unneeded complication to me. Just as KSP keeps that reference for internal purposes only, but shows angles that are consistent with the relative orientation of the craft (IRT the main body), the same approach would be best if used by Jebnix.

[Zander]

Please make sure it can maneuver the ship using the gimbals and not the torque. Kos can only manipulate the torque so those of us using realism mods with no torque in parts need the OS to be able to access the engine gimbals and move them to the same degree the keyboard can.