Dunbaratu

If you update this, here is one reminder: The old problem with being unable to save the game and come back without explicitly zeroing lots of variables individually by name is now gone. I performed several tests about this and the new kOS no longer seems to have that bug that caused KSP to truncate vessel loading. So that aspect of the rules can be trimmed down and made sensible, as the bug no longer is an issue.

Look at the entries to this challenge thread: http://forum.kerbalspaceprogram.com/threads/58068-kOS-The-Automated-Mission-Challenge/ They were made using older versions of kOS. If anything the stuff they do is a lot easier now in 0.11.

Ah. Well then that is a problem. It's always possible to obtain any vector direction from just two rotations, so I guess that's how kOS is calculating the facing - it's probably deconstructing your vector direction into "what possible set of rotations would give me this direction" and solving for whichever one of the infinite number of rotation combinations that would give you that vector direction happens to be the one achieved by using a roll of 0. (In other words it's only paying attention to which way you're pointing, not how you are rolled around that axis.)

I didn't say impossible. I said impossible *without changing KSP itself*. The limitation that's causing the current impossibility is coming from the core game explicitly denying attempts to do it. Although when you mention KMP, it does occur to me that while KSP cannot do this, multiple instances of KSP, all attached to a KMP server, might be able to if you run a seperate instance of KSP for each 2.5km radius zone that you want to run code in, and have them all report their changes to a KMP server. But that would still technically mean KSP isn't doing it. (KMP is). It may be possible after KSP implements their own multiplayer, but then like I said that would be a case of changing KSP itself. And I never said it was impossible - I said it was impossible *without changing KSP*. In other words, Jebnix on its own would be powerless to do it.

Does anyone know if there is such a thing as "subtracting" a Euler rotation in kOS? Presumably if you want to know your current up-relative facing (the a,b,c in "up + R(a,b,c)") you could do it by getting your FACING and then...subtracting "up" from it? Would "facing - up" give you a rotation with the right starting frame of reference to be used in up + R(a,b,c) ?

You appear to be operating under the assumption that I used that window to pick one of the two revert flight options. I didn't. I picked the one that doesn't revert the save: "Space Center". I can't get to it. The crash menu IS the only menu at that point. It has both the revert and non-revert options on it.

Money payout doesn't happen if you exit the dialog boxes in the wrong order. Take on a mission in which there's a CrashGoal. Fly it to the end, and perform the crash. When you do the crash, the mission payout window appears where you can click the button to get your payout. But *also* at the same time KSP makes the crash diagnostic window appear, with the debug log, and options to revert the flight or go to space center or tracking station. If you answer KSP's stock crash window first, going back to the space center, and THEN while on the space center screen try to answer the mission payout window (which is still there waiting to be clicked on) then the window goes away as expected, but you don't get the payout. It seems that to get the payout you must click the payout window *before* you click the crash report window. In other words once you leave the "vessel" and go back the space center, you can't get the payout anymore. At least that's what I noticed when I tried it.

My thought is that I'd love to have it, but that's combined unfortunately with the belief that it's completely and utterly impossible for a mod to do that because the base KSP game makes it impossible to alter the course of objects that have been put on rails, and furthermore it's actually impossible for the parts the vessel is made of to even "exist" so to speak. I have no idea what the internals of Jebnix do, but if it's anything along the lines of "for each computer part that exists on a vessel somewhere, execute some of its program right now." then there's no way this could be implemented because the computer part wouldn't even exist in the physics engine for KSP at all when the vessel is on rails. That would mean that even if you're talking about doing something with the computer program that isn't going to change the craft's path, you still can't execute code on the computer part because the computer part itself isn't even loaded into KSP's list of "all the parts that exist right now" data structure. On the other hand, one thing that would be handy would be a hook between Kerbal Alarm Clock and Jebnix that would allow a Jebnix program to set/remove alarms in Kerbal Alarm Clock. It would be nice to have something where a program could, say, calculate the right moment for a Hohmann transfer burn, set the manuever node for it, and also make Kerbal Alarm clock set an alarm a few minutes before the burn.

I was curious about what was wrong all this time. So I looked at the commit. As near as I can tell kOS creates a temporary execution context for a single iteration of a loop, and then when it gets to the end of the loop it marks it as "done" and makes a new one for the next iteration. At each time slice kOS goes through all execution contexts in its master superloop and sees if they have any statements queued up that need executing. Ones that are marked as "done" don't need anything executed. As far as I can tell, the error was that it was merely marking the old iterations' execution contexts as "done" when it should have been fully deleting them. So by the time you were on iteration 2000 of a loop for example, you'd have 1 execution context that actually needed work done (the current iteration of the loop), but it was buried among the other older 1999 "done" execution contexts from previous iterations. The superloop's time was wasted iterating over them to see if they needed work done. (They didn't, but they still occupied execution time checking each one in turn to find out that it's in "done" status.) Thus why loops got more laggy the more previous iterations they've been through.

This is one of those topics which sounds a lot more profound than it really is because it boils down to really just asking "what is the definition of this word that has always had two things conflated together in it? Which of those two things is the actual definition and which is the consequential effect of that definition without being part of it?" The word is "universe" and the two conflated meanings are "Everything existent" and "All the contents of all space that originated in the Big Bang." As long as we believe there exists nothing other than that which came from the big bang, the two different meanings are equivalent. The fact that they are equivalent causes us to forget which one is the actual definition, and since words are defined by common usage, if we forget which is the actual definition then that means we forget what the word really means. We don't even know which of the two meanings our own ancestors coined the term for. Once you start talking about the potential for there to exist things outside of that which we traditionally called "universe" it immediately raises the question - "wait a sec - which of those two definitions is the definition? In other words, if we were to discover something outside the matter and energy from the big bang, which of the following two errors would that mean we had made in the past: 1 - We were right to define "the universe" as "all that exists", but then that means we were we wrong to call the stuff coming from the big bang "the universe"? 2- We were right to define "the universe" as all the stuff coming from the big bang, but that means we were wrong to call the universe "all that exists". When it comes down to it, you've got to first decide what the word "universe" actually even means first. And if you go with the definition "everything that exists" then the phrase "outside the universe" cannot by definition mean anything. (And then it would probably mean we need a new word for "the stuff that came from the big bang - the galaxies, stars, and planets" because we couldn't keep using the same word for both without causing undue confusion if it turns out there exists stuff outside the stuff that we used to think was all the stuff there is.).

This! When NASA astronauts in the 60's and 70's had to do manual dockings, they did them with *analog* control sticks. We're trying to do them with a digital boolean controller called a "keyboard". I often find even with the capslock on which is meant to cut back on the strength of the keyboard controls it's still hard when docking to get precise control because there's no such thing as "press the key 1/4 as hard". to get a smaller effect. Just the fastest 'tap' on the key that I'm physically capable of is often more than I wanted, leading to the annoying act of dancing back and forth across the point I'm trying to stop on in the navball because the lightest possible tap on the key causes too much rotation. It's things like that that cause a need for docking to be a bit unrealistically forgiving. Making it more realistic would first require giving the player more fine-tuned control over the controls.

No. The toolbar icon is present. The problem is that clicking the little icon of the rocket, which SHOULD make the current mission window appear, doesn't - at least not while you're on the SPH screen. Once you leave the SPH screen and get to the KSC view, then the current mission window is suddenly there. Both this error and the error with the ship cost window seemed to start happening at the same time, although they don't both manifest at the same time they both seem related. And again, the problem only ever happens in the SPH. This is dev build 6. I had once clicked on the "upgrade toolbar" button by mistake but I immediately quit from the browser webpage that it brought up, without downloading the file. I didn't go through with it. Might the act of clicking the button caused Toolbar to somehow throw some part of itself away, expecting it to be replaced by the download that never came?

Here's the whole log on pastebin: http://pastebin.com/B4TtFeQx it does have one of those sections you mentioned in it: NullReferenceException: Object reference not set to an instance of an object at MissionController.MissionController.OnGUI () [0x00000] in <filename unknown>:0 (Filename: Line: -1) ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint Aborting at UnityEngine.GUILayoutGroup.GetNext () [0x00000] in <filename unknown>:0 at UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type LayoutType) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUILayoutOption[] options) [0x00000] in <filename unknown>:0 at MissionController.MissionController.drawbudgetwindow (Int32 id) [0x00000] in <filename unknown>:0 at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) [0x00000] in <filename unknown>:0 at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) [0x00000] in <filename unknown>:0 (Filename: Line: -1)

The size of planets are scaled down from what they are in our solar system, but the laws of physics are NOT scaled down. They're the same. So basically, in order for surface gravity on Kerbin to match that of Earth, Kerbin had to be made a very dense planet to give it a similar mass to Earth despite being smaller in radius. That *had* to be done precisely because KSP *is* using the same universal constants for its laws of physics as the real universe uses. The gravitational constant G is the same, and therefore a smaller planet than Earth has to be denser than Earth to get the same gravity as Earth. Similarly, if it did bother to calculate the speed of light (it doesn't. Newtonian physics works at any speed in KSP) then it would use the same 'c' the real universe uses.

I spoke too soon. Using the reset windows button in the SPH causes a secondary problem - it makes the Mission selection window never appear until after you leave the SPH. (i.e. I hit the button to toggle the mission selection window, again and again, nothing happens. I hit the 'hide all mission control windows' button to make sure that's not the problem, then toggle the mission selection window again. it simply won't appear. Then I leave the SPH to go to the VAB, and as soon as I leave the SPH there's the mission selection window. It's visibility was suppressed only while on the SPH screen. A dump of the KSP_Data/outputlog.txt file you were talking about is too long to put in the post. Can you tell me which part of it you're interested in so I can trim it down to something the forum software will allow me to post? I should add that behavior everywhere else seems fine. The problem seem to be limited to just the SPH screen.

Only SPH. And the reset button seems to have worked (I didn't know it existed before).

How do I fix this? For some odd reason, the window displaying the cost of the current craft became large and I can't resize it and can't make it go away. I tried deleting config.xml which contains window positions in it, but when it creates a new one from scratch, it comes back with the same bad window size again.

I suspect that it would first require a change to KSP itself to support this. What might work however would be access to the engine's tweakables, where the thrust output can be capped. You could make a sort of makeshift separate throttle that way by setting the throttle to max and then using the engine caps as your throttle.

My ascent script calculates air pressure from known information about the planetary body and the current altitude. I think I'll switch it to actually looking for a barometer instrument on the vessel and reading it directly from that. Seems more appropriate.

Good news. I just tested two of my scripts that used to exhibit the most lag stutter - the ascent and descent scripts - and in 0.11 there didn't seem to be any stutter with them anymore. The ascent script rose all the way up using the enormous 487-part ship without any of the previous freeze-frame behavior. The descent script brought me down to a smooth landing on the Mun (I didn't send it all the way to Duna this time as I wanted to hurry up and perform the test) without any animation pauses. I have no idea what changed but I know eerandrake was fiddling with some parsing internals and I sort of suspected that it might have been the parsing behavior that was responsible in the past - something "leaking worse and worse" the more and more times it re-parsed the loop. But at any rate, one of the things you changed, eerandrake, whether intentionally for this problem or not, it seems to have reduced or perhaps even eliminated the problem now (crossed fingers).

I'm trying the new 0.11 dev build with my old Duna mission. One change I came across right away is that the built-in variable "body" used to be a string - it was the name of the current body. Now it's the the Body structure of your current body. (i.e. to get the old behavior I could go through my scripts and change all occurrences of "body" to "body:name".) Was this change intentional or accidental? If it's intentional I'll go through and change the scripts. I think the new way actually makes more sense and is more self-consistent and therefore worth breaking backward compatibility for, but I'm just checking for whether it was intentional before I go and change all my scripts.

yeah sorry I did.

The author has moved on to making a new from-scratch drop-in replacement for kOS (that could also support other languages) called Jebnix. It's not ready yet, and looks like an ambitious project.

There is no random number generator function in kOS (yet?). If you make your own with the divide/remainder technique, you need to know that the numbers in kOS are NOT integers. They're always 64-bit floating point numbers in IEEE754 format (1 bit for sign, 11 bits for exponent, 52 bits for mantissa-after-the-1.) . That affects what sort of pseudorandom generator to use. (It always feels a bit odd to me that I'm using Doubles as loop counters and now List indeces. It just feels *wrong* to an old programmer, but I understand the decision to make all numbers Doubles - it does make everything simpler to understand for new people.)

Minor documentation bug: The links in the new documentation that point at the supposed full description of how to use Lists are pointing to 404 Not Found. Either the link is typed wrong or the page was never uploaded or something.