Dunbaratu

Useful to know. I wasn't answering the "what does it mean in KOS" sort of question but more the "what does the acronym NaN mean" question in the general sense. The fact that kOS was designed to overload the meaning of NaN by also using it for disabled sensors (which makes sense and I didn't know that, thanks for the heads up) is sort of another layer on top of the question of just "I've never seen 'NaN' before what does it mean?". But without an isNaN() check being implemented, returning NaN to the user isn't a very useful way to report that the sensor is turned off. Your script code can't respond to the condition because NaN doesn't work like normal numbers and you can't just put it in an expression like: if value = NaN { ... do something ... }. (And according to the IEEE standards, you're not *supposed* to be able to do that with a NaN. Languages are meant to provide some sort of a function call or macro syntax that lets you check it by saying isNaN( value ), apparently because there are multiple binary representations that all mean NaN so it's possible for one NaN to not equal another NaN if you just check them the raw way.)

In general the lack of an "else", combined with the lack of a "not" operator, makes some things a lot messier than they need to be.

I see a few potential problems: 1 - You mention that the Mun's altitude is the length of line B. It is not. Altitude is the distance to the parent body's SURFACE, not to it's CENTER. TO get the distance of B you have to add Mun:Altitude to Kerbin's radius. (which is 600,000). The same is true for the length of A - you need to add your altitude to Kerbin's radius. 2 - Be aware that there is an annoying discrepency in the frame of referenced for reported numbers. A body's POSITION is given relative to your craft, but a body's VELOCITY is given relative to the body your craft is orbiting. I don't know why they're different, but as long as you are aware of it you can translate between the two frames of reference easily enough once you know your own position relative to the parent body, and if you transform your UP direction into a unit vector using tfDirToUnitV here: http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs (once you turn your UP direction into a unit vector, if you multiply it by the scalar (body's radius + my altitude), you get your position relative to the parent body. So with that you can add that vector to the Moon's position relative to you, to get its position relative to the parent body. Without giving all the ugly details of how floating point numbers are stored in binary form, suffice it to say that there are some bit patterns that are invalid and don't really map to anything real. These patterns are used deliberately to store the fact that a numerical result is "impossible" or "infinite". When KoS returns "Inf" for a number, it means "You tried dividing by zero". (Yes, I know dividing by zero doesn't *always* mean it's a phenomenon that approaches infinity, but computer numbers tend to assume it does.) When kOS returns "NaN" for a number, it's an acronym that means, literally, "Not a Number". That might sound like something Kevin made up, but it's not. That's been a longstanding well known acronym in computer programming languages. NaN is used for situations where the resulting number is mathematically not possible to represent as a real number at all. Examples include: - Trying to take the square root of a negative number returns NaN. - Trying to use inverse trig functions like arccos on a value that cannot possibly be a cosine. "NaN' is probably coming from your arccos. The value inside the expression is probably less than -1 or larger than +1 so there's no such angle which would have that cosine.

One simple thing that it might be is just this: Where was the keyboard focus when you pressed ALT-1? The trick of using action groups as a roundabout way to get live key input requires that you are in the camera view (not map view) and that the terminal window NOT be focused. It has to be "greyed out" because unless your kepressess are passing through to the KSP game, hitting ALT-1 doesn't trigger action group 1.

I've also noticed this seems to happen for me only after having done a "revert to launch" or "revert to vehicle assembly bay". I wonder if some aspect of the KOS module isn't being properly unloaded and in some way a piece if it is still trying to execute from the previous run. i.e. the part is gone but there's still a bit of a hook leftover in the DLL that's still trying to do something.

Another important difference between archive and local volume is that the local volume is saved in the campaign saved game, while the archive is saved outside of he campaign directory. Therefore programs you store in the archive are not only available to different ships, but also between different save games.

It might be a timing issue that is altering the order in which widgets get drawn when it gets laggy.

Has anyone else had these things happen? After running a KOS script for a while, some of the user interface elements of KSP look messed up and bits of the widgets are blank. The game continues to function but you can't see some of the displays. Specific examples I have seen of this are: 1 - throttle slider gone. The slider indicator disappears, and sometimes the notches aren't drawn either, turning the slider into a blank grey arc. 2 - round altimeter widget gone from the top of the screen, a blank grey where it's supposed to be. (the rolling number wheels are there, but the 'clock-style' circular part is gone). 3 - sliding chevrons in the staging/docking indicator on the lower left are missing. 4 - RCS and SAS lights are masked off in the navball. 5 - Some of the indicators on the navball are missing - maybe it has crosshairs but not the prograde mark, or visa versa. Also, switching to map view shows a different set of UI problems on the navball, usually. Maybe problems 4 and 5 might exist on map view, while they don't exist on camera view, but problem 1 does instead, for example. It is inconsistent which problems occur in different runs of the same mission with the same KOS code. As far as I can tell it appears to be a problem with the ORDER in which KSP draws the UI elements. They flicker in occasionally such that I think they're there but they're layered on top of each other in the wrong order, so for example the background plate for the throttle arc gets drawn on top of the throttle chevron rather than under it. Has anyone else had this happen? It seems to coincide with the 'pausing' hitches in game performance. Once I start getting a lot of pausing hiccups, I also get the UI problems.

What I'm saying is that it's perfectly safe to use the technical terms when reporting a bug to the user, the existence of which already renders the beginner-friendly goal moot. After everything is working right and kOS is more robust, in order to achieve the goal of making it beginner-friendly, the language is going to have to "just work" when it comes to casting numerical types into each other. Therefore go ahead and use the real info when reporting a message that can only occur when that goal isn't working. Problems with mismatched number types are the sorts of problems that can only happen when the beginner-friendliness isn't quite all there anyway.

Technically, what you just described there about the orbit path is impossible once you get back into the atmosphere. The atmosphere will enforce your conformity to the surface frame of reference (which won't be a straight blue line down, because the map view operates on the orbital frame of reference, not surface frame). The atmosphere does this by pushing sideways on you until you match horizontal velocity with the ground, because atmo drag calculations use your surface velocity, not your oribital, on the presumption that the air around the planet moves mostly with the planet. By the time you get to sea level that's a pretty huge difference. It's 174 m/s different.

There are loads of object casting problems in kOS like this, which are, IMO, made worse by the decision to mask off and hide the precise type information from the user. When floats, doubles, integers, and long integers are all called just "Number" by the code, in an attempt to make things "easier" for the user, that attempt backfires and makes things harder when a user sees a message claiming you can't add a "number" to a "number", or can't compare a "number" to a "number", and the user goes "WTF are you talking about? Of COURSE I can add numbers to numbers. I do it all the time." What the code was actually doing was complaining about two different types (say, Float and Integer for example), but then masking their type names when displaying them to the user, so they both got called just "number", which leads to that ridiculous looking error message. There's been a lot of pull requests about trying to fix this with getting all things in the system to return the same type: Double, but I can't help but wonder if the right solution isn't to tackle this root problem: Why on earth can't KOS cast between integers, floats, and doubles in the first place, as need be? The fact that something returns integer instead of double shouldn't BE a problem in the first place. There's plenty of very well defined type promotion rules for how to handle mixed number types in expressions. If you add an integer to a double, you promote the integer into a double first, then do the operation and return a double. This is exactly what happens using low-level primitives in C: int a = 5; double x = 6.0123; double y = x + a; // works just fine because the expression temporarily makes a double version of 'a' to add it to x. I find it really odd that this behavior gets lost when using objects like Integer and Double rather than primitives like int and double. It seems like a step backward that the more high-level objects are actually LESS useful than their primitive counterparts.

I see a nasty potential cheat exploit in how the rules are set up. The rules as they stand now allow multiple launches into Kerbin orbit and only after you leave Kerbin orbit with one of them are you not allowed to launch more. As long as you do this your launches get to be called "one mission composed of separate launches", even though they were designed and they operate entirely independently of each other. So I make one mission that gets to the Mun and back and test it. Then I make another mission that goes to Duna and Ike and I test it. Then i make another mission that goes to Eve and Gilly and back and I test it. At this point I'd have done 3 missions: 1. a mission that goes to 1 moon. 2. a mission that goes to 1 planet and 1 moon. 3. another mission that goes to 1 planet and 1 moon. To weasel my way into more points I could just do this: launch mission 1. Get it to the point where it's in orbit around Kerbin and stop there. launch mission 2. Get it to the point where it's in orbit around Kerbin and stop there. launch mission 3. Get it to the point where it's in orbit around Kerbin and stop there. From then on, the way the challenge rules are worded, those three are the "same" mission. Now I just go back to each of them and finish their separate missions to the end and I get to pretend I went on one mission to 2 planets and 3 moons when I didn't, not REALLY. Granted, there's a bug right now that gets in the way of trying to do this, and that is the fact that when you go on rails and come back your ship doesn't load up properly if you have any scientific notation variables in the context store. However: 1 - It's not a good idea to make the scoring rules utterly dependent on a bug remaining unfixed (especially in this case as the bug *is* fixed in a github fork and is just waiting to be pulled back into the master for release). 2 - There exists a workaround to avoid the bug even now - just have the craft set all the variables it used to zero before putting it on rails so none of them will be hard for the mod to load back in again. I think the phrasing for multi-launch missions needs to be worked on to remove this exploitable wording. Something about how in order to count as one mission, at some point all the crafts have to have been attached together into one craft during a transfer from one SOI to another. Any craft that did not participate in that single joined together craft does not get to be called part of the same mission.

So how does the player design cause KSP bugs again?

Yeah there's backward compatibility problems in how things are documented. Originally VELOCITY was orbital and there was no way to get the surface velocity and then you just used it without the suffix.

VELOCITY:ORBIT is a vector. All vectors allow you to perform these operations: somevector:x somevector:y somevector:z somevector:mag so you want VELOCITY:ORBIT:MAG.

Looking at the code, yes you're right it does. But it didn't look that way in the video. It was moving far too fast to be trying different normal burns at each position. When I try that it takes *forever* to iterate over the guesses and you can watch it trying each guess on the screen.

The thing that I think would help the most is the ability to read those "Closest Distance" chevrons when you *don't* have an encounter. That would allow you to use KSP's own built-in functions that solve the hairy calculus-by-slices problem of working out eliptical orbit timings. (There is no clean mathematical solution to working out how long it will take an object to get from point P1 to P2 in an elliptical orbit other than numerical approximation by iterating over finite slices. Trying to do that sort of thing in a slow computer like the KOS SCS is just not practical, but KSP under the hood is already doing it when it shows you those encounter chevrons, so it would be nice to have access to that information.)

A warning to anyone who tries to use this code: When @AbeS said "Real Kerbin" that does NOT mean "this is the real data for Kerbin". If you use these numbers in a stock install of KSP, it WILL mess you up. What "Real Kerbin" means is this: "There is a Mod called 'Real Kerbin'. It changes the values of Kerbin to be similar in magnitude to Earth. These are the values to use when you have that Mod installed." Just seeing the words "Real Kerbin" in the code won't clue people in to that if they hadn't heard of the mod.

But... But... it *works* when I do it. See this example: set x to "bbb". if x = "aaa" { print "it is aaa". }. if x = "bbb" { print "it is bbb". }. it is bbb That seems to be comparing to a string literal just fine.

Impressive. I would have expected that deadburn technique would waste a lot of fuel (to kill all horizontal speed and fall straight down) but it seems to work okay. I also like your solution to the inclination problem. You seem to be waiting for 1/2 of ETA and then correcting it. That seems to depend on finding an encounter first before correcting inclination though. I think it might not work as well on interplanetary transfers where an inclination of a few degrees means the game won't report an encounter at all - it's too far off - but first to Minmus! Good job.

One possible explanation is that you two are deriving the TWR answer using slightly different math expressions that according to the rules of MATH are the same thing, but don't necessarily give the same result when storing intermediate values of the expression in the lossy storage format that computers tend to use. The fact that the gravitational parameter is derived from multiplying a very very tiny number by a very very big number in a way that cancels out their "bigness" to get a very medium number like 9.8 can mean that the exact order in which things are calculated makes a noted difference in error of the final answer depending on the order in which you perform the operations. Let bigNum = some really big number like 1.2345678 * 10^22 let smallNum = some really small number like 1.2345678 * 10^(-22) In principle, bigNum * smallNum should give you exactly 1. And the following expressions should be the same: (bigNum / 1000) * 1000 * smallNum bigNum * smallNum * (1000/1000) (bigNum * 1000) * ( smallNum / 1000) But in practice on a computer they often are slightly different because you're storing intermediate values along the way in a format that can't store them *exactly* as they are, so that it matters which "lossy" operations happen when. That's just a guess.

Maaaaan I am SOO close to having a working Duna mission including a stopover on Ike while I'm in the area, and a return. The only thing I still need to do is alter my orbital transfer program to be able to handle either case no matter which way the sign points (the same math that finds a transfer orbit position using prograde delta-V to go from Kerbin to Duna shouild be able to find a transfer orbit position using retrograde delta-V to go from Duna to Kerbin. But my script had a few places that made presumptions about the sign that I need to make more universal for either case. That's the last thing I need to fix and then I can start making the video.) It will probably be broken up into two videos because this one is a much longer mission: It consists of the following individual steps, each a separate program with parameters: ascend to Kerbin orbit. escape Kerbin SOI in Kerbin's prograde direction. transfer to Duna. get captured at Duna. descend to Duna landing. ascend to Duna orbit. transfer to Ike. get captured by Ike. descend to Ike landing. ascend to Ike orbit. escape Ike in Ike's retrograde direction. When back in Duna SOI, escape it its prograde direction. transfer to Kerbin. get captured by Kerbin, at a low enough altitude to areobrake. hit the 'chutes. done. The craft itself will be an ugly monstrosity because I'm trying to do all of this without any re-docking so I have a lot of stages and a lots of consumable, separable fuel tanks to leave behind in all those landings and taking offs. So watch this space. I should have it in by the end of the weekend.

Brain fart. Right. That would work.

I do the same thing you do but I don't use the grav sensor and have no idea how it functions. Instead i just calculate it myself based on body's mass and my altitude and the standard law of gravitation, like so: lock heregrav to gConst*bodyMass/((altitude+bodyRadius)^2). From then on 'heregrav' will be the same thing you're trying to read from sensor!grav. Where: - gConst is the gravitational constant. - bodyMass is the mass of the body you are orbiting (you can get this now from Body(body):mass , which you couldn't before.) - bodyRadius is he equatorial radius of the body you are orbiting (which I don't think is in the Body struct yet in KOS so you'll have to get it from a wiki search). set gConst to 6.67384*10^(0-11). // The Gravitational constant - same no matter what body you orbit. set bodyRadius to 600000 . // For kerbin, for example. set bodyMass to 5.2915793*10^22. // for kerbin, for example.

The following part of my descend script has always worked just fine: if STATUS = "LANDED" or STATUS = "SPLASHED" { if descType = "hover" or descType = "lander" { // Stop moving: set mySteer to up. lock throttle to 0. wait 10. set beDone to 1. } if descType = "skycrane" or descType = "skycrane/lander" { SAS ON. // To ensure the payload is holding itself stable. set dMode to 2. }. I thought comparing to string literals only was a problem when the object being compared isn't normally a string. The objects in KOS implement toString() methods that allow them to cast themselves to a string when needed. The problem as you explained it before, is that this conversion isn't being triggered by attempts to compare versus a string literal like it should be, but it *is* being triggered when comparing versus a string variable. Since STATUS really *is* a string, rather than just masquerading as one, no casting is needed so it works fine regardless of whether you compare it to a string literal or a string variable.