nanobot

But ... lipstick

I hope they decide to split up the release into "1.0 public RC" and "1.0". I think that is the only possibility as they already announced the next version number and cannot undo this.

Of course they cannot undo an announcement of 1.0. The best they could do now is a 1.0RC for a large test player base (maybe even on steam?), and the official release later. But since KSP is available only in digital form I guess is does not matter which version is tagged 1.0, it is easy to update ...

HarvesteR already stated that it will be perfectly possible to fly "old crafts", i.e. asymmetric or not-so-aerodynamic planes. Also the goal is that flight physics feels much more intuitive. I don't see why trial and error shouldn't work anymore. It's not that you must build planes with a calculator now because drag doesn't depend on mass anymore. Also, maintaining two versions of aerodynamics will result in a mess in the code base and also makes life harder for modders. For blowing up the random stuff, well, a "disable atmospheric drag" button would allow this too without too much coding hassle, what do you think?

Me too. Hoping that 0.90 doesn't break saves though

Take a look at this thread from 2013: http://forum.kerbalspaceprogram.com/threads/39620-Barycenters-and-non-spherical-Volumes-of-Influence-%28an-idea-for-binary-planets-stars%29

Of course the barycenter itself is not reachable because you immediately enter the SOI of one of the "virtual moons". If you are far out, then the gravity of the barycenter will affect you instead. It's perfectly doable when using sensible SOI ranges.

I see what you meant, woodywood245. I agree with you that there should not a machine code generation invoked every time the input gets partially parsed, since this can change the semantics of a program in a serious way. What about this: - The interpreter expects user input line for line and tries to parse this line, starting with an empty parsing stack. - The input is tried to be parsed into a <statement> node. If the parser needs more tokens, print a symbol like > that prompts the user for another line (easiest way to do this is a blocking readNextToken() method) - If the input is a valid statement, execute it. This can be generalized for the whole language grammar. Most important for this is to specify what exactly is an executable piece of code. Assuming you have a simple formal grammar like this: <statement> -> <expr> := <expr> <statement> -> while (<expr>) <statement> <statement> -> { <statement-list> } <statement-list> -> ε | <statement><statement-list> Then a <statement>, defined like above, is the minimal executable piece of code. I will demonstrate a parsing process using an interactive shell. The parser should start with expecting a <statement> node. The <statement> node then requires reading a { or a "while" or an expression. Let the input of the user be: > while ( The parser sees the "while" keyword and then knows it has to use production 2. (I think that a recursive descent parser is a good option for this kind of user input interpretation). While resolving the right hand side of production 2, it consumes the tokens "while" and "(" and then requires an <expr>. However, since the sequence of remaining tokens is empty, all the parser will do is again printing a prompt: > Assume the user will now enter the expression and closing ")" : > (3 < 4) == !false ) Then the parser can parse the <expression> node and consume the ) token, requiring a <statement> (but knowing that this one is "one level deeper" than the original one). After this statement was also parsed, the production <statement> -> while (<expr>) <statement> is finished and the parser returns to the original "<statement>" call, then producing the required machine code. In this grammar, also a function definition could be modeled as some kind of statement, but one with no side effect or output except that it internally stores the new function. I think I will now first study the parser that you use, I worry everything I wrote is already obvious for you. EDIT Ok, I see that at least on github, the Compiler and CompiledScript files are empty. So if you want, I can give you some directions on how a multi-stage compiler (tokenizer -> syntax parser -> assembly code generator) could be designed.

What if the "shell" just compiled the entered lines on-the-fly and uses the same backend? It should be fast enough. To me, dropping the interactive mode (which I would really like to have) for this reason would be overkill.

Beautiful thread I also hope that it will be possible to integrate the functionality into probe cores, since some people including me are reluctant having crafts that are depending on mod parts. Also, liking the idea of an auto-pilot that is not considered as cheating because you can write the script yourself, which is obviously more fun I have heard several lectures about compiler design and software engineering, too bad that I have never learned C# or KSP modding...

Does interest me too

This is exactly what I was thinking yesterday I tried to post this today, but I think the forums ate it. So I will reply here instead.

Hi folks, recently I searched a harder tech tree to start a new save with, but did find only ones that are tied to game altering mods, or ones that require to copy a bunch of new .cfg files over my GameData/Squad folder. I also did not find a ModuleManager-ready list of required techs for the parts. So I decided to write a little recursive descent parser for KSP's .cfg files. [Post split up because of dumb nginx server error which deleted my previous posting attempt]