Dunbaratu

For some unknown reason, the Mac port of KSP does not support the scroll wheel in the VAB, and the only available method is the keypad +/- keys (which suck if you're on a laptop where the keyboard isn't wide enough to have a separate keypad). It's such a minor thing that has to be easy to fix, but it's enough of a hindrance to using the program that it and it alone was enough to make me stop playing it on a mac and switch to windows just for that ONE small thing.

That behavior can happen from the older 0.9 version. Are you using 0.11 or up?

In general I'd like to see some means of identifying in the crash report, exactly which part it's talking about, regardless of whether the crash happened on the launchpad or elsewhere. Telling me that there's a structural failure between a part of type blah and a part of type blah doesn't tell me much when the craft has multiple copies of the same part in it.

That's entirely possible and seems to make sense (that pitch NaN is a symptom, not a cause), because it seems that many of the script's 'Double' variables go haywire and become NaN at exactly the same time. Whatever causes the crash also causes much of the data in memory to corrupt, making it extremely difficult to trace the cause because once the problem happens, anything you try to print out can't be reliably trusted. Any weird numbers could be the result of the crash not the cause of it. And this is true even down inside the C# code. I added a Debug.Log() call to FlyByWire to catch the first moment when it tries to pass any flight control parameter containing NaN, null, or infinity into KSP, and try to trace it down from there, and I'm still having trouble finding the cause. Thus why I suspect that I may have to resort to verbosely logging each and every opcocde as it runs, and hope that the slowdown of doing that doesn't bog the system enough to cause other unrelated breakages that ruin the integrity of the test.

Thrustlimit isn't a global thing. It's a per-engine thing. The only reason it exists is to allow multiple engines to be throttled differently from each other. If you want all engines throttled the same you'd just use the throttle for that. To use it you LIST ENGINES IN someVariable. Then someVariable is a LIST of objects of type ENGINE. You iterate over the items in the list and set some of their :THRUSTLIMIT suffixes to the value you want.

The line causing the error was already mentioned in the post you are replying to. Marionapp responded and explained the problem. It was a thing that was outside the normal typical "this is what you need for a KSP mod" instructions.

I'm convinced *something* broken is happening in the mod in regards to lock values, but I'm still having a hard time tracing it down. It seems to be hard to trace Consider the following case from the ascend script I posted about before. I took this part that prints out some info into the status box once each loop iteration: print " " at (2,1). print stageMsg at (2,1). print " " at (19,1). print modeMsg at (19,1). print " " at (18,3). I narrowed down the place where numbers were suddenly becoming NAN on their own to that part of the loop, and inserted the following debugging print statements into it, which do mess up the nice "print at" display, by scrolling everything down, but that's just temporary while I try to find the bug: print " " at (2,1). print "A) stageMsg = " + stageMsg + " mypitch = "+mypitch. // eraseme print stageMsg at (2,1). print "B) stageMsg = " + stageMsg + " mypitch = "+mypitch. // eraseme print " " at (19,1). print "C) modeMsg = " + modeMsg + " mypitch = "+mypitch. // eraseme print modeMsg at (19,1). print "D) modeMsg = " + modeMsg + " mypitch = "+mypitch. // eraseme print " " at (18,3). When I ran it, I usually get output like this, when it's working right: A) stageMsg = Stage 2 mypitch = 63.2824214170012 stageMsg = Stage 2 mypitch = 63.2824214170012 C) modeMsg = Thrusting myptich = 62.2630527414027 D) modeMsg = Thrusting mypitch = 62.2630527414027 But at the moment when the black screen of death hits, it looks like this: A) stageMsg = Stage 2 mypitch = 63.166334067263 stageMsg = Stage 2 mypitch = 63.166334067263 C) modeMsg = Thrusting mypitch = NaN D) modeMsg = Thrusting mypitch = NaN If you look at the code, there is absolutely nothing between and C) that should do that to the value of mypitch. This is the value that mypitch is locked to: lock mypitch to 90 - ( sqrt( (usevel:mag+(altitude/4)) / (endSpd+(endAlt/4)) ) * 90 ). endAlt and endSpd are set up at the top of the program and never changed after that. usevel is set to surface vel at first, and then switches to orbital vel partway through the launch, because of this way it was set up up at the top before the loop: lock usevel to velocity:surface. when altitude > endAlt/3 then { lock usevel to velocity:orbit. }. The problem happens at an altitude of 6500 m or so, so it can't be switching usevel to orbital at that point (endAlt is 80000 so endAlt/3 is 26666.666) I can't figure out anything that could possibly legitimately change mypitch to NaN in that code, and yet it does. And once it does become NaN then everything breaks because steering is locked to HEADING( mycompass, mypitch ). Is there some sort of timing issue with the way lock expressions are used to fly by wire that might make it possible to try to fly using an incompletely calculated expression? I'm really grasping at straws here because the behavior makes no sense. I'm at wit's end and almost considering trying to add debug info to a fork of the kOS github code that literally logs each and every low level opcode as it runs to figure out exactly what's happening when and where.

I'm trying to debug a problem that I think might be in the kOS mod that I didn't write, so I'm looking through someone else's code and trying to work out a few things, but I'm very very new to mod writing, so I have a basic question about the mod API: It's possible for a mod writer to make "Update" hooks that get called by KSP on a regular fast basis. It's also possible for a mod writer to make "OnFlyByWire" hooks that get called by KSP on a regular basis when KSP wants to ask you mod "tell me how to move the ship controls". My question is this: Are you guaranteed that it's impossible for KSP to call your OnFlyByWire hook in the middle of you executing a call to your Update hook? I see a case in the mod where a rather important variable used in flight control is temporarily in a nulled-out state during a particular small window of time during the execution of the Update hook, but then is set back to a good state by the end of the Update hook. If the OnFlyByWire hook was called in the midst of that, it could try to fly the ship using that temporarily null value, but I'm not sure if that's a problem or not because I don't know when the hooks are actually called. If the calling of all those hooks is single-threaded such that you are guaranteed you'll never get an OnFlyByWire call in the midst of an Update call then this isn't a problem. But if they get triggered independently in separate threads, then this small window of time could be a problem.

Is there documentation for setting up the source code? For example, I ran into this in the code: using ICSharpCode.SharpZipLib.GZip; In Persistence/ProgramFile.cs And had to do some googling to find out what that was and what to install. Is there documentation covering this sort of stuff? (i.e. "If you want to build this project, in addition to the code you get from forking this github project, you will also need this list of stuff......")

Oh for crying out loud. It's obvious from the context of "we're talking about a computer game" that when someone says "random content" that this means "content as random as it is possible to be in a computer program", making the foibles of computerized pseudorandom number generators off limits to the conversation. The pedantry you're resorting to would disqualify *any* PC game from having something you could call random content, since having to resort to a pseudorandom number generator instead of "real" randomness is going to be a feature of any program you run on a PC. As long as we're talking about something that could actually be implemented on the PC, which we are, then random content is a subset of procedural content, because "random content" in that context means "as close to random as you can achieve on a von nuemann machine", and when you use those random numbers in an algorithm to generate content, that's content being generated procedurally. Now stop detracting from the discussion with this. *as the word 'random' is actually used in computer software in practical terms*, squad's refusal to support having procedural planets is what is preventing having randomly placed planets either, which is why i mentioned that as a thing I'd like to change in KSP's direction - which is what the thread is about.

The soviet style of transporting sideways and then standing up onto the pad always made more sense to me. The NASA style necessitates a VERY slow crawling trip to the launchpad at a fraction of a mile an hour, spending all day to make the short trip there, so it doesn't tip over. It seems a very dangerous fragile method and I'm surprised it hasn't gone wrong yet.

Okay I think I'm going to have to install a C# and .NET dev environment. Any good ideas that work without Visual Studio Express? I tried using it before but the 30 day expiration was annoying, and paying for a full dev suite when I really don't plan to use C# for anything else than this seems a bit silly. Even a low level command-line only solution is fine by me. The problem is that something in the kOS code is changing my steering value. *I* am not doing it, and I can't trace down where it's happening. Partway through the liftoff, for no apparent reason, my steering becomes: R(270,NaN,0) When it hadn't been a moment beforehand and none of my own variables that go into calculating it had changed. I expect this is a symptom of, rather than cause of, the problem, because a bunch of my other variables suddenly all become NaN at exactly the same time.

I think you're missing a very important point of this though, which is other graphics card companies being able to compete with nVidia. By leaving the algorithm working out in the open in the public CPU, "the GPU" doesn't have to mean just "nVidia's GPU". It means a competitor graphics card maker can implement a driver to get PhysX code to work well on their own GPU. That would be a lot harder if PhysX had been implemented as "use nVidia or it will suck". Your response was written as if nVidia has no need to consider how a competitor might perform with PhysX because their only competition they will ever have will come from the CPU makers. But making a good well working implementation that is graphics-card agnostic opens up the chance for a competitor graphics card to make their own GPU layer for PhysX for their own hardware. That would have been a lot harder had it been implemented in such a way that once a game programmer uses PhysX that guarantees that only the nVidia GPU would be able to implement it well. Giving it a good CPU-only implementation requires designing it in good GPU-agnositc way that allows the GPU-enabled driver for it to be drop-in replaceable. Which helps any potential competitors in the future and avoids artificial market lock-in. Which is why I'm glad nVidia is doing it this way. They could have decided to behave more like Microsoft typically does, using their current market dominance to try to ensure eternal future market dominance purely through the need for backward compatibility.

Let me try explaining it *again*. It's very simple. (A) Randomized content is a subset of Procedural content. Manually generated content cannot be random. ( SQUAD has said they don't want to do procedural content. © I want randomized content. (D) Because of (A), the reason I can't get © is because of (. There's no need to condescendingly pretend you're "correcting" me when nothing you're saying actually contradicts what I was talking about. I want randomness, which although not synonymous with procedural content, in a Venn diagram it is entirely contained INSIDE the circle for procedural content, so no procedural content also means no random content, thus why I wish squad would change their minds about that. If they allowed procedural generation, then even if they don't use it to make random content, it would open up the ability for a modder to make random content on top of it. The reason they can't at the moment is because the planets are hardcoded. There's no procedure to even modify in the first place.

Hmm.... that *could* be the cause. See, my script waits until the pressure is down below 0.25 ATM's before starting the gravity turn. Therefore when it thinks the air pressure is zero it's going to start that gravity turn right away on liftoff. So that could actually be the relevant difference - not the throttle but the steering commands that come from starting the gravity turn right away. I'll look into that.

Hmm. That is truly weird. I'm able to: lock throttle to inf where inf is a variable that has a value of infinity. And it does not bug out at all. It just behaves as if the throttle is 1.0.

I'm already aware of this. My script used that formula before the capacity to read sensors had been added to kOS. The problem isn't the sensor or lack thereof. It's that something in the other math in my script is breaking KSP when atmosphere density is zero, which is a perfectly legitimate condition to operate under some of the time, like when taking off from the moon, so I need to work out how to make the script work under those conditions (which it used to in the past). When I replace the sensor reading in the expression with a hardcoded zero, the problem still persists. When I replace it with a hardcoded 1. It goes away. It's not the manner in which I'm reading the air density that's the problem. It's what the math does when it's a zero, which it could validly be under a lot of cases. marianoapp thinks it's because of trying to set the throttle to infinity, but I'm not entirely convinced of that because in my testing I've just discovered that I can manually set the throttle to infinity without it triggering the bug: set divByZero to 1/0. print divByZero. Infinity lock throttle to divByZero. When I do that, it doesn't cause KSP to black screen crash like it does when I run the full script, so I'm still trying to narrow it down to the exact cause. Also weirdly, once the black screen happens, it's hard to diagnose the problem because the value of ALL the variables changes to NaNs, which I think is an an effect of, rather than cause of, the crash. Even variables I never touched at all during the loop have suddenly become NaN after that, and some other variables suddenly stop being printable at all because kOS claims they don't even exist. Whatever the black screen crash is doing, it makes it impossible to see what the values of the variables had been right at the moment prior to the crash.

There was nothing intentionally confusing in what I said. Quite the opposite, I was trying to clarify something.

Ah thank you. That explains it. However, I *swear* I remember seeing this script give a terminal velocity of Infinity before, for exactly the reason you cite of there not being a barometer, or because I used it on The Mun where the density is supposed to be zero, and having it display the string "Infinity" for the terminal velocity right there in the little display box my script uses, and that this did not break KSP before in the past. I need to see what exactly it's "passing" to KSP in this case. Having an air density of zero and a terminal velocity of infinity used to be just fine in the script. It just uses these numbers to decide where to set the throttle so as not to exceed terminal velocity, and it uses them to decide how high to start the gravity turn. In the case where it thought the density was zero and the terminal velocity was infinity, that would just mean it would start the gravity turn immediately instead of going straight up for a while, and it would never throttle back to less than 100%. Neither of those two effects used to cause KSP to go black-screen like that. They *did* cause bad piloting when trying to liftoff from Kerbin, but not bugs that broke KSP. (And it was normal and correct behavior when lifting off from a body with no atmosphere, so I repeatedly flew with infinity term vel and zero density and it was fine because this script also took off from places like the Mun.). I'll have to examine exactly what is breaking and see if I can narrow it down. It's got to have something to do with one of those numbers getting passed to KSP in a way that the older versions of kOS didn't. But thank you for taking the time to look at it. Now I can take over the debugging from there.

Have you had calculus? If so there's a really good example of this sort of thing I can use. Imagine that you're trying to graph the derivative of a function. The definition of a derivative is a graph of the rate of change (slope) at each individual point along the original parent function. Now, a lot of the early coursework in a calculus class involves starting from the approximation of the slope, (y2-y1) / (x2-x1), for points 1 and 2 that are very close together, and then working out what the limit of that approximation becomes as the interval gap gets closer and closer to zero. You work out how this functions for basic polynomials, giving the nice rule that for a term Nx^m, the derivative becomes (N*M)x^(m-1). Then you work out how this limit gives an answer for other things, exponential functions, trig functions, and so on. So after a while you've built a nice toolbox for "how do I avoid having to do the ugly limit math each time by instead using one of the previously solved cookie-cutter formulas in my derivative-making toolbox". Then you do the same thing in the opposite direction and build a similar toolbox of integral-making tools using previously solved stock integral formulas. But regardless of the usefulness of those tools, you still have the original definition to fall back on if faced with an ugly function that you don't have the tools for. If you come across something you haven't solved before you can still resort to taking the limit of the change as the delta-X approaches zero for derivatives, or the limit of the sum of the area under the curve by rectangular slices when trying to solve an integral. It's resorting to those types of ugly methods that the phrase "numerical method iteratively" meant. It's a term for what to do when you don't have a nice clean mathematical function for an answer, and instead you have to cut something into finite chunks and sum the finite chunks, for some small enough finite sized chunks that give you a precision you consider acceptable. Another example of the same sort of thing is when you don't know the *exact* function but can approximate it by executing a series for a lot of iterations, like finding the value of pi that way, or calculating the natural log of something that way. A lot of the math of spaceflight ends up being that sort of messy thing, which is why the advent of computers was so important to spaceflight. A computer that can execute iterations quickly can make a numerical method solution into something almost as good as having the actual precise analytical answer.

Depends on your goal - estimate the time it takes to finish a long journey or get an intuitive feel for how fast you're moving past obstacles *at the moment*. For deciding "am I going fast enough to make that jump?" or "will I bounce too much on this lumpy surface?" or "how tightly can I turn the steering without flipping?" meters per second makes a lot more sense because those are all small scale scenarios where what matters is how fast you cover the local ground a few seconds, not how far you'd get in an hour of straight constant travel. If you travel very fast for a minute, and then rest and don't move for 59 more minutes, you have a very slow "per hour" rate of speed when you average it all out. For this type of driving, it's what you were doing during that minute that mattered. Whenever people do engineering calculations on things like how tight a road can be curved, how much stopping distance it takes if it's raining, and the like, they end up having to convert from miles or kilometers per hour down into a more useful per-second scale before they can usefully use the information, and then convert the answer back up into a 'per hour' measure for the communicating to the general public. I'd find it much simpler to just have an educated public so that conversion is unnecessary.

Sort of, and sort of not. I know that every time I write some C code, that the compiler turns that into machine language and runs it that way. But I can debug the C code without having to dig too deeply into the actual low level machine language. There's enough that can be done at the higher level without resorting to that. I'm not yet convinced that this is really a bug in kOS. It could be a bug in my own script. Similarly, debugging kosscript shouldn't have to require diving down into the C# code underneath it, especially if one of the goals of kOS is to make it accessible. Does anyone have good instructions for setting up a mod environment that *isn't* Visual Studio or Visual Studio express?

Is it possible to provide a way for a kosscript writer to output a message to the KSP.log file? The reason I ask is that this latest black screen of death problem is extremely difficult to narrow down where the problem first happens in my code. The reason I can't narrow down the line where it happens is that the program continues executing after the black screen, and therefore if I sprinkle print or log statements throughout the script, they will happily keep on printing long after the problem has hit - making it hard to tell where it actually occurred. On the other hand if I could dump those messages into KSP.log instead, then I could correlate where the messages are telling me I am within my script with where KSP.log starts spewing the other errors that correspond to the black screen of death. If I had that I could narrow down the offending code to at least which line of the script it is.

That's actually one of the hardest tasks, if you have atmosphere. Without atmosphere it's a bit easier to calculate. But you're dealing essentially with one of those cases where the math stops being pretty and starts to become a case of using a numerical method iteratively to calculate an answer. I had originally planned on having that be my next goal to tackle back when Kevin Laity went AWOL and I stopped using kOS for a while. When kOS got resurrected, I've been trying to modify the stuff I already have to work with the new ever-changing system and that still isn't done yet so I haven't gone back to it.

The notion that speed is easier to intuit in units "per hour" than "per second" is pure cultural baggage. It's that way only because vehicles were slower in the olden days, and speed varied by terrain, so to get any accuracy you had to sample the distance traveled over a long period of time and average it out. Today that's not true anymore and the only reason we stick with "per hour" measurements is historical cultural inertia, not because it would naturally be easier to intuit for a person with a blank slate of a mind and no cultural contamination in his thinking. Meters per second is perfectly intuitive. It only doesn't feel that way because we have already spent the effort it takes to learn how to feel speed in units per hour. If the attitude that a practice should be continued long after it doesn't make sense anymore just because it's "intuitive" (when what they really mean is not naturally intuitive, but rather that the effort to learn it has already occurred in the past), then today we'd all be steering our cars using reins rather than a steering wheel.