KevinLaity

The first bug you mentioned should now be fixed in 0.5. I'll look into the second.

Actually my mod is just grabbing the vessel.longitude value. I assumed it would be fine and hadn't thought to test it thoroughly. I'll take a closer look when I have a chance.

Yes, I do plan on it especially since you can already concatenate with +, it just makes sense

You would think this would be easy to find in the KSP assembly. What I did find was surprisingly difficult to understand. If somebody does know how to get the simple number of stages I'll add it in.

Exactly what I was going for, in fact that is the original C64 font.

Getting :X :Y and :Z from a vector will happen. Add it to the giant list of things that need to be done.

It uses polling, fires once, and does not expire when leaving curly brace scope. I'll take a look at that code

We're definitely on the right track with this. But I want to have a part-registration model where parts register themselves with kOS. I think there's a few benefits to that: - LIST PARTS can be made list only the kOS compatible parts - I can then easily address individual parts - The mod developer can decide exactly what messages to get - We can potentially offer bindings that work with SET, PRINT etc - We can potentially give mod developers the ability to come up with their own commands.

Those things SHOULD be locked out whenever the window is focussed, but there have been reports of conflicts with other mods that nullify that.

This is something that needs to be fixed soon. I think when I started building it the convention was as I have it now. When it switched, I didn't get the memo! Also apparently, support for the folder structure I currently have may go away. Edit: To clarify, I started building this in KSP 0.18 which was quite some time ago

There is a WIKI in the making that might help, but no there is currently no "for Dummies" resource. Maybe there should be! I am VERY interested to see how far a non-programmer is able to get with this. For now I would say, go ahead and try building bigger craft using the same program. See what happens. If something goes wrong, see if you can figure out by looking at the program what went wrong, and why. And then see if you can come up with a way to fix it.

Currently it'll automatically trap any kOSException and show it in the terminal. This is where your in-game error messages come from. Anything else falls through. This seems to work well enough for my purposes because if there ever is an exception that's the result of a bug in my code, the terminal will stop working and I'll know to check the output file. I'm better off with the output file because the terminal has limited space. I guess I could show a "Flagrant error, computer over!" error message and then rethrow the Exception to still get the output.

That's definitely an exception when that happens. And it also happens if you try to type into a terminal that was opened from a ship that is now destroyed. I don't really use alt-f2 much, but they do get dumped in an output file in your KSP folder. (I can't remember exactly where it is right now) This is definitely worth exploring further. What happens if you try to lock the steering of a craft that's still on the pad?

Yes the stock ones. And if a mod has an antenna that people want to use I would have to add that in manually. There doesn't appear to be an antenna partmodule that I can detect, so I have to go by the part names "commDish" and "longAntenna".

Well, some of this will come true. I already have a plan to take the scientific instruments and expose their outputs and make sure that you can't get those values without those instruments on board. On that note, you will soon need at least one antenna if you want to access your Archive drive from space and more if you're more than 150 km from the surface of Kerbin. It'll use the same rules as targetting, you get 75km for free, each additional antenna gives you another 75km, and then that number is multiplied by 10 for every comm dish. It's so true about KSP. All of the fun of a sandbox game comes from finding your own solution to problems that are hard to solve.

If you look at the bottom left, do you see the controls moving as though it's trying to turn? Do you lose your flashing cursor at any point? That would indicate that an uncaught exception

SAS is probably the most common thing because under the new system, you expect the craft to rotate at will when it's on. I may implement a fix that automatically shuts off SAS whenever the steering is locked. EDIT: And the script ending only applies of course if you're in a program, the original post seemed to indicate that he had also tried doing it as an immediate mode command.

Maybe not, but the post I was responding to WAS about English and whether the English meaning of a semicolon fits into a programming language. They comply to C-like structures when I have absolutely no choice. If you read my blog, you know that implementing braces was a last resort for me. As a programmer who works regularly with 5 different languages and has worked in the past with at least 10 others, I feel that it only helps you grow as a programmer to be confronted with new syntaxes and push yourself out of your comfort zone. If nothing else, it encourages you to do more thinking and less knee-jerk reacting. If I were to switch the terminator to be more C-like, well there would always be "just one more" C-like thing people would want it switched to as well. Eventually my mod would be pointless, because KSP already has a 100% C-like way to program it: writing your own mod. Part of the fun of developing kOS is being able to throw out convention and try new unexpected things. What I absolutely do not want is to create rage wars of people trying to share code and yelling at each other for not using the "one true terminator." And frankly, from my point of view, we've already passed the point where I would even consider doing a hard-change to semicolon for everyone. This one I definitely agree with. It's just one of those things I haven't gotten to. What I'm going to do is have optional periods after braces to avoid breaking old code. While I love bucking convention, there's no upside to }.}.}. I definitely want to give mod developers a way to join in, in ways that each mod doesn't require the other, but that they can optionally work together. I've been in some talks with the creator of infernal robotics about this. I did notice in one of my DLL fishing expeditions something about messaging for parts. This might hold the key. What I'd like is for mod developers to be able to register their own bindings and maybe even commands with kOS. And/or let kOS send strings to a part that have commands in them. Like TELL kethaneDrill TO "Deploy Drill". I did bring this idea up before, I think it's a cool idea and the kOS terminal already functions in a way that (I think) should be pretty compatible with telnet. But I don't have the time to work on this at the moment. Thank you, and I hope you and others find the unique quirks of KerboScript more endearing than annoying!

Okay, a fix for this is done and will be rolled out in the next release.

Well, in English a semicolon doesn't come with the option of another sentence, it comes with that as a requirement. And the second sentence MUST be related to the first.

Well you may be right, though history seems to show that when presented with an option, most people will keep the default. I'll relegate that to the back burner for now. I'll take another look at the resource tags, dangit I thought I had those completely nailed down.

Yes KSP won't honor any steering input I give programatically it while SAS is on.

You're right that in my video it's the amount of fuel left in the rocket, but that's only because I don't have any fuel tanks that are not connected to an active engine. Looking back at your original post, it sounds like you've got a tank lying dormant. Perhaps connected to an engine but an engine isn't activated yet. That woun't count toward your stage:liquidfuel calculation. EDIT: In debugging these things, it might be good to try a manual launch, but then when you reach the point you're expecting it to stage at, do a PRINT stage:LiquidFuel. You can bind that to an action group if good timing is needed.

Correct, and so does kOS. However I can't really save a file or configuration settings inside an action group.

It's one thing I'm working towards. My initial tests with hooking the steering system up to a rover did not go well. I'm hoping to have the abliity to set a target or give it a set of coordinates and have rovers autodrive to them. Edit: realized you may not be talking about rovers at all. I see what you're looking for though, I just need to find where to grab those values in the assembly.