LN400

The process of developing anything usually starts with a set of goals. To reach those goals you set minor goals. When you reach one of the minor goals, you have the next beta. When you finally reach the original goals, that's when you get a "release". It's really not more than that.

From what I've read here on the forums, I take it "full release" points to the game having reached the point of developement which was their initial goal. It does not imply perfect, it simply means "this is what our goals were back then". Now they have reached those developement milestones, we get a "full release". It opens up for further improvements as they keep setting goals. Perhaps this whole issue is based on different ideas of what a "full release" means.

As for buggy releases, one word: Daggerfall. How someone can cram that many bugs into one game is, and will remain a mystery. Still, it hit the shelves and even today it is being played (not bad at all for a game that old that buggy). Ok so DF is at one extreme end of the scale but which major game was ever released totally bug free, which would be the other extreme end of the scale? I can't think of one. I just think it's ludicrous to judge a game (or the developers) by whether or not it's bug free. Instead, what matters is, will they fix the bugs when they surface? So far everything points to yes, they will. We need to get out of our fantasy bubble where "perfect" is real (it isn't, it's ideal), stop complaining about every little, minute, miniscule flaw and we certainly need to stop blowing these flaws way out of proportions. Appreciate that you have KSP at all and not some knitting simulator without knitting needles. To the devs: Your work is greatly appreciated.

TheXRuler: Thanks for the additions (and the rep ) and thanks tons for explaining the 2 small buttons on the maneuver node. I never figured out what they were good for.

Upgrading as soon as I can BUT also keeping 0.90 until the modders catch up. Some of these mods are must-haves to me.

Just a few pointers on docking/rendezvous. I'm not saying this is The Best way, but it's a way that consistently works for me. Probably several steps you already have figured out in here but for the sake of completeness: First thing: RCS. Once in orbit and with the inclination as well as altitude for overtaking sorted, use RCS for adjusting altitude/trajectory. Main engines tend to be way too powerful for fine adjustments. Ok, back to the launch pad. In map view, set the target so you have one less thing to worry about later. Look at the target's apo/periapsis to get an idea of your orbital altitude. Launch (getting close to target on orbit injection is real nice but it won't break the game if you miss the target by half an orbit). During the ascent, figure out if you'll get ahead or behind the target and set your apoapsis to give you the necessary overtake speed once in orbit. Higher if you're ahead, lower if you're lagging. How much depends on how much distance is between you two. Once in a stable orbit, get the inclination sorted first. After that there are in essence only 2 different scenarios. First is: The target is far away (>100km the way I prefer it) , in which case you circularize with both apo and periapsis well above/below target orbit for a quicker rendezvous. Second is (and it should come after the first anyway): The target is close (I regard less than 100km close at this stage). Get either your apoapsis or periapsis (not both) to match the target's apo/periapsis. Now the overtake speed will drop which is good. Keep a close eye on both of the closest approach markers and when your 2nd orbit approach is greater than the 1st approach, raise/lower the apo/peri so that the 2nd approach is closer than the 1st. Do this gradually. This will get you into an orbit that will be very close to the target's orbit everywhere on the orbital trajectory. It will also bring the target speed down to just a few 10's m/s where RCS becomes really effective. When the distance is between 15 and 5 km, use RCS to glue the prograde marker to the target marker, and keep them glued together. You might want to initiate this by using the main engines if the prograde marker is more than 10* off the target marker but once the two match, and target speed is less than or at least not much greater than 10m/s, switch to RCS. Keep the 2 markers glued to eachother and gradually slow down as you approach using RCS. Rule of thumb: Under 500m apart at around 50m/s, reduce target speed by 10m/s per 10m closing in. Don't allow the markers to separate. Be on it. 10 or so meters away, slow down to crawling speed and align the docking ports. Eyeballing works courtesy of the magnetic pull on the ports. Again, there are many ways you can do it, but this is a way I found would work consistently. Plan ahead and don't do sudden improvisations to you plan unless it's part of the plan. Jazz is not what you want to play here.

Moon Machines is a pretty good mini series on the engineering that went into the Apollo program.

Nice list. The mods I personally would love to see in v1 (unless they somehow get incorporated in the stock game) are in particular SCANSat, RT, KOS, Kerbal Engineer Redux, Procedural Fairings and FAR. KW Rocketry and MRS really add to the game as well as Raster Prop Monitor but I _guess_ I could live without them if I absolutely have to (fingers crossed I don't have to).

I don't know if this is of any use but here is a short code for 2 files, func3a and func3b where 3a is main and 3b has the function. 3a @lazyglobal off. run func3b. declare local a to 1. declare local b to 2. print a. set a to swap(). print a. 3b function swap{ declare local temp to 0. set temp to a. set a to b. set b to temp. return a. } EDIT: I'm still a bit curious why the local in main could be manipulated by func3b. Oh well, every day is a chance to learn something.

Thanks tons for the new version. Quick test and it seems my boot issue has been completely solved. Awesome work and I can't wait to explore the new features. User defined functions, here I come! - - - Updated - - - Thanks tons for the new version. Quick test and it seems my boot issue has been completely solved. Awesome work and I can't wait to explore the new features. User defined functions, here I come! EDIT: trnt: If I understand your question correctly, you can use a variable (let's call it temp) to temporarily store one of the values, say a, copy a to temp, copy b to a then copy temp to b.

Thanks for the reply. From what I have gathered so far, the in-VAB options are limited to rename tag and lights on, the boot.ks will need to be in Archive and the same boot file will be uploaded for all KOS equipped ships. I am looking for a way to have each rocket/spaceplane design have their own, unique boot file. Any pointers to where I can find info on boot files? Google gave me 16 hits on 'ksp kos boot file' where half were unrelated to KOS or KSP.

Just one question. I am aware that the KOS units don't "exist" in the VAB so uploading programs isn't possible until launch but I am still wondering. I found the lines of what's on the KOS hard drive in the perisistent file and now the question: Is it possible, or advisable, to alter the parts cfg in such a way that the hard drives will have files uploaded to them the moment you hit the launch pad and the units come into existence?

Hello, I am new to this place and just came across this post. I just recently started looking at KOS so there are quite possibly better solutions than this but I have made a program, "term", that lets me store 2 3-digit numbers in a "verb/noun" way, kinda like the Apollo style, using 2 of the action groups (just 2 for now since it's only a test) for inputs. So I end up with a total of 64 combinations that could be "if"-ed to run various other programs, functions etc. It's not really optimal as I need to set aside 2 of the 10 AG's for this when running the script but as a nice side effect, I get to use the Raster Prop Monitor MkI pod IVA's AG buttons as input keys, which is kinda neat. The whole script is really a test of various ideas so it's not aimed at being optimal but it might give you an idea how to have a UI with that program. Mind you it's rather large but by removing all newlines, spaces that are not needed, removing comments and cutting down the variable names, you can shave off quite a lot and again, this is just a test of varius ideas so any tips on improvements would be greatly appreciated. clearscreen.unset all. //this sets up a fake 'shift register' memory. declare store_value.//value to be stored in register cell 0 (store:z). set store to v(0,0,0).//fake 3 cell shift register memory set store_count to 1. set store_en to false.//enable storing to shift register set sum1 to 0.//decimal interpretation of first 3 digits in shift register. set sum2 to 0.//decimal interpretation of next 3 digits in shift register. set exe to false.//enabled when prog and mode set. set prg to 1.//0 error 1 nominal ag1 off. ag2 off. trig on. set prog to true. until prog = false { if trig { trig off. on ag1 { set store_value to 1. set store_en to true. trig on. ag1 off. } on ag2 { set store_value to 2. set store_en to true. trig on. ag2 off. } } if store_en = true { //shift logic. set store:x to store:y. set store:y to store:z. set store:z to store_value. if store_count = 3//interprets the stored digits and sets(sum1) which program to run. { set sum1 to 100*store:x+10*store:y+store:z. print "V "+sum1 at (0,8). if sum1 = 111 { print "PRG1" at (7,8). } else if sum1 = 112 { print "PRG2" at (7,8). } else if sum1 = 121 { print "PRG3" at (7,8). } else if sum1 = 222 { clearscreen. print "Shutting down..." at (0,8). wait 1. set prog to false. } else { set prg to 0. print "INVL" at (7,8). } } else if store_count = 6//interprets the next 3 digits and sets (sum2) which mode to run. { set sum2 to 100*store:x+10*store:y+store:z. print "N "+sum2 at (0,9). if sum2 = 122 { //set exe to true. print "MOD1" at (7,9). } else if sum2 = 121 { //set exe to true. print "MOD2" at (7,9). } else if sum2 = 212 { //set exe to true. print "MOD3" at (7,9). } else { set prg to 0. print "INVL" at (7,9). } set store_count to 0. wait 0.1. } if prg = 0//if invalid program or mode selected { wait 0.7. clearscreen. set prg to 1. set store to v(0,0,0). set store_count to 0. } set store_count to store_count+1. set store_en to false. } print store:x at (0,6). print store:y at (2,6). print store:z at (4,6). } unset store_value. unset store. unset store_count. unset store_en. unset exe. unset prg. unset sum1. unset sum2. clearscreen.