Dunbaratu

The reason people track every asteroid is that you can't tell which ones have a danger of impacting Kerbin if you don't. While the game allows that to happen without consequence people won't assume that. They'll assume they MUST check for that danger. How about showing the asteroids icon for asteroids that are bound for an impact with a different color, even when they're in the untracked "question mark" state? Then people wouldn't feel obligated to track all of them. They'd just track the dangerous ones. Even if the game allows you to ignore the impact asteroids, players playing a more 'roleplaying' way will still want to pay attention to the ones that are going to impact. And right now the only way to do that is to track them, because you can't tell until then.

It's also impossible to achieve that optimization. The optimal use of the method you're talking about would require dividing the burn into an infinite number of individual burns of duration zero seconds each, which is obviously impossible. So how close to that do you want to get? 60 orbits of 10 second burns each? 30 orbits of 20 second burns each, 10 orbits of 60 seconds each? 1 burn of 5 minutes? It's not just KSP players that refuse to optmize it all the way. EVERYone does because it's not practical to take an infinite number of orbits to accomplish the burn. It's always a trade off between boredom and practicality versus efficiency, even in real space programs. Even the recent probe from India that uses this technique only does it to the extent of using 4 iterations of the method, rather than say 10 or 20 or so.

The Pale Blue Dot I was trying to refer to obliquely was a photo taken from within the solar system. Nothing interstellar about it.

Does there exist the danger, with the current kOS code, that through no fault of the script programmer, KSP decides to RETURN a NaN into a variable, and then this causes kOS to crash the script because it stores that NaN on the stack? i.e. imagine trying to read a value from the game engine, like maneuver node ETA, or current target's distance, and so on, and then KSP gives you a NaN for it, and the script crashes before the player has any control over it?

Yeah it was definitely KSP's fault not MCE. Other ways in which the "landed" flag mattered were also not working. I couldn't time warp or leave the craft, for example.

Perhaps a fan of Carl Sagan decided to sneak some trojan code into the game to occasionally turn your homeworld into a mere blue dot.

Your whole post was predicated upon the idea that "hours" is normal and everything else has to have the effort to convert into it. That makes the argument circular. I was speaking from the idea of what would work better if starting from a clean cultural slate without the contamination of past conventions. For most of the things a rover driver is doing, what matters is what occurs over the next few seconds - how the speed looks *at the moment*, and how the terrain is passing by under your wheels *at the moment*. Using units in which that time span has to be expressed as a small fraction like 1/3600 isn't sensible *except* for the cultural baggage that has trained people to already think of that as normal.

I've been slightly annoyed by this for a long time, but it's not *that* important - just a minor annoyance. I can't control which way the flag orients when I plant it. The Kerbalnaut just turns around and plants the flag in whatever orientation he feels like, regardless of how I've got him facing. And it seems that, inevitably, he picks an east/west orientation aligned with the Sun, so the sun never falls on either face of the flag, leaving the flag dark all the time so you can't see the little logo image I made for it.

I don't understand the concept of zero mass parts and how on earth that doesn't completely break the physics engine, because of: F=ma Wouldn't a massless part be accelerated up to an infinite speed the moment it collides with anything?

A parking orbit is NOT more efficient. It's just a heck of a lot easier to do the math. (I use them a lot in my kOS missions for that reason). Of your three options, #2 is the most efficient (although your figure of 25 degrees is way off. You want the angle between the longitude of the KSC laucnhpad and the longitude of Mun (if you draw a line from Mun down to Kerbin and imagine the logitude where that hits Kerbin) of about 110 to 120 degrees at T zero of your launch. It's hard to be more precise than "110 to 120 degrees" because the exact number depends on your choice of how you pilot your ship into orbit. Usually if you start at 110 to 120 degrees, then you'll be hitting the transfer point at about 90 to 100 degrees, which is the right spot. (EDIT: The boldface bit below is the real reason parking orbits are usually less efficient.) What is more efficient is to act "as if" you were going to do a parking orbit, but instead of that bit where you shut off the engines at an altitude of about 50-60km and coast to apoapsis and then turn them on again to finish circularizing, you just keep burning anyway, raising your apoapsis very high on the other side, stretching it up to the Mun. The result is an elliptical transfer orbit who's periapsis behind you can be low enough to actually dip into Kerbin's atmosphere. That's what makes it more efficient. If you go to a parking orbit first, then you can't get a transfer orbit with a periapsis that low. An orbit with apoapsis at 12 million meters and a peirapsis at 80000 meters takes more energy to achieve than one with an apoapsis of 12 million meters but a periapsis of 50000 ro 70000 meters. Don't aim TOO low because then you're still fighting atmosphere, but your speed at a circular orbit of 60000m is higher than your speed at a circular orbit of about 80000m. By aiming to go from 60000m to the Mun, as opposed to going from 80000m to the Mun, you are aiming to use a higher speed at your transfer point, thus taking advantage of the oberth effect, which is strong enough to more than compensate for the small drag caused by the thin air of 60000m. The reason real space programs use parking orbits is because the loss of efficiency of that versus a direct burn isn't *that* large, but a parking orbit gains you the ability to run tests and diagnostic checks before you pass the point of no return and leave Earth orbit. i.e. For Apollo it allowed time to make sure the craft was set up right and configured properly before pushing on to the moon. Also, it puts you more in control with the precision to decide when to make the burn.

I can't think of a case where it does that. And in fact the new change would make it impossible to do that. It's now impossible for the program stack to even hold a NaN or Infinity in it at all, so it can't feed one to your script anymore (to get it passed into one of the script's variables it would have had to put it on kOS's stack for a moment and then popped it back off again.) More than likely one of your own math expressions is doing it. It's either trying to to trigonometry on invalid input (i.e. what's the arccos of x where abs(x) > 1? It's NaN.), or you're trying to divide a nonzero number by zero (which results in Infinity). The frustration can be that if you have math in a LOCK expression used when flying the ship (i.e. a bit of math called when calculating STEERING or THROTTLE), these calculations can be happening at any random time in your script, so you can't even do something like this: lock throttle to x/maxthrust. // And then later in the code you try to protect against maxthrust being zero and giving an infinity throttle this way: if doStage { stage. if maxthrust = 0 { unlock throttle. }. // turn throttle off until the next stage so it doesn't try to divide by maxthrust of zero. }. In the new design you can't even protect against it that way. It steers and flies constantly "in the background", interrupting your script execution at "random" times (not really random, but at any rate its outside your control) to go fly the ship a moment, then going back to continuing execution of your script where it left off. This sets up a race condition where if this interruption just happens to occur in between your call to "stage." and your call to "unlock throttle", then your script hasn't gotten around to decoupling the throttle from the infinity value you get from dividing by zero, and your script gets killed. Because it's impossible to mark a section of the script as an "atomic section", you are helpless to do anything about this. It's impossible to write script code that can be guaranteed to catch the condition between when it gets set and when it gets used by the fly by wire system. Therefore the only way to catch it is to NEVER, even for one brief instant of time, let it happen. To do something like the above I now have to do it this way: set myMaxThrust to maxthrust. lock throttle to x/myMaxThrust. ... // And then later in the code you try to protect against maxthrust being zero and giving an infinity throttle this way: if doStage { stage. if maxthrust = 0 { set myMaxThrust to 0.01. // Use a very small but not quite zero value, so throttle is big but not infinity. } else { set myMaxThrust to maxthrust. }. I too don't like it, but it's because its less elegant programming to check all your possible error conditions ahead of time before trying something than it is to unconditionally try to do it, but then check for an error condition afterward. In other words this commonly used bit of logic in programs: if (try to open the file) failed then (print error condition here) Is a lot more elegant than this: if (check for filename existing) then if (check for proper permissions) then if (check for disk mounted okay) then ...etc... then (try to open file). It is currently POSSIBLE to stop any NaN or Infinity from happening before it kills your script, but only by checking every case where a calculation could come out that way, ahead of time, before it happens. It's possible, but not very nice. That's actually correct according to how the IEEE specifications for the common floating point representations say NaN numbers are meant to work. You are never meant to be able to do anything at all with NaN other than check "is it NaN?", and that check cannot be performed directly like so: "if num == NAN", because there's more than one way to represent NaN in binary form and such a check would therefore be a mess to implement. Instead all languages in which a program may need to deal with NaN values because the language doesn't mask them off should provide a feature that lets you check with a function or macro call, like so: "if isNan(num)" because then the underlying fact that there's more than one NaN representation can be dealt with by whatever the implementation of that call does.

Uh... what am I supposed to do about this problem? EDIT: I found a workaround. I thought that taking off and landing again might reset the flag properly, and since the pull of gravity on Gilly is so small, I was able to "take off" without rocket engines by simply tilting back and forth to bounce the wheels against the ground. I rose up about 6 meters, and then fell back to the ground and got the landed status to show up.

No. It would have been possible before by adding a very simple "isNaN()" function to kOS that just is a wrapper around the C# isNaN call underneath. But not anymore. A change was made that I'm not happy with but I reluctantly accept, that now does make it literally impossible for you to catch the problem in your script no matter what additional support gets implemented in kOS. That change is that the moment any value becomes NaN or Infinity, even just temporarily during calculations of an expression, then kOS deliberately kills your script right there immediately. This is when you see the error message that says "tried to push ____ onto the stack". (where ____ is 'NaN' or 'Infinity'). Because of this change it would be pointless now to implement an isNaN check because by the time you get to the point where your script can run that check, kOS has already killed your script. This change was made to make it impossible for the mod to ever pass a value of NaN or Infinity into any of KSP's API calls regardless of what the kOS script does, because now the kOS script cannot even "store" a value of NaN or Infinity in any value anywhere. KSP's API doesn't protect itself from callers giving it bogus data so KSP can crash when it gets a value like that. I'm a bit unhappy about the solution, but I can understand that it's the simplest quickest way to implement it. I think the slightly more complex solution of passing arguments through a sanity check *only at* the moments they go into a KSP API method would have been nicer, but admit that it's a more time consuming solution to write.

Perhaps to handle the fact that asteroid impacts generate outside of MCE's influence there should be a repeatable, non-contract, asteroid capture mission, so you're never in a position of having an asteroid available to capture but having to lose money in order to go get it because there's no mission for it.

Yeah this is definitely easier than I thought it would be. The class already has everything I need for this. Technically it should be called coneRenderer, because it makes cylinders and cones where I specify the width, not just lines, and it also makes the object a thing that can be shifted and moved after placement by moving vertices - so it's got everything I need for this. Thanks for the advice, both of you.

Also, UNLOCK does work with specific named variables. It's just the "ALL" that's not working. UNLOCK THROTTLE and UNLOCK STEERING work.

I don't think any of the changes refer to un-implemented stuff yet so.. yeah go ahead.

Is it possible to tweak the probability of an ARM contract appearing based on whether or not there's a collision asteroid already coming? The reason I asked my earlier question is that my game had spawned an impact-bound asteroid on its own, and if I went to take care of it I was bleeding money doing so because a contract hadn't spawned to match up to it.

I agree in principle, but not with that specific example. That can be a dangerous check that fails to stop the burn. It has two problems: 1: If X is too small, you can blow past X faster than the script responds and then when periapsis and apoapsis swap positions continued burning won't make the gap smaller, but larger. 2: If It takes too long to execute the burn so that you aren't precise enough in executing it centered on apoapsis, then its possible to never get apoapsis and periapsis within X, and yet its still time to stop burning because continued burning won't make it any better. The check I prefer is to stop the burn when you've rotated periapsis to within 90 degrees of your current position - to stop the burn as the apoapsis and periapsis are starting to swap positions and you're halfway between then. To see how to calculate that, google the phrase "True Anomaly".

Are there any missions designed for asteroid capture? At the moment if I want to capture an asteroid I have to disable MCE first so I don't lose money on it.

Thank you. That example is being most constructive to me.

Does it have the "ELSE"? It looks from the branch history like it would, but it's not mentioned in the release report.

I've just started helping out in small bits contributing code to the kOS mod ( http://forum.kerbalspaceprogram.com/threads/68089-0-23-kOS-Scriptable-Autopilot-System-v0-11-2-13/ ), and I've come across an idea that would be very handy to help me (and maybe others) to debug problems in their kOS scripts. Before I consider it, I'd like to ask if what I outline below is feasible and easy to do: Some math problems in kOS involve doing a bit of vector math. But the XYZ axes in KSP can be hard to visualize and most players are playing "blind" as to what those axes are, and therefore have a hard time trying to work out what way a vector is actually pointing, given it's definition. If you see that a vector contains the following parts: x=103.1 y=2.10 z=912.12 Most players have no clue which way that's pointing in the space you're viewing at in the game. What I'm wondering is this: is there a good way via the Unity engine or KSP API to make a holographic representation of the vectors in the 3D space view so a player can look at them, but they have zero effect on anything in the game and as far as KSP cares they may as well not be there? I'm picturing drawing a vector as a type of very narrow cylinder with a "hat" on the tip end, so it looks vaguely like this mockup: These would be 3D objects (you could spin the camera around to get a better view of them) that the ship can just pass straight through with no effect (like the scatter rocks on the Mun). If someone can guide me to what would be the needed API calls to put such an object into space (and then remove it later) that would be awesome. I've got experience with graphics and programming, but not specifically with the implementation of them that uses Unity, or KSP, or C#.

Yes. Even flying manually I never get it all the way to zero. It seems to get down close to zero and then start going back up again. I suspect this is because the aim would have to be 100% accurate for it to get to zero. It's probably calculating the difference between your current velocity and the intended end velocity, and I say "velocity" rather than "speed" quite deliberately here because I mean the vector, not the scalar. The direction matters not just the magnitude. So let's say for example that you set up a maneuver node that was meant to achieve a delta-V of 100 m/s in a particular direction, but you were burning 2 degrees off from the planned direction. Then after adding 100 m/s of delta-V you still aren't at the intended velocity. You're 2 degrees off from the intended velocity. Your maneuver node at this point would tell you that your current velocity is still 100*sin(2 deg) away from the intended velocity, or 3.49 m/s. But that's the closest it gets as your velocity passes just missing the intended mark and starts going farther past it. The only way to get it to exactly 0 is for the aim to be literally exact and perfect, which is utterly impossible due to floating point math precision anyway, not to mention that the steering algorithm will have a little bit of wobble in it. It will just get near zero without reaching it. Suggested fix: In a loop continually compare the node's current delta V magnitude to the node's delta-V magnitude that you had on the previous loop iteration. This will let you detect if it's getting smaller (current is less than previous). Instead of burning until delta-V magnitude is zero, burn until the delta-V magnitude starts getting larger instead of getting smaller.

I am in fact saying that. The 1 atom per cubic meter near-vacuum of space contains atoms that have gotten there from other planets. They get mixed together.