Dunbaratu

That sounds like a bug where RT2 is overriding kOS to me. It sounds like RT2's "lock user out of controls if out of range" isn't differentiating between controls caused by manual input devices like keyboards and joysticks from controls caused by automation. I've wanted to get into RT2 for a while now but I've held off because I keep seeing some pretty severe issues with it not playing well with kOS in the github issues list. Until those issues go away I'm staying clear of RT2.

Really? That's a bit too ... Mechjeb. I'd rather have the components that go into the calculation than the final result of it. We're supposed to be writing the autopilot ourselves here.

That makes sense but you don't actually have to do that, and it presumes a flat world rather than a spherical one. As you gain altitude, your actual horizontal speed won't match your surface speed anymore - not exactly - because you're moving out at a larger radius from the center than the surface is. (But under 70,000 it's going to be a rather small error). You can just use the surface velocity vector instead: velocity:surface You can use the pythagorean theorem yourself to get the magnitude, or just use the MAG suffix like so: velocity:surface:mag

But that's because they derive it differently. If "triangle" is "go" and "square" is "stop" then two vertical bars looks like the stop square with a bit of it missing, i.e. a partial "stop" - thus it fits logically for that to be pause. That's always how I thought of that symbol. It still has a recognizable meaning that is derived differently from the original but is NOT just based on memorizing it. It does have a logic to it. When the arrows to the right mean "forward" and the arrows to the left mean "backward" then it stands to reason that the vertical bars are holding still. That's derived from thinking of the stream as a geometric line and thinking of moving along that line left and right. The reference for things like an old-fashioned phone handset and an old fashioned 3.5 floppy don't work that way. They aren't based on a logical geometric inference, but based on a cultural one. For those of us who were around when the thing they reference were common, it's mapping to a familiar thing. For younger people, it's just an act of rote memorization with no logic to it. I expect the 3.5 floppy icon will go away - probably to be replaced by a cloud with an arrow pointing into it.

Ah, I see. If that non-integer was less than 1, then yeah kOSscript doesn't deal with imaginary numbers. Everything must be representable as a Double.

I second this. The lack of "else" has made me write some weird code.

I assumed the cases where the C approach to for loops do a thing the visual basic approach does not were obvious and I didn't want to spend a whole post outlining them, but since they apparently weren't, I'll have to do that now. In your proposed system, the loop MUST have exactly one counter variable, no more and no less. It MUST be a number or at least an object like an iterator for which the operators +, -, <=, and >= are implemented. In a C++ for loop the initializer can be any statement you feel like and can even be omitted. If you'd like to design a loop that tracks using a pointer, you can. If you'd like to use a loop that tracks using a reference, you can. In your proposed system, the ending condition MUST be of the form A <= expr or A >= expr, where A is the counter variable. In the C++ approach you can use any particular boolean expression you feel like, and it can contain any combination of ands and ors, and it doesn't have to be a numerical check where "<=" and ">=" make sense. You could, for example, test for whether or not nextNode == NULL when traversing a list or tree.' In your proposed system, the incrementer must be of the form A = A + C, or A = A - C, where A is the loop counter and C is the step. Any other type of increment is not supported. You can't walk a tree for example by having an incrementer that says A = A.getNextNode(). Here's a simple example of a thing that I don't think your proposed for loop supports that C, C++, and Java do support: // Binary search on an already sorted array of strings for the index of the hit, or return -1 if no hit found: // assume the following variables exist before starting: // char needle[] = "some string I'm looking for"; // char *haystack[] is a sorted array of the strings being searched // int haystackSize is the length of the haystack array. // int min, max. middle, cmp; for( min=0, max=haystackSize ; min <= max || cmp != 0 ; (cmp<0 ? max = min + middle : min = min + middle) ) { middle = ((max-min)+1) / 2; cmp = strcmp( needle, haystack[middle] ); } if( cmp == 0 ) { // hit was found at index "middle". } else { // hit was not found. } Note: I haven't compiled and tested that. It's written from memory about how the basic algorithm works and it could include things like off-by-one errors and such. My goal was not to write perfectly debugged code but to show an example of how the for loop is truly open-ended and unrestricted in C/C++/Java much more so than what you're proposing, precisely because it does *less* built-in logic and therefore doesn't dictate anything about how the loop is required to work. Arguments have been made that this is a bad feature of those languages and it makes the FOR loop confusing. I'm not trying to enter that argument. I don't agree with it, but I also don't care as much about it. What I do care about is that you made the claim that you can do all the same things with the FOR loop you're proposing that can be done in C/C++/Java and that this claim shows a large misunderstanding of how the FOR loop works in those languages. In those languages, the FOR loop is nothing more than a way of re-writing a WHILE loop with some of the code moved from the body to the header, and as such it doesn't dictate anything about the actual algorithm. Which is why I said that that I could cover the cases that your for loop doesn't cover, but C/C++/Java for loops do cover, by using an UNTIL instead. an UNTIL is just a WHILE with an implied "not" applied to the boolean check. If you were going with the sort of FOR loop that exist in C/C++/Java, than ANY code of the following format: stuffAAA. UNTIL stuffBBB { stuffCCC. stuffDDD. } Could be re-written as: for( stuffAAA ; not( stuffBBB ) ; stuffDDD ) { stuffCCC. } For any arbitrary stuffAAA, stuffBBB, stuffCCC, and stuffDDD. Regardless of whether that stuff includes counting a variable up or down across a range of numbers.

In the days before the SQRT operator you had to get a square root by taking something to the power ^0.5 and that worked just fine. Are you sure this doesn't work?

Or hook it into the screenshot saving mechanism. Allow you to "picture frame" a screenshot and put it in the "museum" as a mission photo.

The actual internet timeout for attempting TCP connections tends to default to 2 minutes. Back in the day with very slow connections this made more sense. Now it's just silly, but a lot of the same rules are still used deep in the network stack of operating systems.

Given what you said here that is false. But at any rate it seems like it will be easy to work with and I can always resort to a more raw approach using an "until" loop when I want to make the sorts of for loops that this structure doesn't support.

Yes, I knew that. But THIS: Is what hadn't been specified until now. It's basically the difference between whether is is SETting the end condition to the expression or LOCKing the end condition to the expression. Now it's clear. Although it does bring up another question: does it check the sign of the increment again each time too? If someone did something utterly ridiculous and say started a loop going from A to B step C, in which A < B, and then partway through changed B to a small number such that A > B, would the loop know to reverse the direction of the increment C? Or is the direction of the increment only determined once up front and then it stays that way? You basically said that the programmer doesn't need to specify the sign of C because the system automatically chooses whether to add or subtract C based on whether A <B or A > B. But is that decision re-evaluated each time as well as the expression C being re-evaluated?

I can verify I have the same problem. It happens when it has an optional bonus payout and you choose NOT to fufill it, but instead just click the "hide optional goal" during the mission to clear it out of the window. When you do that and then later finish the mission, that empty window appears and the only way to make it go away is to exit KSP entirely and re-run it. It stays there on all the screens. Specifically, I got it to happen on the "Kastor IV" Mission from the "Kerbin SOI" mission pack. That mission includes an optional goal that requires you to have the "clamp o tron Jr." unlocked in the tech tree, and I didn't have that yet so I skipped it.

I notice that this is not the same github page as you were using before. Have you and marianoapp moved to this new fork and all future development should happen there? At any rate I added several issues about the new version to that page for a problems in the parser. But the following problem is not related to the new parser and was there in the old version. Since I don't know if the old fork is being abandoned and everything is moving to the new one or not I'll report it here in the forum instead of on github: The value of SHIP:SOLIDFUEL doesn't return zero when there's no solid fuel. Instead it says "suffix SOLIDFUEL not found on object" and bombs out.

Not really. It doesn't clarify what this does: 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. }. If the expressions in the for syntax evaluate up front once, then it does this: A is now 1 A is now 2 A is now 3 A is now 4 A is now 5 If they evaluate each time dynamically, then it does this: A is now 1 A is now 2 A is now 4 A is now 8 A is now 16 A is now 32 Does changing the value of endp or incr inside the loop body do anything to the checks, or have those expressions already been evaluated into a final answer by then and only the final answer is remembered? That was my question. Another example of where the two approaches differ is what happens when you insert or delete from the very list that you are iterating over. If you use a for loop to iterate from 1 to list:length, and the purpose of the loop is to insert some items into the list whenever an item is found that fits certain criteria, then when does the loop stop? If list:length was originally 10, but your loop added 2 items to the list as it goes, does it stop at the original value of 10 or does it re-evaluate the expression list:length each time so it stops at 12? That's the meat of my question.

But the important question is when do the expressions get evaluated? Up front before the first loop iteration (making them effectively a static constant once the loop is executing), or again and again each loop iteration (making the expression capable of containing live dynamic logic in it). That's a difference that is more than just syntactic sugar. If a for loop must have a fixed number of iterations before it starts, that actually affects the sorts of algorithms a for loop can be used for.

You could be in a situation where the mod in question for the part cannot be loaded because it hasn't been updated to the newest KSP. You don't want to ruin the entire save game making it impossible to load just because one of the vessels in the game is impossible to load. It's just simple to ask the user: "If you continue loading this saved game all the following vessels will have to be deleted from the saved game because they contain parts that are not defined: vessel A vessel B vessel C .. etc.. Do you want to continue and delete them? (Y/N)?"

For maximum flexibility, I'd prefer something akin to the C for loop, which is so versatile you can use it for everything. Here's the starting setup, Here's the boolean check between iterations. Here's the thing to increment each time.

I probably won't have a chance to give it a good test until Friday, but I'm looking forward to giving it a go.

If you're going to make a different version of the kosscript language from what's in erendrake's version, it's probably a good idea to pick a naming convention for the fork of the language you're making. Just so people writing scripts can say things like "this program is written in jebscript not kosscript" (or whatever ends up being the names). Basically there's a long tradition of being able to divorce the naming of the language variant from the naming of one particular program that implements it, so that if you change a language a lot in your implementation it's a good idea to give it a different name so you don't have to refer to it as "the version of the language that that program does instead of the version that this program does."

In general I've found it massively useful to always remember this in the top of my head in any thinking about maneuvers in KSP: "Always, always, always, your predicted orbital ellipse must necessarily include returning to your current position." In other words, your current location is the "pivot point" of any maneuver burn - the one position, locked in place, that must always be part of the new orbital path you're creating. Keeping that at the top of your mind helps avoid a lot of pitfalls. In this case it helps remind you that it's impossible to raise your periapsis higher than your current altitude because (periapsis <= altitude <= apoapsis) must always be true if your current location has to be on the orbital ellipse. What's happening in your case is that before you hit the point where periapsis >= (original apopasis - 2500), periapsis has rotated position with apopapsis so that now apoapsis is on the far side and periapsis is near you. At that point your orbit has already passed through circular and you're now stretching it out again by burning more. And this has happened before periapsis got to within 2500 of what apoapsis used to be so your script didn't catch it and stop you. Try this logic instead: "Burn until diff between my current periapsis and my current altitude is a smaller number than the diff between my current altitude and my current apoapsis." You can do that in one simple "wait until" expression. That will burn until you pass the point where you've pushed the apoapsis around to the other side of the orbit from you. I used this and it works like a charm every time. Your logic to slow down the burn as you get close to the cutoff point is good tactic to get more precision, but the way I typically do that is to lock the throttle to a math expression that continuously gets closer to zero as it gets closer to the endpoint, like this for example: lock throttle to 0.01 + (apoapsis - periapsis)/5000 . In that example, the throttle stays > 1.0 (which kOS just takes to mean the same as 1.0) as long as apoapsis is more than 5000m higher than periapsis, but then it starts scaling down from 1.0 down to 0.01 as the difference between apoapsis and periapsis scales from 5000m to 0m. The reason for adding 0.01 is that you need to avoid the case where you asymptotically approach the endpoint without ever actually quite reaching it, which is what could happen if you bring the throttle to exactly zero as you bring the oribit to exactly circular.

(What does MLP mean?)

False. The GPU does not do most of the calculations in KSP. The physics engine does not make use of the GPU hardware and runs entirely in the CPU.

Have you looked at Jebnix and what woodywood is doing? It seems interesting but probably a lot harder to merge any code with.

This may be related to a bug I've found when a vessel is designed in two equal halves in a stack facing each other like so: Engine (A) upside down. Fuel (A) upside down. Decoupler (A) upside down. kOS SCS part (A) upside down. Command Core (A) upside down. Docking Port (A) upside down. Docking Port ( Command Core ( kOS SCS part ( Decoupler ( Fuel ( Engine ( After decoupling the two halves into separate crafts, A and B, issuing the "stage" command from kOS SCS part A causes the other craft's decoupler, decoupler B, to stage instead of its own decoupler, decoupler A. This is even though kOS SCS part A isn't even connected to the vessel containing decoupler B. When decoupling, something isn't being updated about which vessel the CPU is associated with, I think. This is a bug I discovered a long time ago back in 0.7 but it might still be there if it never got addressed.