Dunbaratu

Exactly. There's loose hydrogen atoms in space (about 1 atom per cubic meter, if I recall). So how many hydrogen atoms per cubic meter are needed before you assume those atoms are part of the atmosphere? 2? 3? 100? 1000000? There is no hard and fast line that can be called the *start* of outer space.

Might there be a way to "earmark" science points that only work for one particular part of the tech tree? Then you could give them out for doing missions related to that thing - i.e. do a docking mission and get points dedicated to the tech tree path that leads to better docking rings and rcs thrusters and so on. I imagine an implementation like this: You define a few "lines" through the tech tree and give them names like "docking path" and "efficiency path" and "instruments path" and so on. Each line is a fixed list defined in the mod: a list of nodes that forms one particular line path from the root of the tree out to one of the leaves of the tree, hitting some tech nodes that relate to a particular type of tech along the way, like the names suggest. Then you track separate totals of MCE science voucher points - one such number for each path defined above, as in "you have 120 points of 'docking path' points, and 50 points of 'instruments path' points right now". These points are given out as rewards for MCE mission completions in lieu of the current practice of sometimes giving out KSP's generic raw science points. How do you use them? Well, KSP itself doesn't know about them, but what you do is that when a player is going to buy a new tech tree node in the science center interface, you check to see if that node is on one of the paths described above, and if the player has any MCE science voucher points for that path. If so, then you discount their purchase of that tech tree node by the amount of voucher points (or add the voucher points back in to their science points after the purchase if you can't quite force what I'm talking about through the KSP API). Thus you've invented a sort of dedicated science point system that melts in with KSP's own generic science points system. Players still get normal KSP science points from normal KSP science things, but then get MCE science voucher points as well that are more dedicated and specific. By applying each dedicated type of voucher point to a PATH through the tree rather than to one specific node of the tree, you're ensuring that the points will be usable on whatever the next purchase along that path happens to be. The voucher points would only become useless when you hit the end of that path at the leaf node. At any stage prior to that they'd still be usable.

Perhaps it should be made with an optional goal for a bonus. Define a square area with lattitude/longitude that covers the entire crater, and make that be the minimum goal, then add a more narrowly defined square inside it that covers just the island and make that be the bonus goal.

At no point wast the Dark Knight pretending in any way to be realistic. Gravity was pretending to be. That's the big difference you're missing.

The atmosphere never disappears. It approaches zero density asymptotically on an exponential decay function. The idea of a hard dividing line where "space" begins always seemed to me to be utterly arbitrary and made up. It's basically asking "what's the fraction closest to zero, meaning there's no way to make a fraction that's even closer to zero than it is?" And of course, for any non-infinite N, you can always get closer than 1/N by taking 1/(N+1), so there is no such number.

True, but the reason it looks like that is that I didn't know at first what the internal starting point of the rotation was and I had to determine it experimentally by tweaking the script again and again until it worked. Until I knew which way around it was it was easier to leave the entire transformation matrix populated fully even for the zero terms, otherwise I'd have to re-type it every time I tried a different starting point (because that causes different terms to zero out.)

Cpt Kipard: If you really do want to use the timed burn style, then you need to force the ramp-up and ramp-down times to be predictable so you can calculate the triangular parts of your graph. What matters isn't that it has to be super fast, but that it has to be KNOWN so you can perform your calculations. Here's an idea of how to ramp it up predictably. Let's say that you've decided upon a 2 second ramp-up time and a 2-second ramp down time, and doing the calculation that way you've come to the conclusion that with those timings you'd need a burn that looks like this: Ramp up from 0.0 to 1.0 in 2 seconds. Then burn steady at 1.0 for 10 seconds. Then ramp down from 1.0 to 0.0 in 2 seconds. (I'm leaving it to you to work out the math for how to decide that that's the burn you need, but lets say for the sake of the example that you've already determined that those are the timings you want) You could implement that like so: This would mean that you want a slope at the beginning of the graph of 1/2 (2 seconds to get from 0.0 to 1.0)., and at the end of the graph a slope of -1/2 (2 seconds to get from 1.0 to 0.0). You can make a triangular graph that does that with this formula: 1: throttle = 3.5 - abs( (t-7)/2 ) (Note the number 7 is derived from "it's half of 14", which is the total duration of the ramp up, steady burn, and ramp down parts of the graph (2+10+2).) (Note the number 3.5 is derived from "it's the midpoint time, multiplied by the slope: 7*(1/2)". That makes it be the max height of the triangle.) (and the divide by 2 is because you want a slope of 1/2 in this example). Then the middle steady part of the burn is described by this formula: 2: throttle = 1.0 [ a constant ] Graphing the two of them you get this: (the brown line is formula 1, and the blue line is formula 2). If you take the minimum of those two, you get this graph: 3: throttle = min( 1.0, 3.5 - abs( (t-7)/2 ) ) That's the graph you want the burn to do. This is the code that would accomplish that burn: set rampSlope to 0.5. // Assume this is fixed no matter what. // I leave it as an exercise for you to work out how you'd come up with this next number, given // the rampSlope. set steadyTime to 10.0. // Total time, 14 in this case: set tTotal to 2/rampSlope + steadyTime. set tHalf to tTotal/2. set triangleTop to tHalf * rampSlope. set tZero to time:seconds. // Now, the entire throttle burn envelope can be controlled with this one expression: lock throttle to max( 0, max( 1, triangleTop - abs( (t-tHalf )*rampSlope ) ) ). The max(0, ….) part is there so that when the expression goes negative, the throttle stays at zero.

Would you object if it was adapted so that it does work regardless of whether it was internally made with a vector or not? Because the meaning of the R(..,..,..) format you get from the built-in rotations IS in fact to assume the starting direction (pitch, yaw, and roll all being zero) prior to any of the rotations is the Z axis. So you can always treat it like it was crated from the unit vector V(0,0,1). All rotations in fact start from the presumption that you began with a known initial direction, otherwise they don't mean anything. "I'm steering in a direction that is 20 degrees to the left". "uh… 20 degrees to the left of WHAT?" Without a well defined meaning of that "WHAT", you can't steer toward that direction because it's not defined what it is. Experimentally, I found out that in kOS, the "WHAT" is always the Z axis. In other words, I don't understand how kOS can make use of a Rotation like R(… ,…., …) to steer by if there exist rotations that don't have a default presumed starting direction.

That reminds me of something that always bothered me a bit in the back of my mind about the Kerbin Crater mission. It claims that the purpose of the mission is to explore Kerbin's impact crater (which I assume is that ring of land around a central island just offshore of the west coast of the big continent). BUT, the goals for the mission never mention longitude at all. It only has a latitude goal, so you never need to go anywhere near the crater. Just go 8 degrees straight north from the KSC launchpad and land and you've succeeded. But it has a better payout than the polar mission, which makes you have to go further and is slightly harder. Would it make more sense to add a longitude goal to that mission so you really do in fact have to get near that crater?

The biggest problem you're going to run into with any attempt to calculate this is that you literally cannot detect the duration of time that your sloped sections of the graph take. Nothing you query from kOS will tell you "this is where the real throttle is at the moment, rather than the throttle setting it's seeking toward." So you can't tell how long it took to get from zero to 100% from inside the code. The instant you set the throttle to 1, kOS will *claim* it really is at 1 right away when you query it, whether it really has gotten there yet or not. Here's how I usually deal with it: I don't do what you're trying to do. Predicting the burn time ahead of time and then unconditionally telling it to burn for that long seems a very fragile algorithm to follow given that the numbers in KSP aren't 100% accurate. Instead I look for a way to query the expected ending condition (burn until WHAT is true? Until the orbit is circular? Until the encounter is at its minimum periapsis?, etc.), and then I make that check be the thing that actually causes the burn to end, utterly ignoring the predicted burn time. I only use the predicted burn time for some fuzzy heuristics, never for a thing I have to "trust" it for. Also, I usually come up with a way for that end-condition check to "notice" when the condition is getting near but not there yet, so I can slow the throttle down gently and therefore not overshoot the end condition. For example, when circularizing the orbit, I start slowing the throttle down as the eccentricity gets closer to 0.0, and then cut the throttle off when the craft gets closer to periapsis than apoapsis altitude (meaning the craft has rotated them around to the point where there's no point in burning any further from the current location). A number of uses so far, where I used my longhand version of it, that I can now go through and replace with the shorter version. The mod gives you "north" and "up", but only in the form of Directions, not in the form of vectors. If I had them in the form of vectors then I can get my own axes rotated relative to the surface, and thus make calculations in that surface-relative coordinate system that's so much better to deal with for the last steps of landing. So I used that code to get the "up" unit vector from the "up" R() rotation, and the "north" unit vector from the "north" R() rotation. Once I had those two then I could get the east vector by taking the cross product of the north and up vectors. (And I used to have to do the cross product in longhand too, but that now has a function VCRS(A, for it.) Another place where having it is handy is in transforming the direction to a target into a vector to the target that can be multiplied, scaled, and combined with other vectors to help in writing docking scripts (which I'm just starting now but first I'm looking at some problems in the actual mod code).

This is such a useful thing I just found buried in the github code, and it was in the documentation but it sneaked past me without a major announcement and I didn't see it. set dir to Up + R(20,0,0). set unitV to dir:vector. That suffix ":vector" is what I'm talking about. It converts the direction into a unit vector pointing in that direction. To see how happy I am to find out that this exists, remember that this is the kosscript code I had to use when I had to build the rotation matrix manually without the help of the Unity engine's matrix operations: declare parameter tfDir. // Rotation angles for rotation matrix: set tfA to tfDir:yaw. set tfCosA to cos(tfA). set tfSinA to sin(tfA). set tfB to tfDir:pitch. set tfCosB to cos(tfB). set tfSinB to sin(tfB). set tfC to tfDir:roll. set tfCosC to cos(tfC). set tfSinC to sin(tfC). set tf11 to tfCosA*tfCosC + tfSinA*tfSinB*tfSinC . set tf21 to tfCosC*tfSinA*tfSinB - tfCosA*tfSinC . set tf31 to tfCosB*tfSinA . set tf12 to tfCosB*tfSinC . set tf22 to tfCosB*tfCosC . set tf32 to 0-tfSinB . set tf13 to tfCosA*tfSinB*tfSinC - tfCosC*tfSinA . set tf23 to tfSinA*tfSinC + tfCosA*tfCosC*tfSinB . set tf33 to tfCosA*tfCosB . set tfV to V( 0,0,1 ). set tfUnit to V( tf11*tfV:x + tf21*tfV:y + tf31*tfV:z , tf12*tfV:x + tf22*tfV:y + tf32*tfV:z , tf13*tfV:x + tf23*tfV:y + tf33*tfV:z ) . THAT, is now replaced with this one line: set tfUnit to tfDir:vector. Normally in most cases I dislike when the kOS mod does all the work for you, but in this case I like it because it doesn't feel like "cheating" when real navigation computers would have the ability to perform vector rotations with a transformation matrix as a very low level operation buried down in the hardware. Even the Apollo computer had that. (sort of. It ran on a very RISC set of only about 12 instruction opcodes, which then had a set of middleware instructions layered on top of them to preset a virtual machine language to the rest of the system that had more than those 12 opcodes. The matrix and vector operations were in that middleware pseudo-ML layer.)

This is better: print "altitude: " + round(altitude,0) + " " at (0,2). The reason for rounding is that altitude is a floating point number and you could get a display like 1234.5667781. The reason for adding [ + " " ] after the altitude is to handle the case where the altitude might become small enough to lose a digit. You want to wipe out the characters after the altitude so that if you go from this: altitude: 10000 to this: altitude: 9999 The extra "0" leftover from the '10000' gets wiped out. Otherwise you'll end up with the "9999" looking like this: altitude: 99990

I had the exact opposite experience. [ heading x by y ] was deprecated and I had to change to [ heading(x,y) ].

Actually the big difference is this: A washing machine has an axle. A spinning space ring (presumably) doesn't. The presence of an axle mechanism, in which only a portion of the machine spins, and another portion of the machine is stationary, and there needs to be some attachment point at the pivot point of that rotation, causes a *forced* pivot point. The washing machine cannot spin around the center of mass if the center of mass isn't on that predefined axis, thus the washing machine gets wobbly. The fact that the clothes stick to the walls isn't the cause of the imbalance. The fact that the axis is forced to be where it is regardless of how the mass it distributed is. By the time a washing machine is spinning at high speed (rather than agitating back and forth), it has drained out all the free-standing water and the only water left is that which is sponged into the clothes, the spin being there to press the water out through the holes in the walls. Are you sure it would balance if the holes were stoppered up, the clothes were removed, and the normal control mechanism was 'hotwired' and bypassed to just make the machine spin with only some water (say, 1/4 full) in it? I think in that case the problem of the unstable equilibrium causing the water to eventually migrate over to one side causing unbalance would still happen in that case. Because the relevant reason the washing machine can develop wobble while the space station can't isn't because it has solid stuck to the walls instead of liquid in it, but because the washing machine has machinery that is preventing the axis of rotation from moving offcenter. The axis of rotation is being forced to remain in the geometric center of the washing machine's cylinder even when that's not where the center of mass is. The space station doesn't have such a mechanism forcing that to happen, and is free to rotate about whatever axis line it naturally happens to rotate around, and THAT is the reason that a washing machine can develop unstable wobble where a space station can't. An axle mechanism disallows the spinning part from spinning around an offcenter point.

Thanks - I got the advice to make it work now. It's not just that it has to be a second branch, but that it can't be a branch off of my previous change. It has to be a branch from the original fork point prior to my previous change, otherwise the two changes can't be treated as different independently pull-able changes.

Try it abbreviating "atmosphere" to just "atm". That may be the problem.

I've noticed that using the raw controls, it's possible to rotate the craft in an impossibly fast way that you'd never be able to do if rotating by manual control: For example, I did this: set ship:control:pitch to 20.0. and the airplane suddenly starting spinning mega-fast and flung itself apart from centrifugal force, a lot faster than would be physically possible from pressing "S". It occurs to me that this could be a "cheat" to allow craft with very poor rotational performance to still rotate fast anyway by just picking control numbers larger than 1.0.

This is a question about Github, but it relates to KSP mods because it's for a KSP mod project I'm trying to contribute some changes to. I asked this question on some github forums but I'm not getting answers and I'm still lost. The situation: For the first issue: I am not the project owner but am trying to contribute small changes to the project. I made my own github fork of the project, then fetched that to a local copy on my own computer, made my changes there, committed them, and pushe them back to my own github fork, and made the pull request for it. This worked fine. The author said it may be a few days before that pull request gets merged in with the main project. So I also tried to fix a second issue. I made the code changes in my local copy to perform those changes and tested them locally and it all looks good. But now when I try to commit and push those changes back to my github fork, they keep getting assigned to my previous pull request. How do I stop my future commits from being applied to that previous pull request (that's still pending) and instead apply them to a second pull request meant to be applied after my previous pull request?

Is there a way to only lock some but not all the controls using the SHIP:CONTROL technique? At the moment if I wanted to, for example, make an altitude-controlling autopilot, it also locks out all other controls the moment I use ship:control:pitch. Once the computer controls pitch, it also freezes roll, yaw, throttle, etc.

Who is the author of the mission pack called "BSP Kerbin SOI" that the mod ships with? One thing about that mission pack that's bothered me for a while is that the mission called Katurn III requires a Clamp-o-tron Jr docking port, loooong before there's any chance of having unlocked that part in the tech tree. It's an early mission in the days when you're still doing missions for $60,000, and the clamp-o-tron jr is very high up the tech tree. So basically when I hit that mission I have to stop and switch to a different set of missions. By the time I can do it later, I no longer care about $60,000 missions anymore because I'm already going to other planets.

I used to do something similar but then ran into a lot of trouble trying to make it generic for all rocket designs. The problem was that it was normal for there to be some fluctuations in the calculations of fuel loss rate because part of the calculation involved dividing a very small number by another very small number to get a rather normal medium-sized number, which is a calculation that can get rather chaotic, exaggerating small errors in precision into big ones. So I had to have quite a bit of tolerance in the fuel loss rate, and only stage if the change in fuel loss was big enough not to be the result of minor precision errors. That made it really messy to try to make the script work for any rocket, big or small or complex or simple, because the window was vary narrow between setting the tolerance too low so it stages when it shouldn't, versus setting it too high so it fails to stage when it should. Just directly detecting the flameout is much cleaner now that it's possible.

Oh yeah I know I could hardcode it for Kerbin like that. I was hoping for a generic works-anywhere solution. The altitude where it happens is different for each body.

Filename: "stager.txt" //KOS // A program that will detect if there's a need to stage right now. // Takes no arguments, but "returns" these two global variables: // // stageStatus: An integer with the following meaning: // 0 = Staging did not occur. // 1 = Staged because the current stage has no fuel. // 2 = Staged because of a flameout (Good for asparagus or solid boosters on the side). // // stageMsg: A string describing the stageStatus. // // Call repeatedly in a program's main loop as you are burning. set stageStatus to 0. set stageMsg to "didn't stage". if (stage:liquidfuel + stage:solidfuel = 0) { set stageStatus to 1. set stageMsg to "no fuel in stage". }. if stageStatus = 0 { // Check for flameout of any of the existing engines: set stg_numF to 0. list engines in stg_eList. for stg_eng in stg_eList { if stg_eng:flameout { set stg_numF to stg_numF + 1. }. }. if stg_numF > 0 { set stageStatus to 2. set stageMsg to stg_numF + " engine(s) flamed out". }. }. // Now actually do it: if stageStatus > 0 { stage. wait 0.25. } Call it anywhere, in the midst of any burn for any reason. Ascending, transferring, landing, whatever. So long as you've got your craft's staging list set up in the right order, and all boosters are on decouplers so they can be destaged when they run dry, it seems to handle just about any rocket design, any mix of solid/liquid, and any weird asparagus staging. Here's a very crude example of use: print "Stupidly going straight up until all stages spent.". print "press AG 9 to quit.". lock steering to up. lock throttle to 1. until ag9 { run stager. if stageStatus > 0 { print "Stage Activated. Reason: " + stageMsg. }. }. Most scripts at some point end up spinning in a loop like that rather than doing everything by waits, whens, and locks, just because people like to see displays updating what's going on on the terminal. Any time you're in the midst of a burn and in one of those types of loop, just insert a call to stager in that loop somewhere, for all your staging needs.

Is there a way to find the altitude at which KSP decides to auto-switch from surface velocity to orbital velocity on the navball during an ascent? I'd like to be able to have my script for ascent switch which one it uses to calculate with depending upon that.

I hope you enjoyed the break. I sometimes feel like I'm being to "complainy" when I look at the issues list and realize I've gor 4 in a row all from me, so I back off and stop for a bit to keep the "to-do" list from looking too overwhelming.