Dunbaratu

There is a bug with KOS where its expression system can't properly convert different types of number to each other and work seamlessly like they should. Most programming languages either: A - Have no trouble automatically converting between integers, long integers, floats, and doubles so you don't need to explicitly convert them, or B - Allow you to explicitly convert them manually. But with KOS it's sort of the worst of both worlds. You are denied the ability to manually convert numeric types yourself, AND the system won't do it correctly for you. So when there's a type mismatch, you're out of luck and can't do anything about it. At the moment this is being handled by trying to make all the numbers returned everywhere in the system be the same type of number - a double-precision floating point number - so the conversions never have to happen. But there are a few places where that hasn't happened and one of those places is TARGET:DISTANCE. This is what leads to that rather odd looking error message "Can't compare number to number", which sounds utterly ridiculous until you realize that what's going on is that it's actually complaining about "Can't compare float to double" or "Can't compare integer to double" or something like that, but the true names of the types are being masked when the message is printed and all numeric types are getting called just "number" in the error message.

No. I understood it, and disagreed with it. Only if you run KSP ALONE and shut everything else down would it be true that you won't see any benefit from more than 4GB while running it. The ability to have OTHER THINGS also be resident without THEM swapping will help the performance of KSP when those things are running at the same time as KSP.

This post contains no useful information.

I am NOT arguing for removing functionality. Being able to detect if you're going to escape the body or not *is functionality*, and it's functionality that you're ignoring when you decide to mislabel wanting to have that functionality as "removing" functionality. (EDIT: OR to be more generous to your position, I'm swapping one functionality for another, which is at worst a null effect on total functionality, not a drop in functionality). And while you *can* calculate things like eccentricity from a negative apoapsis, it's not the ONLY way to do it. So the functionality you're talking about isn't gone, just more ugly to get. Compare that to the functionality you're arguing I shouldn't have. It's not derivable mathematically. There's no alternate recourse for it. Given your current position and velocity and the planet's mass is enough on its own to derive everything else. It might not be pretty but at least it's actually *possible* to calculate with what's there now, unlike the problem I'm talking about where no amount of math will help learn what SQUAD set the SOI to for each body. So I'd be fine with restoring the broken definition of apaopsis to allow it to be negative if it coincided with also being able to get SOI data about the bodies *at the same time in the same release*. But what you and boalan have been arguing for is to fix the ability to calculate using a negative apoapsis FIRST and then eventually later on, if time permits, get around to fixing the apparently less important problem about how you can't get correct ("correct" meaning "works for the purpose of flying a craft in this simulation", meaning "takes into account the simulation's SOI feature") escape information. And if one problem can be fixed with a workaround and the other can't, the one that can't is more important. So to summarize my position: Fix the SOI problem first and restore negative apaopsis later. - I'm fine with this. Fix the SOI problem and restore negative apoapsis in the same reliease - I'm fine with this too. Fix the SOI problem later and restore negative apoapsis now - I'm not fine with this for the reasons stated above. The SOI problem *requires* getting information from KOS as there's no alternative way to calculate escape mathematically right now. There *is no* workaround right now. There are, however, workarounds to not being able to see a negative "apoapsis".

I guess the reason we're arguing is that the manner in which the current system is broken is useful for you and broken for me. It is currently impossible to detect whether or not I've been captured. Getting to where it reports the bogus negative value for apoapsis does not imply I'm captured. Because of the game's SOI radius issue you can have a positive apopasis and yet still escape and not come back. That's rather important when you want your autopilot to burn retro long enough to get captured but not long enough to circularize, as that's wasteful to do. As it is I have to make a pure guess and say if I've gotten it down to about 60% of escape velocity that's probably small enough to be within the SOI of things in the KSP simulation - maybe. But those sorts of guesses often turn out to be wrong, as it's not the same for every body. the SOI radius is an arbitrary decision that doesn't seem to follow a pattern. It doesn't seem to be based on a calculatable thing but rather is an arbitrary decision SQUAD made for each body. In some cases, like Ike around Duna, the SOI is a lot smaller than you'd think, apparently because Ike's closeness to Duna would make it interfere with Duna orbits if it had too large of an SOI. The problem is that you're basically saying your problem is important and mine is irrelevant when you qualify the current behavior as "correct" and claim it should be left in place in favor of a nebulous non-existent solution.

I haven't been arguing for removing it. I've been arguing for making it correct. It is incorrect to claim it's positive when it is in fact not because the simulation doesn't match reality. In the game if your apoapsis is higher than SOI then it's not honest to report it as if it's not infinity. As far as the GAME cares, it's infinity. You're not coming back down.

I frequently find that I get numbers that are close to correct but not exactly correct when trying to use inverse trig functions like arctan. Trying to calculate where the ascending and descending nodes were between me and a target for the sake of doing an inclination correction had the same problem, where it was always off by just a degree or so, untill I used larger vectors for it. (i.e. finding the dot product of two unit vectors and then getting the cosine from that dot product seems to be rather error prone, whereas doing it with the full length vectors instead of with unit vectors, gets a far more accurate answer.)

I'm aware of everything you said here. It does not cause the problem to go away, nor does it make it magically stop being a problem no matter how much you keep repeating the mantra that it "works as designed". You just accurately described what's wrong, which is, in a nutshell, that what the laws of physics claims your apoapsis is, is not in agreement with what it actually is in the simulation, and for the sake of an autopilot, what we need to know is what the simulation thinks it is, not what the laws of physics claims it is. If I want to burn retrograde until captured, I have no choice but to use what the KSP simulation thinks of as escaping, which is not what physics claims is escaping, nor is it what status="ESCAPING' claims is escaping. And there is a difference between a number that happens to work in a degenerate case and a number that means what it's defined as. A negative apoapsis violates the definition of what an apoapsis IS. A far better solution is to get the eccentricity as a direct query, rather than to falsify the apoapsis to let you calculate eccentricity from it and in so doing to break the ability to detect whether or not you're going to exit the SOI.

Apparently the expression I was trying to lock the throttle to was producing a value of Infinity while maxthrust was zero, which it temporarily is for just an instant during the staging process. So I unlock the throttle, then do the stage, then relock the throttle and the problem seems to have gone away.

I keep having this happen in my script and I can't figure out why. It just started happening recently. When the script gets to the part where it hits "stage" the first time, it completely ruins KSP, doing THIS to it: (Note the weird values for altitude and velocity. Most properties I attempt to print after the entire scree blacks out like that end up being bogus NaN values. They weren't prior to the blackout.) The only recourse at this point is to kill KSP from the task manager. As near as I can tell this happens as soon as I execute "stage". I'm still trying to trace down the conditions that cause it. Every time I try making a reduced version of the ascent program that removes everything except the problem lines, it runs fine.

On another front, I've found a much easier way to work-around the craft loading bug. Before you leave a craft that you intend to come back to later, issue this command on the KOS part (or all the KOS parts) that ever ran any KOS code: SHUTDOWN. Then when you reload the craft you can turn the KOS unit back on from the toggle power option on the rightclick menu.. The fact that the craft was shut off when it went onto rails means the KOS mod didn't try to save its variable context in the persistence file.

Are you proposing that the object remains frozen in position until a low load time? I don't think that's workable, as it breaks the object's position relative to other objects. .

For those who don't believe me: I started from the first image, then burned slowly to the second image while printing my apoapsis as I burned. Note it stopped giving me negative numbers *before* I was captured. Therefore the thing that began the entire bug report, that being the fact that the numbers do NOT in fact tell me if I'm going to escape or not, is true. Addendum: checking for STATUS="ESCAPING" has the same problem. It will claim I've been captured (STATUS="ORBITING") when in fact I haven't been. It's reporting numbers as if KSP's concept of an SOI radius didn't exist. If you want to roll back the changes to re-instate this behavior, then please explain an alternate way to get this data. I don't know how to query the game for the body's SOI radius. If there was a way to do that, that could provide an alternate way to get this information (if apoapsis < 0 or apoapsis > Mun:SOI would work for example, if there was such a thing in the language as Mun:SOI).

Even if it did consistently return a negative number that you can plug into the equation to get your eccentricity, it still wouldn't be correct to call that negative number an apoapsis.

Apparently providing that information once isn't enough. I already described it in the github issue.

How can a pull request "remove" information that is already physically impossible? A hyperbolic orbit is one that by definition does not HAVE an apoapsis because it doesn't curve back and fall in again, and therefore there's no such thing as the "highest" altitude it will achieve. What I was asking for was a way to detect this scenario and stop returning bogus false numbers for apoapsis in this scenario like it does now.

It is not trivial that you had the meaning of adding the suffix ":BODY" misunderstood. That will mess up everything else you try to do. In this *one* example case, all it does is change the sign, but in the general case, believing that Kerbin:BODY is Kerbin, when it's in fact the sun, will mess up lots of math you try to do.

It appears to be in the same orientation. A different origin point, but the same orientation. So the only operation needed is a translation, not a rotation. I've had success getting the Mun's position relative to Kerbin by just doing simple vector tip to tail addition - adding (my position from Kerbin) to (Mun's position from me) to get (Mun's position from Kerbin). Kerbin:BODY:position does not give you YOUR position at all, in ANY frame of reference. Period. It gives you The Sun's position. Because Kerbin:BODY means "The body that Kerbin orbits", i.e. "the sun". That's not true. They have to be in coordinate systems that have the same orientation, but don't need the same origin to add them together. In fact that's pretty much the definition of vector addition of vector A to vector B. You're making vector B be "origined" at the tip of vector A.

There were some bugs that could cause that that I encountered in previous versions. I am not aware of any in the current version. Can you post the script you're trying to run?

You say you read through the Wiki. Have you seen this page? http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP Caveat: I wrote that based on guesswork and trial and error taking different readings at different positions until I'd worked it out. So I don't know if it's right or not. The coordinate system of KSP is weird because it keeps changing where the origin is depending on context.

That makes sense, because Kerbin:BODY and Duna:BODY are two different ways to refer to the same object - the Sun. The special keywords Kerbin and Duna already *are* objects of type BODY. You probably should have just typed Kerbin:POSITION and Duna:POSITION. Each object of type BODY has a property, also called BODY, which is referring to the parent body that body orbits (this is a holdover from the fact that when you type just BODY, it refers to the thing your craft orbits. I'd have preferred a less confusing term like "PARENTBODY".) So when you said Kerbin:BODY you ended up referring not to Kerbin, but the thing Kerbin orbits - the Sun. This is why Kerbin:body and Duna:body are the same thing.

They're relatively recent and I'm thinking of overhauling the wiki page on XYZ coordinate system to talk about them. One exceedingly annoying "feature" about them is that the origin of the coordinate system for a body's POSITION and the origin of the coordinate system for a body's VELOCITY are not the same. Since velocity and position are directly connected to each other, having them reported in different coordinate systems so you constantly have to shift the origin when using them together is really messy. A body's VELOCITY is given in a coordinate system relative to your parent body you are currently orbiting. BUT, a body's POSITION is given in a coordinate system relative to your craft's position as origin, NOT the body your craft is orbiting. So for example if you are orbiting Kerbin, then Mun:POSITION is the position vector from YOU to the Mun. while Mun:VELOCITY is the velocity vector of the Mun relative to Kerbin, not relative to YOU. To prove this get into an orbit around Kerbin and keep printing both Mun:POSITION:MAG and Mun:VELOCITY:MAG. as you orbit. As you change position and velocity going around Kerbin, Mun:POSITION is smaller when you're on the side of Kerbin closest to it, and it gets bigger when you're on the side of Kerbin facing away from it. BUT, Mun:Velocity is only changing by a tiny amount as it slowly orbits Kerbin, while if it was based on being relative to you like the position was, it should be giving drastically different numbers when you're flying toward, away from, or perpendicular to it as you orbit around Kerbin. I'm not sure if this is KOS doing this or if this is just KOS exposing a weirdness about the underlying KSP C# API. It's workable as it is, as long as you know this fact, as you can always adjust between the two frames of reference because you can get your position relative to the body you orbit, but it's really odd that you have to make the adjustment because the system is being inconsistent with itself.

NOTHING can instantaneously stop, period. It requires an acceleration of infinity to do so. All scenarios in which you claim the earth stops must include how many seconds you're picturing it taking to do so. The answer cannot be zero seconds (to stop "instantaneously") Even an object moving at only 0.000001 meters per second STILL requires infinite acceleration to stop in an instant. Without that context of how many seconds you're talking about it taking for the Earth to stop, you're talking about a scenario that breaks all calculations using Newtonian physics anyway. You'd be introducing everything on the planet to a Space Kraken bug. But if we temporarily accept the absurd scenario, people need to remember that when you say "the earth" stops rotating you need to define what bits of mass are part of "the earth" and are thus included in that magical stopping. The talk about oceans sloshing, and tectonic plates shifting are rather predicated on treating these things like they're not part of the earth and are therefore not included in the statement "the earth stops rotating". Speaking of the earthquakes and magma effects from the shifting plates is basically a case of pretending the word "earth" is defined to only include the core and the mantle and not the crust.

Ah, I see. So when it says NaN for a number it is in fact casting it to a string so you can check against the literal "NaN". But why doesn't it complain about comparing a number to a string when sensor!grav() is a real number and not NaN?

Do you mean this part? "Also note that only the first craft to leave Kerbin orbit counts towards any points." It would be a good idea to make it clear that you are allowed to assemble this ship out of pieces and split this ship apart later, so long as it's one ship when it leaves Kerbin orbit. People might not think of an assembled collection as "one craft" and might not realize what you meant.