woodywood245

One of my goals for KerboScript++ (as I'm calling it) is to make it as KerboScript compatible as possible. You'll still be able to run your old code with little to no modification. However, there will be a variety of additions to the language that will make it more powerful for the power user, without sacrificing the ease of the language.

Keeping compatibility with the older language is partially a selfish goal. I spent several weeks writing a unified guidance system that I have no urge to rewrite in it's entirety. However, I plan on allowing programmers to implement whatever language they like on the system. The front end and back ends are going to be two different systems.

Trust me, I try to document EVERYTHING. Sometimes it's tough (I hate writing documentation), but if I don't document stuff, it comes back to bite me when I forget what I'm doing exactly. Part of the project includes writing a thorough language specification. You'll find what I have done so far in the codebase wiki. It's not anywhere near finished, but it will detail all language keywords, functions, types, and other language features. https://github.com/griderd/Jebnix/wiki/KerboScript-Plus-Plus-Language-Specification

I've been wanting to make a part like this for a while, though it will be part of another project that I'm also working on.

Thanks for responding to this. I was hoping to get a response several weeks ago, but didn't, so I implemented this without anyone's judgement, but it can be easily changed. I have a different set of implementation rules for each operation. A Value object has an underlying type value, which determines whether the Value is a string, floating-point (double), integer, boolean, ordered pair, etc, etc, etc. Each binary operator compares the operands internal types, and performs casts based upon a set of order rules. For example: The + operator does a string concatenation first, only if one of the values has an internal type as a string. Then it tries it for floating-point, then integers, then booleans, then complex types. public static Value operator +(Value a, Value { if (a.IsNull | b.IsNull) throw new NullReferenceException(); if ((a.Type == ValueTypes.String) | (b.Type == ValueTypes.String)) return new Value(a.StringValue + b.StringValue); else if ((a.Type == ValueTypes.Float) | (b.Type == ValueTypes.Float)) return new Value(a.FloatValue + b.FloatValue); else if ((a.Type == ValueTypes.Integer) | (b.Type == ValueTypes.Integer)) return new Value(a.IntegerValue + b.IntegerValue); else if ((a.Type == ValueTypes.Boolean) | (b.Type == ValueTypes.Boolean)) return new Value((a.IntegerValue + b.IntegerValue) != 0 ? true : false); else if ((a.Type == ValueTypes.OrderedPair) | (b.Type == ValueTypes.OrderedPair)) return new Value(new OrderedPair(a.OrderedPairValue.X + b.OrderedPairValue.X, a.OrderedPairValue.Y + b.OrderedPairValue.Y)); else return new Value(); } Also, some operations cannot be performed on certain types as it is currently written. For example: set val to "50". set answer to val + 1. print answer. set answer to val - 1. print answer. Would result in. 501 InvalidOperationException: Cannot perform subtraction with a string value. 501 The second occurrence of "501" will be because I don't plan on having a program halt because of an error unless it is explicitly told to do so in the code. The code will run into an exception at "set answer to val - 1.", ignore the line, and execute the next. I really like your idea of explicit casting. Implementing that will solve the problem. set val to "50". set answer to val:ToNumber + 1. print answer. set answer to val:ToNumber - 1. print answer. Would result in. 51 49 I could implement it as such: ToInt - casts the value to an integer ToFloat - casts the value to a double ToNumber - if the value has a fractional value, converts it to a double. otherwise, converts it to an int. ToString - casts the value to a string

I'm going to release as I get things done. My first goal is to have a version that works with the existing KerboScript language, and includes a few core language improvements (such as if-else) that are easier to implement from the beginning. From there, I will add features starting with language features and moving towards functional features, releasing every few weeks.

There are several reasons why I chose to continue using KerboScript. 1. The language may have a variety of syntax issues, but it is incredibly easy to learn. 2. I spent several weeks working on and perfecting a unified guidance system for my rockets, and all of it is written in KerboScript. Personally, I don't want to have to convert the whole thing to a different language. 3. In order to implement a language, one must be intimately familiar with it, either by designing it from scratch, or knowing A LOT about it. I may not have designed KerboScript, but I do know it pretty well, and there are a few people around here that can help fill in the gaps in my knowledge. I do not know Lua, and I really don't like JavaScript, but I do know that KerboScript has a lot of potential if given a little TLC. 4. I have done this type of thing before (including implementing a new language), and I know how to do it right. I've been studying language design and implementation for several years.

Actually, I was really hoping I could figure out a way to make Jebnix work with RPM. I'm working on a conceptual testbed for Jebnix's navigation system that uses RPM as it's GUI, and I'd love to be able to use RPM as an optional console for Jebnix. The only thing I would need is the ability to get keyboard input from RPM. I'm utterly unfamiliar with designing GUIs for KSP so I'll probably need a lot of guidance in this area. However, the RPM system is brilliantly easy to use from the programmer's end.

I will look into this. I don't use Real Solar System, nor do I know how it works. So keep watch on the development so when testing does begin, you will be able to help me get it working with Real Solar System. I don't know when the alpha will be ready. I am hesitant to make an estimation because I'm ALWAYS late when I do that. I consider this project still in the early stages. There are large chunks of the KSP API that I still need to learn, and get some additional talent aboard.

First of all, I'd like to thank everyone for their continued support. Sorry I disappeared for a couple weeks, but I had a handful of emergencies all pop up at the same time. The college semester has started, so most of my time is being dedicated towards my school work. However, work is continuing even if it doesn't look like it. A few weeks ago, I started working on a closely related project that will enable me to explore the idea of having an IMU that keeps track of the current pitch-roll-yaw angles, allowing the user to program their directions that way if they so choose. I had to stop working on that temporarily to finish another project (I'm a very busy person, obviously), however, work will proceed again this week, and I think I've got everything narrowed down. Two things: 1. No matter how long I might be quiet, this project will not die. Even when I'm quiet, I'm still working. 2. Please please please PLEASE read the first post on this thread before asking for a feature. The first post has a list of features that are probably going to be added. I kind of feel like a jerk whenever I have to point out that the requested feature is already on the list. Also, check if the date/time on the "Last Edited" part of the first post. If it's been changed since you've last read it, you're going to miss something. Now I will respond to each of you individually.

You sir, are a god! [LOG 21:31:08.504] TextureCompressor: Memory Saved : 1002MB KSP used to crash on me somewhere between 3.5GB and 4GB usage. Now I'm running all of my normal mods, plus the clouds and city lights mod that I wanted to run so badly, with 2,104,560 KB (2.007 GB).

I'm not entirely sure what I'm doing wrong, but every instance of AGSTATEX returns "AGSTATEX". For example: {0} $&$ AGSTATE1 Results in AGSTATE1 This applies for AGSTATE0 through AGSTATE9. Is this a feature that hasn't been released yet? Thanks

This is an interesting idea. I will look into it.

There are some technical details I need to work out, but I'm hoping to have translation capabilities built in to Jebnix.

I will add this request to the list.

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.

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.

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.

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.

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.

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.

I've officially begun development of my kOS alternative. Go here for information: http://forum.kerbalspaceprogram.com/threads/65005-Jebnix-A-kOS-Alternative

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: Throw an exception in the event an invalid operation is performed. Or... 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.)

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

Because of the amount of work that needs to be done to expand the capabilities of kOS, I am branching kOS Extensions into a separate mod. This will allow me to not clutter up Sensor Reporter with unrelated code. More details to come. Edit: Until an official KSP 0.23-compatible release of kOS is made, there will be no updates to Sensor Reporter, and kOS Extensions will not be released either.