woodywood245

Given the code: set endp to 5. set incr to 1. FOR A from 1 to endp STEP incr { print "A is now " + A. set endp to 40. set incr to A. }. Your output would be: A is now 1. A is now 2. A is now 4. A is now 8. A is now 16. A is now 32. A, endp, and incr are stored as variables just like any other variable. Each time through the loop, they are evaluated for that one time. The values that are provided at the beginning of the loop only matter for the first time through. They are not remembered, and the expressions are evaluated every time through. Therefore, if you start looping through an array of 10 elements, and add 10 more elements onto the end, but tell it not to stop until the end of the array is reached, then you will stop after 20 elements.

If labeling the expressions A, B, C, and D respectively, then... for A from B to C step D { // your code here } ... is functionally identical to... set A to B. while A <= C { // your code here set A to A + D. } "SET x TO y." requires that the expression x evaluate to a variable, whether it exists or not. The reason I say "expression" is because "a[b+c]" is a valid expression, representing a location in an array. Expression y must simply evaluate fully. Therefore, A must evaluate to a variable, while B, C, and D must simply fully evaluate to a value of some kind. Setting A to B is run only once, before the loop begins. Then, expression A <= B is evaluated. If it evaluates as TRUE, the loop executes. At the end of the loop, A is incremented/decremented according to D, if it exists. Otherwise, D is set to 1, the sign is inferred from B and C (via D = A - B >= 0 ? 1 : -1) and the increment/decrements happens accordingly. Then the loop starts back at the beginning, evaluating A >= C. I hope that makes sense and answers your question.

Given the opinions given, and the simplicity in syntax, I think I'm going to go with a Visual Basic-like for-loop. It will be much easier to parse that way. This is far easier to parse with my setup than anything else: for [expression] from [expression] to [expression] [opt:step [expression]] { }

I'm calling my version of the language KerboScript++.

That's a really good idea. I might do that, thanks! It will depend on how easy it is to code in relation to the VB-based idea, and whether it fits well within the existing syntax of the language. But I will look into it.

On a second thought, I won't bother adding DO...WHILE. Not yet, anyway.

I suppose that's true. I may put it in anyway and let people decide whether or not they want to use it. The implementation of a DO... WHILE loop is almost identical to that of a WHILE loop, so it's something I could whip up and test in only a few minutes. I've had a thought about FOR loops. It could be done similar to how it is done in Visual Basic: for x from 0 to 5 step 1 { } for [control variable] from [start] to [end] [opt:step [count]] { } Using the STEP keyword is optional. Without it, the value is stepped by 1 or -1, depending upon whether the end value is larger than the start.

WHILE loops are already built into Jebnix. WHILE loops and DO... WHILE loops are similar, but different. In a WHILE loop, the condition is checked before it is executed for the first time, whereas in a DO... WHILE loop, the block is executed at least once, with the condition checked at the end to see if it should be executed again. set x to 0. // this will run repeatedly until x is 5 while x < 5 { set x to x + 5. } // this loop is functionally identical to the one above set x to 0. do { set x to x + 1. } while x < 5. set x to 5. // this loop executes only once, and x becomes 6. do { set x to x + 1. } while x < 5.

So have I. I'm also thinking about including do...while loops and for-loops, but I'm not exactly sure on the appropriate syntax to make it easy. For-loops are confusing already for newbies in other languages. I'm thinking something like this for do... while. DO { // do something } WHILE condition. I want to add for-loops if possible because they are closely related to while-loops (virtually identical, actually) so they are easy to implement, and I'm going to have arrays (which will support a foreach iterator loop), but sometimes you don't want to iterate over the entire array.

I'm not sure I understand your question. Are you taking about in the console, where it says "this is test 1.", "this is test 2.", etc?

Storing script names as strings, creating them dynamically, and calling scripts through the stored variable. Also demonstrates WHILE loops.

The plugin system is being designed today. It will feature two systems: a legacy system that lets you use the old (and weird) method, and a newer system that lets you register your functions directly through the Jebnix library. The newer system will allow programmers to simply call the ExternalFunctions.RegisterFunction(string name, int paramCount, Delegate ptr) or ExternalFunction.RegisterFunction(string namespc, string name, int paramCount, Delegate ptr) method, and pass it a delegate (function pointer, for the C/C++ programmers). A unique internal name is generated for the function, and the function is registered with its delegate in a Dictionary (hash table). When its time for the function to be invoked, the ExternalFunctions.InvokeFunction() method is called, and the registered function is invoked, if it exists.

This is going to release, I'm just not exactly sure when. Because I started completely from scratch, it is definitely an uphill battle, and I'm not able to put in as many hours as I'd like to. However, I never abandon projects (sometimes I just let them get dusty), so you can be assured that this project will be released within a reasonable time. I'm planning on distributing a pre-release alpha sometime in the coming weeks that uses RPM as an interface (with no keyboard support). This would simply be designed to test/run scripts and use the underlying systems. And I'm sure there will be plenty of stuff for the breaking. I'm writing the thing, and I'm finding new bugs every day. You can track day-to-day progress on Github (see first post). Thanks for your support!

A test of library functions: 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. roundto - 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)

And next, a preview of expression evaluation. There are still a few bugs that need to be worked out and some other work, but it's mostly working. This demonstrates the importance of parentheses for equal-precedence operations.

The part in parentheses is the name of the file/process running (or, in this case, the interactive console process), and the line number the error occurs on, similar to how it would appear as a compiler error.

A preview of the improved error messages:

It's a little too late to incorporate that kind of thing into what I already have. I've already reached the point where the DLLs compile and actually work. I haven't started looking at performance yet. I expect initial performance of Jebnix to either be abysmal or excellent, but I won't release it until I get it where I want it (the faster the better). I'm hoping the simplified codebase, which uses a lot of the optimization techniques I know, will help increase the speed. Most of the speed is based on the core clockspeed, which can be determined by implementation and potentially be configured. I have been working on a separate project for quite some time now that is a virtual machine/scripting engine for .Net, which compiles everything to bytecode and runs it directly on a virtual machine. If that project is ever completed, I'm planning on releasing a version of Jebnix incorporating that scripting engine. The project is large and ambitious (and I can describe it in far more detail, PM me if you'd like more info), but is a backburner project so I'm not sure when it will be finished.

As far as language design is concerned, I'm starting where Kevin left off. I'm planning on adding core language improvements first (if-else/if-elseif statements, useful error messages, exception handling, return values, function blocks, enumerators, != operator, unary + and - operators, NOT operator, bitwise AND and OR operators, arrays, boolean type, ordered pair type, string operations, variable scopes, etc) before adding new surface-level features (dynamic arrays, VOLUME:NAME, etc). Features that Erendrake is adding may be included in my version, but it's not guaranteed.

As I'm working on Jebnix, I'm working on writing a detailed language specification for Kerboscript++, that defines the expected behavior of each of the language elements, and how they should work on concert. This is for my own sanity as well as everyone else's. If something isn't working as I designed it, it will become obvious when reading the language definition. In the case of Kerboscript++, certain behaviors that exist in the original language (such as normal variables existing in global scope) will still be there, with fixes for other behaviors. There will also be no hidden keywords that can only be found by looking in the source code. Everything will be defined as obviously as possible. I'm going to try my best to make decent documentation as well as a decent implementation, because it drives me nuts when good software comes with bad documentation.

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.

As dead as a Kerbal with no parachute. This project has been dead for a while. Many of the features that was planned for this project were built into KOS during one of the releases. Here's the Jebnix thread: http://forum.kerbalspaceprogram.com/threads/65005-Jebnix-A-kOS-Alternative

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.

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.

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.