Dunbaratu

Okay. I wasn't talking about the difficulties you had with steering when I talked about reverting flight with a kOS unit turned on, by the way - that I don't know what's going on with. I was talking about the black screen of death requiring you to kill KSP and re-run it from scratch. THAT is a thing I only got when reverting flight without shutdown more than a few times and it stopped happening after I got in the habit of always doing a shutdown before reverting.

Often "print" works in places where nothing else does, when it comes to "invalid" types. So you can print a number out just fine but then can't do any math with it or comparisons on it. This is because "print" is a lot more tolerant of any random hodgepodge of object types than the rest of kOS is. One of the ideas that C# copied directly from Java is the idea that any object in the system can implement a "toString" method that returns a string representation of itself and once it does that then it magically "just works" in any context where someone is trying to use it like a string (like when printing it).

Can you hear a second "click" right after the first stage? If so then it did try to do it but KSP doesn't allow staging too quickly. I've had a hard time trying to hit "stage" successively less than a second apart sometimes. That's true both in kOS and just flying KSP manually too. If I hit spacebar two times quickly in succession sometimes the second one just goes "click" and doesn't do anything and I have to hit it again. Here's the sort of logic I tend to use when I stage: // Put this at the top of the code as a global config setting: // assumeJustFuel: // A lower bound for the amount of mass you expect is a lot // smaller than the mass in any of your stages. If the mass // changes by less than this much in the time it takes to run // a few statements it is probably just from burning fuel. // If it changes by more than this much it's // probably because you lost part of the vessel from staging. set assumeJustFuel to 0.2. // Then when staging do this: set prevMass to mass. until mass < (prevMass-assumeJustFuel) { stage. wait 0.25. }. Essentially it just does what a human does when playing - hit the spacebar until it seems like a piece of the craft comes off. A human uses eyeballs to detect this, the script uses mass to detect it. In your case it might be really fiddly to get theassumeJustFuel threshold just right since you're only expecting to lose the mass of sepratrons when you stage and that's a small enough amount that it might be mistaken for fuel loss.

But don't do the mistake of trying to do TOO much for them, as the players who want the work done for them already have another mod for that called Mechjeb. I don't agree with Jocram about this one though. I don't think it's any more unrealistic to give people eccentricity and node position than it is to give them apoapsis and current velocity, though. In real spacecraft autopilot software even getting THAT much telemetry information is not automatic and takes work. Once you've accepted that it's okay to dive into the API to get things like your position and velocity it's hard to make the argument about avoiding the other data. Also, while having to make utility routines that calculate that data may be a fun programming challenge in a fully functional computer, it's not so fun in a 10k computer that runs at about 10 commands a second. Once you have to use up most of that 10k of code to just have library support routines there's nothing left for your piloting. Yes I know the real space program used computers with tiny storage but they weren't trying to fit ascii source code on them. The computer only stored the machine language code and also the designers didn't make the computer do all the work. Some of the logic was the responsibility of the peripheral control electronics, which they were also designing from scratch. Back in those days the idea that the peripherals should just be dumb and all the thinking should be on the computer wasn't the way things were designed. If anything the way maneuver nodes work NOW on kOS even before adammada's change is giving people MORE power than they get playing manually and doing it by position is actually LESS powerful than what kOS does now. Playing the game manually you can't set a node by ETA time. You can ONLY set it by location. Via kOS you can set a node at a time further into the future than one orbital period from now. Playing the game manually you can't. If you click to set a node at a spot on your orbital path, the UI assumes you meant the next time you'll get to that spot in THIS orbit, not one or two orbits from now.

I also tend to keep trying to skip the boring bits of the video with ">". And when that doesn't work I start thinking "Do I have the throttle up?". Sometimes I even hit ALT-> before I realize how silly I'm being.

For me it's more because I keep thinking in Java or C++ instead of in C#. I come from the world of UNIX programming, where C# isn't really used very much because of it being a Microsoft thing. The other thing I'd like to do besides have a body database is look at all the "can't compare number to number" problems. People have been trying to fix it by making every single number in the mod into a Double, but that seems like its approaching the problem from the wrong end. If the code exists already that translates all numeric types into the word "Number" when reporting them, that seems to indicate the intention to actually support a mixture of numeric types, otherwise that wouldn't be needed. It seems the right response is to add the logic to do type promotion to the expression system.

As a long-time programmer, zero-based anything doesn't bother me at all. It's less intuitive to the new programmer, but in the long run it's usually mathematically cleaner to count starting at zero, which is why languages tend to do it a lot. They're mimicking the language of mathematics when they do that. That being said, the problem isn't that the line numbers start at zero. The problem is that even compensating for that they're still wrong most of the time. They're wrong for two reasons: 1 - They only report based on counting from the start of the current context (sub-body of code, like if conditions, loop bodies, etc). 2 - They CLAIM to be counting lines when they're actually counting statements. That's very different if you have more than one statement on the same line, or blank lines of padding, or comment lines. 3 - Whenever a C# exception is raised the flagrant error will never report where it happened - always saying zero. Those are bigger problems. The fact that it starts at zero is rather minor in comparison to those problems. In fact starting at zero is only a problem due to a fact entirely external to kOS itself - that is the fact that text editors usually start at 1. I'd much prefer it if kOS continued to *internally* count from zero but then just added 1 when reporting the error message. I looked at the github code but was reluctant to jump in because C# is new to me and I don't actually like it much compared to other languages. I did just a little one tiny thing - making it so you don't have to manually say "switch to ..." when it first starts (you used to have to because the mod would start up with no selected volume yet and many file operations would error out as a result). Now I'm reluctant to jump in purely because of the current highly forked nature of the code. Without someone to make leadership decisions about what pull requests are in and which are out, it's becoming a forest of *different* mods rather than one mod. So it's not a good time for a newcomer to start getting involved in it until something is done that unifies it again. One thing I would like to do is to implement a database of queryable body data. I assume the API knows things the Wiki doesn't - like the SOI radius of bodies.

What a clever suggestion. I like this because it would be fun, and unlike a lot of suggestions, is probably actually doable because the code for wings is already there, and a flying parachute is just a fabric wing you deploy. It might be implementable as a wing that has a higher drag coefficient than normal parts do.

A common user interface feature is to be able to pick more than one item at a time from a list by holding CONTROL down while you click (or that clover-leaf thingy on a Mac), so you can then do a thing to all of them in one click. It would be nice to be able to go into the tracking center, pick 10 things from the list, and press the terminate or recovery button. It would cycle through all the them, opening up dialogs for science recovery in serial if there are any science points obtained. Obviously when you do this you can't pick "control craff". Just like regular select lists, you can't always do everything with a multiselect that you can do with a single select.

I think the problem might be that Jaleco is using the AVERAGE delta V requirements instead of the minimum at the planets' optimal positions. For bodies with non-circular orbits that's a hefty difference.

I fear that Kevin's absence may trigger people to sacrifice good design for practicality in the face of the current situation, and have them put more and more stuff into "side" mods for KSP that really belong in the main stock thing.

I can answer that, but I think we're deviating from the point of this thread into topics about KOS itself, not the challenge post.

Ah sorry. I misunderstood on whose part you meant the omniscience to fall. I thought you were complaining that the programmer would have to be omniscient to implement the request (i.e. the request is asking for impossible programming from the human being in our world, not the Kerbal in the simulated world.). I'm of two minds. I see your point but some things are sensible to do in the faster world of c# instead of the slow world of kOS. Like having a natural log function instead of running a converging series in a kOS loop for it, or having an operator that does vector cross products in one statement. But it can go too far to the point where ALL the thinking was done for you in the c# code and you may as well just use Mechjeb's autopilot instead.

A "pull request" isn't someone begging for a solution. It's someone who already IMPLEMENTED one in their own forked copy of the code and is requesting that it be pulled back into the main code. And there's been a lot of that going on. It's just not in official release because Kevin is away.

I wish I'd known that existed before I went and wrote this in my script: set gTurnPres to 0.25 . // Atmospheres of pressure where I want to start my gravity turn. // Calculating the altitude at which air pressure is 0.25 ATM's, using that // as an altitude at which to go into the turn. print "". print "Calculating a natural log by series....". print "Please be patient". print "". // trying to do this: // set gTurnBot to -ln (0.25/(atmToPres*bodtAtmSea))*bodyAtmScale. set x to (gTurnPres/(atmToPres*bodyAtmSea)). set lnSoFar to 0. set n to 1. // KOS 0.92 has no logarithm functions so I'm using a series. // lnSoFar approaches ln(x) as the series converges: until n >= 30 { set lnSoFar to lnSoFar + ( ( (0-1)^(n+1) / n )*( (x-1)^n ) ). set n to n + 1. }. set gTurnBot to (0-lnSoFar)*bodyAtmScale. It seems like it might be a good idea to move those math functions in to the main kOS code, since they're not technically part of sensor functionality, but are a bit more low-level than that.

I have the first interplanetary mission - to Duna and Ike and back home to Kerbin. I did it all in one go and had to compress video as I go, so the video quality is only so-so, but it's good enough to qualify, I figure: I did a video of it, but it's very long. Even though I edited the video to speed up a few of the boring waits it still is 1 hour 24 minutes long. If you don't want to watch the long video and instead just use still screenshots as proof, they're down below. Here's the video: Take off From Kerbin. Stable orbit around Kerbin. (JUST barely. The periapsis is ever so slightly out of the atmosphere.) Escape from Kerbin SOI Stable Sun orbit. Transfer from Sun orbit to Duna SOI. Captured at Duna to stable Duna orbit. Landed on Duna. Ascend back up to stable Duna Orbit again. Transfer to Ike SOI. Captured at Ike to stable Ike orbit. Landed on Ike. Ascend back up to stable Ike orbit again. Transfer from Ike SOI back "down" to Duna SOI and get recaptured. Escape Duna SOI back to Sun SOI. Transfer from sun SOI back to Kerbin. Deflect course to intersect Kerbin's atmosphere and use it to stop me. Parachutes on for "dumb" Kerbin landing. Recover Vessel. Code and Craft Files here: https://drive.google.com/folderview?id=0Bxkeai7oN35fUkM1bmFRV0VKV3M&usp=sharing

The following two things you just said are (in the current version of kOS) mutually exclusive and cannot both be true: 1 - You are NOT allowed to edit the persistence file. 2 - You ARE allowed to perform the mission in more than one go. (come back to a saved game later and continue it). In the current release of kOS, you cannot quit the game halfway through a kOS mission and return to it later unless you edit the persistence file to work around the vessel reloading bug, as described earlier. If you're saying you can't do that to the persistence file then you ARE in fact saying the whole thing has to be done in one go.

I think that HEADING(__,__,__) is not the same as a Euler rotation like R(__,__,__). The values of FACING and PROGRADE are given in Euler rotations "R(__,__,__) but then you're setting them using HEADING(__,__,__) which isn't the same coordinate system. All Directions in KOS by default get converted into Euler Rotations when you read them back out even if you didn't set them that way, which can be a bit annoying at times. You can SET your steering by HEADING(_,_,_) or V(_,_,_) but you can't READ it back that way. It always reads back out as R(_,_,_) regardless of how you set it. The difference is that HEADING conforms to the navball, while R(_,_,_) is giving your rotation from the super-secret invisible XYZ system that KSP uses internally, which can be a very confusing challenge to understand, as it's not consistent from one minute to the next. (Basically, when you are high above the planet, the planet rotates around Y and the universe stays put, but when you're close in to the planet, it freezes and instead the universe rotates around Y. Depending on exactly when you transitioned between those states, the X and Z axes could be aligned with any arbitrary longitude and the only thing you know for sure is that they're 90 degrees off from each other. The Z axis might be north one moment and then a half hour later in the same game it's now southeast because it rotated for a while and then re-froze. So HEADING gives you a nice navball-centric coordinate system to use, but then when you READ your values back, they're not expressed in that system. They're back to telling you how far you're rotated from wherever the heck the X and Z axes happen to be at the moment.

I have found that trying to use "revert flight" too many times with KOS enabled can do this (the black death effect). I've had success avoiding it by doing this: Every time you're about to revert flight, FIRST go into the KOS terminal and give the command "SHUTDOWN.". THEN revert the flight. There is something the KOS DLL is doing that leaves behind something still running when you revert flight. I'm not sure what it is, but a manual shutdown seems to avoid it.

Two problems: 1 - I imagine that would only look cool if you had a high FPS. If you're animation is lagging that would very quickly change from looking cool to looking really messed up and frustrating. 2 - Remember that there are some things the GUI only lets you control by right clicking on a part to bring up the menu. Imagine having to make an emergency on the spot command to one of the parts and you can't bloody right click on the thing because it's constantly moving about on your screen. That might get exceedingly frustrating.

(talking about having it take game time to build a rocket on the pad.) I don't think it would be irrelevant just because you can time warp. It makes it impossible to launch two launches back-to-back one right after the other, which affects all sorts of mission timings. While it may be realistic to have the wait, it would only be realistic if we had more than one launchpad because real space programs don't have to launch everything from ONE launchpad - one team can be assembling a rocket on pad 2 while another is launching from pad 1, allowing you to make your rockets in parallel and launch them together. But because KSP only has one launchpad, build times would end up having to be done in serial, and that creates an unfair extra unrealistic hurdle.

I don't think this is doable for the same reason we don't have L1 Lagrange points. To do it really properly would require calculating gravity as a 2-body problem rather than a 1-body problem with the sphere of influence technique. Problems with trying to do it with the current 1-body model: 1 - It would have an odd fold in space at the boundary between the SOI's. It would behave really screwy in the space between the two planets. Instead of moving across a nice mild gradient gently transitioning from pulling toward Dee to pulling toward Dum, you'd instead hit a line where it would just instantly JUMP from pulling strongly one way to pulling strongly the other. This will interfere with trying to pull off nice figure-8 paths. 2 - The current model doesn't support the idea of "equal" planets with SOI radii that have equal "rights" butting up against each other. Instead it has a parent/child tree relationship of SOI's. i.e: Mun's SOI is inside Kerbin's SOI is inside Sun's SOI. So to do this you'd need to make one of the two twin planets be a "moon" of the other one, which sort of gets into the next problem. 3 - The SHAPE of the SOI boundary between the two bodies would be wrong. What you'd need would be something akin to when two spherical soap bubbles intersect and form a common wall between them, and that common wall is not shaped like a sphere but gets much flatter between them. But the current model can't do that. It puts spheres inside spheres inside spheres and they all have symmetrical shapes. No egg-shaped SOIs or SOI's flattened on one side are currently supported by the model the game uses. Don't get me wrong. I'd love this, especially for the screenshots alone of landing on one planet and having the HUGE other planet taking up most of the sky above. But it would require a change in the main game engine to support it.

That's not true. Both are available, but just not in entirely the same format: Say: LOCK STEERING TO _______ Where ______ is one of the things on the following table: \ Type Frame \ of of \ Data Reference \ Euler XYZ \ Rotation Vector | R( __, __, __) V( __, __, __) ---------+-----------------|-----------------------+ pro | PROGRADE | VELOCITY:ORBIT | ORBITAL |-----------------|-----------------------| retro | RETROGRADE | (-1)*VELOCITY:ORBIT | -----------|-----------------|-----------------------| pro | doesn't exist? | VELOCITY:SURFACE | SURFACE |-----------------|-----------------------| retro | doesn't exist? | (-1)*VELOCITY:SURFACE | +-----------------|-----------------------+

It's hard to tell from description alone what's going on. Can you post the code? I do get massive "turn the wrong way first" behavior from kOS, where it tends to sweep in a big curving arc that starts trying to go perpendicular to the desired direction instead of straight toward it, and then it realizes that's not the way it wants to go so it then curves back around and eventually gets to where I told it - but almost never in a straight simple turn. It's a bit annoying but it never really mattered that much except during ascent from large gravity wells. In other cases you can just make it wait and not fire the engines until the rotation is done, so you don't care how wonky the rotation was to get there. It's only during ascent that you can't do that because you need to leave the engines on as you do it. But then again, during ascent I'm never making big sweeping arc changes anyway as I'm trying to follow an ascent profile that starts off straight up and then very slowly curves off from that. (i.e. at one moment I've locked steering to a pitch of 45, then later to 44, then to 43, then to 42, etc. rather than going all the way from 45 to 0 all at once for example. I'm trying to make my ascent follow a path that looks roughly like the shape of a sideways parabola (a square root curve) so I sort of avoid the problem by the fact that making big changes all at once isn't appropriate to the algorithm I'm trying to do anyway. ) If you're in a position where you can just wait and drift until your steering stops going the wrong way, You can test whether or not it's lined up by comparing the Euler rotation called FACING to the one you've locked your steering to. FACING is the direction you are currently pointed, not the direction you are trying to point. So you wait until the difference between the pitch, yaw, and roll components of FACING are very close to those of your steering direction. (That check is a bit more ugly than it might seem because sometimes the rotations will be expressed in equivalent angles that look different if you just look at their raw numbers - i.e. -45 degrees as opposed to +315 degrees - So you have to do the trig on them to compare the angles (i.e. compare their sines and cosines.)) But in general I don't know why kOS doesn't steer in the most efficient direction toward the destination heading. i.e. if I was flying manually, and the angle I wanted to go to was about 45 degrees to the left of where I am pointing now, I'd just hold the "A" key down to start rotating to the left. But kOS seems to try to go UP first (i.e. the "S" key), then roll left (i.e. the "Q" key) until finally it has rolled over far enough that UP is now what LEFT used to be so it can pull up to go to the desired heading. That's a sort of silly way to it but at least if it's going to do that it should WAIT to pull up AFTER it's finished the rolling part so it can still draw a straight line across the navball to the new heading, not a big swooping arc. But at any rate I don't know why it didn't just yaw to the left instead. There are times when I sort of wish I could just get independant control over what the keys do to simulate what the user is used to when flying the game manually: (That would also solve the RCS translation thing too - just let us do what the IJKLHN keys do and then let us work out the logic of how to make that work.)

I noticed the laggy stuttering also can be triggered not just by UNTIL loops but also by running WAIT UNTIL's that have a complex enough expression as the conditional check. In fact, WAIT UNTIL seems to be even worse. With an UNTIL loop I can manually throttle down the speed of execution with a WAIT 0.5. or so when speed is not important and that greatly helps reduce the stutter. But there's no way to tell WAIT UNTIL (condition) that it doesn't need to check all that often. I seem to get less lag by turning an instance of this: WAIT UNTIL (some condition). into this: UNTIL some condition { wait 0.2 . }.