Dunbaratu

So I'm glad it's not just me. I get this too in an until loop. One symptom is that if the engines are thrusting you'll hear them go schhhhh...schhhhhh..schhhhh..schhhhh instead of just a steady ssssschhhhhhhhhhhhhhhhhhhhhhhhhh.

I think what the OP wanted was a setting where you don't pick a fixed pixel size in the setting but pick a relative size - relative to the screen. So instead of, say " small" being defined as such-and-such a number of pixels it's instead defined as being X percent of the height of the screen or something like that.

I imagine that would be really hard to enforce properly anyway. It would mean having to see many slightly different runs of the same thing, which would get tedious.

If that was true then calculating when to do simplified circular-to-circular Hohmann transfers wouldn't work because you couldn't get the elliptical transfer time elapsed. (EDIT, oh, no you're right. Hohmann transfers use the trick of just knowing that it's half the orbital period, which is a special case that only works for circular orbits.)

The 250 is the result of some constants in kip's calculations. The 0.2 is the stock parts default for all non parachutes. To respond to differing part drag requires a feature KOS does not have yet - the ability to query the craft's parts and their properties.

After a bit of googling I've come to the conclusion that there isn't a good webpage out there that tells me the answer to this math problem: I want to perform a transfer from my orbit to intercept another orbit. Both orbits are ellipses (obviously) but you are NOT safe to make the assumption that they are circular. Your starting orbit can be any arbitrary ellipse, and the target can be any arbitrary ellipse. The intercept has to be timed so me and the target are there at the same time. You can assume the two orbits have the same inclination plane, so you can treat it like a problem in 2-D space to make it easier. (Solving the inclination problem can be done separately.) All the help I can find on it keeps containing the assumption the starting orbits are circularized. SO this is my plan of attack. I'm done for tonight working on KSP but I plan to attack this tomorrow. For now check my logic and tell me if this seems right: The givens I have or can calculate quickly from what I have are these: Let v1 be my initial velocity vector right now. I know my speed and my direction relative to the body both me and the target are orbiting (i.e. the sun). Let p1 be my initial position right now, which I could express in XYZ form or in polar coords as (r,theta), where theta is my angle from some arbitrary point I pick). Let o1 be the set of orbital parameters I can derive that describe my current orbital shape. All the elliptical parameters should be easily derivable: the semi-major axis, my current angle from periapsis, etc. What matters is that the new ellipse I make when I burn Let v2, p2, and o2 be the same thing, but for where my target body is right now. Note if I use polar coords I need to use the same reference zero point for both (I can't measure my theta from my periapsis and my target's from its periapsis since our perapsi (is that a word?) aren't at the same angle.) Given all of that as starting constraints, here's my math steps to try to cone up with the answer: Step 1 - Get where my intercept would be if I burned now. If we assume I will burn prograde (or retrograde, which mathematically should just be representable as a negative number in the prograde direction) ONLY, then presumably I can recalculate a new set of orbital parameters, call them o3, that represent my new ellipse I get after applying the delta V. at that point my old ellipse, o1, becomes irrelevant. What matters is the new one, o3. Given nothing but my starting position and that my new velocity must be some vector pointing along the same direction as my current one, presumably that's enough to constrain all the possible new ellipses I could end up with to just the ones possible with differing speeds in that direction. So I need to find the intercept point between that new ellipse, o3, and the target one, o2. I imagine there will be one of three possible results depending on what my new speed is: - Zero solutions: If my new speed is too slow, then the math to find the intercept of o2 and o3 will have zero solutions, or at least no real-number solutions, as there will be no intercept points. - Two solutions: If my new speed is too high, then the equations to find the intercept of o2 and o3 will have two solutions, crossing higher above the target, then falling back in again later. - One solution: If my new speed is just right, then the equations to find the intercept of o2 and o3 will have exactly one solution, barely touching. Therefore, what I'm looking for is the speed at which I only get exactly one solution to the question "where do 02 and 03 intercept?". Because I see there could be 0,1, or 2 solutions, I'm predicting a term involving a square root will be involved somewhere in the math, in which I'll be solving for where that term is zero. (square root of a negative will be the case where there is no intercept, and square root of a positive will be the case where there's two). I predict I'll be able to do this, and therefore come up with a new position, p3, which is the position along the target ellipse o3 where I would barely kiss against it and neither miss below it, nor cross above it, if I tried my prograde burn now. In the case of circular starting orbits this is dead simple - it's always 180 degrees from where I am now, and that simplicity is the reason those equations work out so nicely. But for any arbitrary ellipses that doesn't hold true. Step 2: How many seconds will it take me to get to p3? This should be simple based just on knowing that i'll get there along the path of o3, and I know my current position on o3 and I know the position p3 on o3. Step 3: How many seconds will my target take to get to p3 P3 is also a position along the target's ellipse, o2. How many seconds will it take to get there along its o2 path? Step 4: Solve for which starting position would cause step 2 and step 3 to be the same number of seconds. That's the position at which to do the burn. I THINK this is solvable, and probably a lot of the messy terms will fall out along the way. Can anyone find a flaw in my logic? I'll probably tackle actually doing this tomorrow. I want to be able to get to the more difficult planets in the automated pilot challenge and getting this bit right is crucial.

I don't think big fractional parts is the only instance where it will use scientific notation. imagine something like the mass of a planet kerbinMass = 52915793000000000000000 . // Warning, this is kg, when your ship's mass is in metric tons. It really doesn't matter if you round that off, even all the way to: kerbinMass = 50000000000000000000000. It would still get stored as 5.0E10 because it's big.

Well I did a similar thing for VIM, which is designed to allow people to make their own syntax files fairly simply with just a knowledge of regular expressions. I don't think it's that much work.

© Getting to a planet that's at a different inclination or has an eliptical eccentricity presents more of a challenge. Should the score reflect this? Right now, Duna is worth the same amount of points as Moho, for example, but Moho is a LOT harder because of the need to deal with inclination.

My comments on the new scoring: (A) So, thrfoot, with your new scoring, do you mean a cumulative total of achieving all those things on different missions or achieving them in one single mission? Because this one for example: 10 points - Enter the SOI of all bodies in the Kerbol system I'm not even sure is possible to do on a single *manual* mission, given the massive fuel requirements, and that since it's worth more than doing it for "only" 10 bodies, you must be including the moons as well. You can't enter the SOI of all moons of Jool, for example, unless you get captured by Jool. So when you have to do that for all moons, you're not just talking flybys but captures( which then gets rid of any slingshot fuel savings). That just sounds utterly impossible even without doing it in software. ( New bodies get added by KSP updates sometimes, and there's more bodies planned for the future. So be careful with phrasings like "all the bodies in the Kerbol system", as their meaning changes when updates come out. It's probably best to use explicit numbers so the challenge doesn't become harder or easier as Squad changes the number of bodies.. ©

It's even more limited than that. The bug also surfaces if the KOS module had ever had *in the past* any code running on it that used a variable who's value was large enough or small enough to get represented in scientific notation when KOS tries to write it out to the persistence store. So if your code ever said this line: set Gconst to 0.00i0000000000667384. that would be enough to make it trigger to the bug from then on even after the program finishes. The bug happens when KOS writes that out as "6.67384E-11" but then doesn't know how to parse the scientific notation back in.

// You need these values in order to do the calculation: set gConst to 6.67384*10^(0-11). // The Gravitational constant set e to 2.718281828459 . // natural log base. set atmToPres to 1.2230948554874 . // presure at 1.0 Atm's. set bodyMass to Body(body):mass. // Kerbin's mass. set bodyRadius to 600000. // Hardcoded For Kerbin, radius not available in BODY struct yet. set bodyAtmSea to 1.0 // For Kerbin. use wiki for other worlds. Not avail in BODY struct yet. set bodyAtmScale to 5000. // For kerbin. Use wiki for other worlds. Not avail in BODY struct yet. set vdrag to 0.2 // If you have no parachutes on. // grav acceleration at your current location (i.e. 9.8 m/s^2 for sea level on Kerbin): // Recalculates to take into account the lessening of gravity as your altitude rises, which matters more for small planets. lock gravhere to gConst*bodyMass/((usepe+bodyRadius)^2). // air pressure here: lock herepress to (atmToPres*bodyAtmSea) * e ^ ( (0-altitude)/bodyAtmScale) . // Terminal velocity at current altitude: lock termv to sqrt( (250*heregrav)/( herepress * vdrag ) ). // Force of drag the air causes depending on your current speed and altitude. // Not necessary for term vel, but I thought you might like to know it: lock fdrag to 0.5*( (atmToPres*bodyAtmSea) * e^( (0-altitude)/bodyAtmScale) )*(velocity:surface:mag)^2*vdrag*0.008*mass. it may have errors because I just re-edited it from a version where I was getting term v at periapsis rather than at current altitude, so beware. Also beware that case matters. Some of those variables are all lowercase because they had to be to avoid a bug in KOS with lock expressions.

How on earth did you keep the thing from tipping over in that second screenshot? That ground doesn't look flat enough for it to balance on the engine.

Well, CURRENTLY, a bug will cause it to grind to a halt when you return focus to a ship that had been running software that you had then put onto rails. It doesn't re-load the variables from the persistence store correctly and when it attempts to it breaks KSP's vessel loading procedure leaving half your craft missing, and grinding your FPS to 0.5 or so. But that's a bug that could potentially get fixed, and once it does then your concern would become relevant, so it's a good idea to think about it before that bug gets fixed.

Two Suggestions: 1. When you add more ways to score points, always be careful to only ADD new types of points, and never subtract or reduce previous point methods, otherwise the scores you already handed out will look like they weren't added up correctly to a new reader of the thread. 2. When posting a score, post the parenthesized list of the achievements that summed up to the score, so it makes a more meaningful entry. So for example, instead of: 18: Somebody. It's more like this: 18: Somebody. (3:Stable orbit around Kerbin, 15: safe return to Kerbin surface). Also, your new 7 point achievement should probably include a definition of what you mean by interplanetary space ("outside the sphere of influence of Kerbin or any of Kerbin's moons" would be a good definition.)

Okay, start writing it then. Good Luck.

I've seen several cases where when KOS can't comprehend the syntax it gets stuck in a neverending loop (which is what locks up all of KSP. All a mod has to do to lock KSP is just: "while true {}." and KSP doesn't have a safety mechanism to grab control from the mod back again. Granted, detecting infinite loops is one of the classic computer science problems that is mathematically proven to be impossible) But KSP could theoretically mandate a maximum timeslice based on the user setting for physics update timeframes (that number that defaults to 0.1 in the settings screen) and only allow a mod that much time to finish its response to a callout before slapping the mod with a newspaper and saying "NO. I have a physics engine here to keep track of, bad mod, bad." and then suspending the mod. But it doesn't, so a mod that's not responding brings all of KSP down.

All variables are global and if they didn't last after a program exited then it would be impossible for a subprogram to calculate values meant to be used by the calling program. What there probably should be is a way to classify variables as local or global explicitly, such that you can pick and choose which ones remain after the program ends, but right now everything is global and everything remains.

It would only be a violation if I did it at a time other than when you're allowed to type commands. I only do it at times where the challenge allows you to type commands. And all it does is type the command. All it does is load the next bit of software and run it. If anything I actually made it HARDER for myself by doing that, as I can't adjust to changed circumstances and all I can do is tell the program to continue to the next step. I can't change my mind and tell it to run with different parameters. If anyone challenges it I'll go waste some time re-recording it with the pauses replaced with hardcoded waits to prove it.

It's old. I'm not sure it necessarily has been kept up to date with the latest syntax changes in the language.

well, the video is there now, but apparently the audio keeps cutting out at various parts of it - it seems mostly when in atmosphere - I guess the program didn't like all the CPU load of that plus the vid recorder at the same time. Eventually I may re-dub the video with new commentary but since it's 40 min long that's nontrivial so I'm probably not doing that tonight. It's good enough to constitute proof so I'll let it be for now.

Well if I'd have known that I'd have done a different mission. If you reserve the right to add new sources of points after submissions have come in, then I only think it's fair that get the right to re-submit after such a change has been made.

My entry. (Note: Youtube is still processing the video so the following link might not work right away. If it doesn't work, try back again in a few hours.) Code and craft file posted here: https://drive.google.com/?authuser=0#folders/0Bxkeai7oN35fUFNtZW15Tm12WGM Some screenshots:

And everyone who makes THAT argument is making a flawed argument because if they aren't meant to have any analogies to the human form we're familiar with, then Kerbals wouldn't look like cartoony short humanoids at ALL. They'd be weird and alien. People have been spoiled by the limitations of sci fi TV and movie special effects budgets into thinking putting forehead wrinkles or funny ears or weird makeup on a human is what an alien would look like. No. If it was truly alien it wouldn't look human at all. A tentacle thing like a squid perhaps, or maybe a floating gasbag with arms, or something with 3 limbs, or something with eyes in its hands, etc. The fact is that Kerbals *ARE* designed by artists to appeal to us humans, to make them evoke emotional responses in humans that make humans think "cute". So the claim that analogies to human expectations of appearance are off limits in the discussion are hogwash. These Kerbal aliens are aliens *designed by* a game company to be understandable and familiar to their human customers. Just think about the work that went into the facial expression driver that when the craft is tumbling to its doom causes Jeb to grin joyously while Bill is screaming in terror. Truly alien facial expressions wouldn't be decipherable to a human playing the game. A lot of work went into making darn sure Kerbals are similar enough to humans for us to empathize with them. So make it so the girls playing the game have characters they can empathize with too.

I have a successful mission that I've been tweaking a bit to make it reliable and now I'm ready to go off and start recording the video for it. Before I do, I'd like to chime in on this lightspeed delay thing and show what I did about it. I decided that to simulate the idea that you can get data from the archive, but you shouldn't be able to do it in a way that's happening during the fiddly bits where you need the script to be responsive and quick, I made a program called simRadioDelay. I only use the archive drive during times when this challenge would allow manual typing, and whenever I do I always use it via the program called simRadioDelay, which is stored on the archive to be run from there (not on the local 10k drive). The way it's used is this: run simRadioDelay("any command goes here."). For example, this snippet. which I run when the craft has finished liftoff and circularazation and is in a stable orbit around Kerbin: // Hohmann Transfer to Mun: // ======================== run simRadioDelay( "copy angleUntilHohmann from archive." ). run simRadioDelay( "copy tfDirToUnitV from archive." ). run simRadioDelay( "copy transfer from archive." ). run simRadioDelay( "run transfer(Mun:name,25000 )." ). run simRadioDelay( "delete transfer." ). run simRadioDelay( "delete tfDirToUnitV." ). run simRadioDelay( "delete angleUntilHohmann." ). print "=======================================". print "STEP FINISHED. PRESS AG 9 TO CONTINUE". print "=======================================". ag9 off. wait until ag9. ag9 off. It works with any arbitrary command, except for those which require a string literal (because KOSscript does not support a way to embed quote marks inside strings. There's some code in KOS that attempts to support using backslashed quote marks to do it but it still isn't quite working right at the moment. So for now I have to avoid running a command that contains a string literal in it this way.) Although it works with any arbitrary command (using the LOG self modifying code trick mentioned many weeks ago in this thread), I end up using it just to tell the craft "please load this software onto yourself and then run it and then delete it to make way for the next thing." like you see in my example snippet there. The way it looks is this: //KOS - simulate lightspeed delay between // craft and home based on distance craft // is from archive. Any time I tell the craft // to run something and I am currently in // "switch to archive" mode, I call this first which // waits a bit. // // Also adds an extra 3 seconds to the delay // to simulate handshakes and such (and so I can // see it working when testing close to home). declare parameter rdCmd. // command the vessel is doing. set lSpd to 299792458. // light speed in m/s. set extraPad to 3. // Extra seconds to wait on top of lightspeed delay // BODY:DISTANCE is bugged at the moment and returns // a number that isn't allowed to play maths with // other numbers (some sort of cast error). Therefore // I'm faking it with POSITION minus kerbin radius: set kerbDist to KERBIN:POSITION:MAG - 600000. clearscreen. print "SIMULATING LIGHTSPEED RADIO DELAY". print "+-----------------------------------+". print "| KERBIN IS SENDING ME THIS COMMAND |". print "+-----------------------------------+----------". print "| " + rdCmd. print "+-----------------------+----------------------". print "| MY DISTANCE TO KERBIN |". print "+-----------------------+----------------------". print "| " + round(kerbDist,0) + " meters". print "+-----------------------+---------------------+". print "| RADIO DELAY REMAINING:| |". print "+---------------------------------------------+". // Let's assume a round-trip transmit is required, // so we'll use half ot lightspeed. set totDelay to ( kerbDist / (lSpd/2) ) + extraPad. set startTime to time:seconds. set dLeft to totDelay. until dLeft <= 0 { print round(dLeft,2) + " s " at (26,10). set dLeft to totDelay - (time:seconds - startTime). // Update display less frequently when there's more time to wait. // The 'if dLeft > 0' is there because a bug in KOS makes // WAIT 0 behave like WAIT Infinity: if dLeft > 0 { wait dLeft / 20. }. }. print "Done " at (26,10). print "DELAY OVER.". // ===== Self modifying code to run dCmd: ===== // Clear old file, making sure it exists first // so delteing it won't give an error if it doesn't: log "dummyline" to delayCmd. delete delayCmd. // wrap command with 'switch to 1' and 'switch to archive.': log "switch t" + "o 1." to delayCmd. log rdCmd to delayCmd. log "switch t" + "o archive." to delayCmd. // run it: run delayCmd. (The reason for that odd syntax you see where I do this: log "switch t" + "o 1." to delayCmd. instead of this: log "switch to 1." to delayCmd. is because I wrote this when there was a bug where you can't contain the word "to" inside the string or the parser will mistake that "to" for the "to" in the syntax LOG blah TO blah. It has been fixed but I forgot to change the code to match.