Search the Community

I've been having trouble with that regard, too. I think the problem may be the density of the command pods and heatshields combined with kerbin's shallow atmosphere. The only solutions I've found are to come in super shallow and try to bounce like apollo (only worked once or twice with the larger pods, maybe we could talk to the FAR people about how to give the heatshields and pods more lift), use wings (works fairly reliably but restricts your designs somewhat), or burn at about 30-35km until I'm under mach 5.

All that talk of marriage and junk I'm just entering my first real relationship right now (been a bit shy my whole life)

Hey there everyone, how's it going! First of all, I just wanted to thank this community and especially Squad for being so awesome, without you guys we wouldn't have so many great creative minds in one spot. Keep it up! Secondly (and I don't know if this is the right sub-forum for it), I wanted to propose a joint project in the vein of the IYSS. As we all know, KSP has been quickly gaining popularity recently, partially due to the efforts of our wicked Media Team. Those guys put out quality solo videos all the time, but personally I quite enjoy watching the projects they work on together. We've seen what they can do, so let us show them what craziness we can come up with! I'd like to get a few of the smaller KSP YouTubers together (say...anyone with 1000 subs or less?) to work on our own version of the IYSS, though perhaps that might seem a bit unoriginal. So instead we could attempt a surface base or station around another planet, maybe build a large ship in Kerbin orbit and send that somewhere...there's many possibilities and all ideas are welcome! The purpose of this collaboration would not only be to show off the game, but also to expose the smaller channels and maybe strike up some friendly competition with the Media Team. Please let me know what you think. I'd love to make this as huge a project as possible, so the more the merrier! -------------- UPDATE: Let's go to Duna! The Mun is boring, so we're skipping that for now. The Duna phase will consist of a ground base and station once again, but with a bit more freedom when it comes to the builds. -------------- UPDATE: Time for the second phase! Take a look at the submission thread for all of the current and previous videos. For this phase we'll be heading to Minmus with a ground base and an orbital station. Keep tuned! -------------- UPDATE: The project has officially begun, check out the submission thread! Link to the thread here and a playlist . Also, drop on by the Reddit thread here!-------------- UPDATE: Well, now that we've had this idea up for a while and a good number of people have joined, let's give everybody an update on what's happening. Unfortunately we've got a pretty big group, so I doubt we'll be accepting others in for this build, but there'll be more in the future! Everyone's welcome to drop by and chat with us, though Project members: Nauthy - YT CakeNinjaProductions - YT leax256 - YT Goosexi - YT dharak1 - YT Cooly568 - YT The Destroyer - YT Spyritdragon - YT TheCanadianVendingMachine - YT Holo - YT KCBP Rules: 1a. A max limit on parts per module, this is perhaps the most important with so many people involved. The limit will be 40 parts for the ground base and 60 parts on the station. We need to keep the parts count as low as possible, since we all know how bad the lag can get, especially for those with not so beefy PCs. There is a leeway of 5 parts, in case of an emergency and you absolutely need to add a few extra pieces. 1b. You are allowed to build however many modules you want, as long as you stick within the part limit. So it should allow for more freedom of creativity and will ensure that the builds will have more interesting components. 2a. No docking dead-end modules. If you take up a docking port, there should be at least one additional docking port on your module of the same size. Station-to-station ports should be Senior-sized. Should be pretty obvious why this rule is in place, we don't want to block off the expansion. In the same vein, try to attach your modules to a port that makes sense. We'll probably have to rearrange some modules around anyways, but as long as there's plenty of docking ports available it won't be an issue. 2a. The same applies for the ground base, always make sure to leave a port open. It's not much of a base if all the modules are just scattered around (rovers may be exempt). 3. Debris - don't leave it behind! More specifically, when you launch your module, have a way of deorbiting any debris. Still, it's not a problem if you're unable to deorbit, as long as you ensure that you terminate its flight before posting the save file. We wouldn't want a random piece of rocket to crash into our awesome builds, after all. Keep those orbits clear! 4. Mods - they are sort of allowed, just not on the final module. It's no problem if you use mods for the launch, as long as whatever you leave behind on the station is built solely from stock parts. This also ties in to the rule above about debris, since we don't want modded parts floating around in orbit. 5. The builds and the order of uploading - please stick with what's been assigned. I don't want to be a jerk about it, but we've got so many people involved in the project that we absolutely need everyone to follow this rule. The order might change depending on the situation, but the builds we're currently working on should be our focus. The project will eventually have stations and ground bases all over the system, so let's take it one step at a time. 6. The recording - your video should be of good audio and visual quality, though that's a given. Let's put a time requirement on it, too, say between 10-30 mins. Most importantly, please talk a bit about the project and your module's intended purpose. Cinematic videos and such are totally cool as well, just make sure to leave a little tidbit at the end with the previously mentioned info. 7. Please post your submission in the other thread. I don't mind if it gets posted here as well, I just want to make sure that the other thread gets the attention it needs. Since it's in the Live from Mission Control sub-forum, it only makes sense that the actual videos get posted there. Any other info that people are interested in they'd like me to leave here? I think I've covered the basics, but I'll gladly add more if needed, lots of discussion throughout the thread.

wtf is with Scott Manley? He often talk about stuff he doesn't fully understand but pretends that he does. popularity has nothing to do with expertise or authority on matters of science.

Well... guess you found a good reason to stop using hacks... not trying to talk you down or nothing, its a SP game play it your way, but if you did construct it in space you'd be fine. In the VAB... hit that save button as much as possible. I hit it after every major part that goes go.

Where it blows Day 1: Jebediah could hardly wait. The maiden flight of Orion, a.k.a “Ol’ Boom-boom†was ready for launch. Along side of him were Bill and Bob. Bill was scared due to the fact the rocket was powered by 1000 nukes. Bob, well, he wasn’t exited or scared. As the final seconds ticked away, Jeb accidently fired the LES, meaning they couldn’t turn back. Once the rocket launched, explosions ravaged through the town. KSC staff, however, couldn’t hear it since they were in a sound-proof bomb shelter. Surprisingly, they got into orbit in less time than most rocket launches, at 2.15 minutes. “Jeb, how’s everyone doing up there?†radioed Gary Kerman, Capsule Communicator of the flight. Jeb replied with “Fine, except for Bob and Bill barfing due to motion sickness.†Ever since the first rocket flight, Kerbal 1, motion sickness has been a problem, and KSC had no idea what caused it. Day 50: After about 105 orbits, they could finally transfer to Duna. Even with nukes powering the rocket, it took 10 minutes to transfer. Bob could hardly wait to get to Duna, as he would pilot a lander that could land everywhere! Plus, it would be his first time being up close to Duna. Day 165: Duna. Where Kartains are believe to live at. Still, Bob could never be happier. The crew finally got to Duna. Day 205: It was 5 minutes until they could move to the DM to land on Duna. Suddenly, there was an explosion and the pod was spinning. “Jeb, what the heck happened? I said not to throttle up the engines and turn to starboard!†yelled Gary. “It wasn’t me! I swear!†said Jeb, confused about the situation. “Uh oh, when I throttle up, we don’t go any faster!†said Bill, screaming his head off. Suddenly, KSC, and the crew, went silent. Then, Flight director, Gene Kerman, yelled “THE POD FELL OFF THE ROCKET? GOD DAMNIT, KRAKEN, WHY DO YOU RUIN EVERY SINGLE INTERPLANETARY FLIGHT?!?!†Now, everyone realized that the crew was stranded. As communications faded out, the crew was stuck alone, with only each other. Searching for logs...Logs found. Select log? <Y Log list. Select log from list: Day 1 Day 2 Day 6 Day 10 Day 51 Day 70 Day 100 Day 278 Day 582 Day 666 Day 987 Day 1500 Day 1 This is the first day without communication with KSC. Not much to talk about, other than that today was Bill’s birthday. I will report on stuff tomorrow. What day is tomorrow anyway? -Jebediah Kerman Day 2 Today is my birthday. I really wish I was home so I could be eating cake. Oh well. We saw Gilly today. I figured out there was a calendar system on the ship. Cool. -Jebediah Kerman Day 6 Today is Bill’s birthday. If you’re reading this Bill, happy birthday. -Bob Kerman Day 10 I want to go home. -Bill Kerman Day 51 Why do we still use this? Well, anyways, Eve looks like a good home. -Jebediah Kerman Day 70 Merry Christmas. -Bob Kerman Day 100 Day 100 without radio. Milestone achieved. -Jebediah Kerman Day 278 I can’t believe we’re still using this. Well, who cares? I don’t -Jebediah Kerman Day 582 Where’s the Red Mush? -Bob Kerman Day 666 666. The number of the Knevil. Day 987 Found the propulsion stage. It was still intact. If only we could dock to it to it and use it to get home. -Bill Kerman Day 1500 We’ve reestablished radio contact with KSC. We can actually dock with the propulsion stage! We just did and now it’s time to hea- Dangit. NO BOMBS LEFT IN THE STAGE!!!! Now we can’t go home...NOOOOOOOOO!!!!! -Jebediah Kerman This is all the data there is left of the flight. The rescue team found the craft, and inside were the bodies of Bill, Jebediah, and Bob Kerman. When Erlock Kerman poked all of the crew, it was determined they were dead. The End Original word count: 666 Now: 670 or so

Awesome! I love seeing what people build with Kethane. I'm not a KSP dev. ;-) Release dates are sometimes hard to pin down, but versions are easier to talk about. Kethane has a narrower scope so it's easier to plan releases. The geodesic grid map will be in the 0.7 update. As you can see, a lot of it already works great!

So with all this talk of debris, has anyone ACTUALLY had a collision? I don't mean with that stage you just dropped an orbit or two ago, I'm talking something that's been up there not-rusting for some time?

I've got a feature request wrapped inside a bug report, having to do with how tank definitions are initially applied. Say you set up a tank definition like this … 'cause I have: // RP1-LOX TANK_DEFINITION { name = CommonBulkheadStandard basemass = 0.000108649774484067 * volume TANK { name = LH2 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -253.8 loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C amount = 0.0 // liters maxAmount = 0.0 // liters note = } TANK { name = RP1 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 0.35 * volume // liters maxAmount = 0.35 * volume // liters note = } TANK { name = LOX fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -184 loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C amount = 0.65 * volume // liters maxAmount = 0.65 * volume // liters note = } TANK { name = Hydrazine fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 0.0 // liters maxAmount = 0.0 // liters note = } } Just to make my intentions clear: This tank can hold LH₂, RP1, LOX and hydrazine. But by default, it holds only RP1 and LOX. The volume is meant to be divided 35% RP1 and 65% LOX, and each tank in the part has a utilization factor of 85%. That's the idea, kay? Then you create a tank part config file what looks like this: @PART[fuelTank]:Final { !RESOURCE[LiquidFuel] {} !RESOURCE[Oxidizer] {} MODULE { name = ModuleFuelTanks volume = 2100 // liters type = CommonBulkheadStandard } } This is supposed to take the stock fuelTank part, remove the LiquidFuel and Oxidizer resources entirely, then configure it using the above tank definition, with a total volume of 2100 liters. Kay so far? What I expect to happen, given this setup, is that the tank will come into the VAB with its 2100 liters of interior volume divided up into 624.75 liters of RP1 and 1160.25 liters of LOX, ± a liter or so for rounding. That's 2100 liters × 35% × 85% for the RP1, and 2100 liters × 65% × 85% for the LOX. What actually happens is that the tank comes into the VAB with 735 liters of RP1 and 1049 liters of LOX, and I don't know why. If I add an RP1 engine, then use the "remove all tanks" and "configure remaining volume for engines", the results end up being correct. To try to nail this down, I tried swapping the positions in the config file of the RP1 and LOX tank entries, so LOX came before RP1, like so: // LOX-RP1 TANK_DEFINITION { name = CommonBulkheadStandard basemass = 0.000108649774484067 * volume TANK { name = LOX fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -184 loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C amount = 0.65 * volume // liters maxAmount = 0.65 * volume // liters note = } TANK { name = LH2 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -253.8 loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C amount = 0.0 // liters maxAmount = 0.0 // liters note = } TANK { name = RP1 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 0.35 * volume // liters maxAmount = 0.35 * volume // liters note = } TANK { name = Hydrazine fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 0.0 // liters maxAmount = 0.0 // liters note = } } Again, I don't know why, but I got the wrong answer in the VAB. It's 1365 liters of LOX, which adds up to 2100 liters × 65% leaving 735 liters left over, but there's only 420.7 liters of RP1, which is like 57.2% of that and which doesn't add up to anything. So I haven't figure out where that came from. But the point here is that the order of the tank config nodes in a tank definition matters. Next test was to try combining proportional maxAmounts with fixed ones. This tank definition is the same as the first one I showed you, only it also has 100 liters of hydrazine monopropellant in it. // RP1-LOX-Hydrazine TANK_DEFINITION { name = CommonBulkheadStandard basemass = 0.000108649774484067 * volume TANK { name = LH2 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -253.8 loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C amount = 0.0 // liters maxAmount = 0.0 // liters note = } TANK { name = RP1 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 0.35 * volume // liters maxAmount = 0.35 * volume // liters note = } TANK { name = LOX fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -184 loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C amount = 0.65 * volume // liters maxAmount = 0.65 * volume // liters note = } TANK { name = Hydrazine fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 100.0 // liters maxAmount = 100.0 // liters note = } } Here I expect the tank to end up with 100 liters of hydrazine, 590 liters of RP1 and 1095 liters of LOX. (See below for how I got there.) Instead, I get this: Note that this is exactly the same as the first example, only with the tiny leftover space (left out by rounding off) filled with hydrazine. Which isn't right at all. Again, if I go into the UI, remove all tanks, manually create a 100-liter hydrazine tank, then tell it to auto-configure for an RP1/LOX engine, I get the right result: Just to confirm things, I then edited the config file to move the hydrazine entry to the top, like so: // Hydrazine-RP1-LOX TANK_DEFINITION { name = CommonBulkheadStandard basemass = 0.000108649774484067 * volume TANK { name = Hydrazine fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 100.0 // liters maxAmount = 100.0 // liters note = } TANK { name = LH2 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -253.8 loss_rate = 0.0000000000422720017314612 // 0.1% per day at 20°C amount = 0.0 // liters maxAmount = 0.0 // liters note = } TANK { name = RP1 fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 amount = 0.35 * volume // liters maxAmount = 0.35 * volume // liters note = } TANK { name = LOX fillable = true efficiency = 0.85 // common bulkhead mass = 0.0 temperature = -184 loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C amount = 0.65 * volume // liters maxAmount = 0.65 * volume // liters note = } } Again, I got the wrong answer in the VAB. The 100 liters of hydrazine is right, obviously. But the other two are both wrong, and I haven't figured out how the plugin got them. So there's the bug-report part of this: The plugin is assembling tanks incorrectly. If you use both proportional tanks ("## * volume") and efficiencies of less than 1, the plugin does the math wrong. My workaround is to leave all maxAmounts in the tank definition set to zero, then build my tanks manually in the VAB. This gives me the right answers always; the auto-configure button has never failed me so far. But it's an extra step for every single tank on every single spacecraft, and that's annoying. It works, it doesn't stop me using your (super-awesome) mod, but it's annoying. Here's the feature-request part. In messing around with this, it occurred to me that the way tank definitions work could be changed to make it all much simpler. Now, I'm about to propose a big change, one that breaks compatibility, so I won't be offended if you laugh and walk away at this point. The tank definition syntax could look like this: TANK_DEFINITION { name = CommonBulkheadStandard basemass = 0.000108649774484067 * volume TANK { resourceName = Hydrazine utilization = 0.85 // common bulkhead type = fixed maxAmount = 100.0 // liters amount = 100.0 // liters } TANK { resourceName = LOX utilization = 0.80 // common bulkhead, insulated type = proportional maxAmount = 0.65 // 65% of the remaining usable volume amount = 1.0 // this tank starts out 100% full temperature = -184 loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C } } 1. Change "name" to "resourceName" for consistency. This confused me at first. The name parameter to the TANK_DEFINITION node can be anything you want, but the name parameter under the TANK node must match a resource name. The stock modules tend to use resourceName for this, so I suggest it be changed. 2. Change "efficiency" to "utilization" for clarity. This one might only make sense to me. In the literature (aw haw haw haw, how good of you to come for tea Lord Wobblypants) there's consistent talk of utilization fractions of propellant tanks, given as a percentage. You could adopt the same vocabulary if you wanted. I think it'd be a little clearer, but it might only be clearer to me. 3. Give tanks a "type" that's either "fixed" or "proportional." I'm not married to the terms, obviously. The idea is that either a tank is defined to have a specific number of volumetric units of the resource in it (both maxAmount and amount), or it's defined in a proportional way, such that maxAmount is the fraction of the tank's usable volume and amount is the fraction of the tank's capacity. How's this work in practice? Lemme walk you through a kinda complex example. TANK_DEFINITION { name = ServiceModule basemass = 0.000108649774484067 * volume // Oxygen supply, for use with IonCross TANK { resourceName = CompressedOxygen utilization = 0.90 type = fixed maxAmount = 10.0 // liters amount = 10.0 // liters } // Waste CO₂, again for IonCross TANK { resourceName = CarbonDioxide utilization = 0.90 type = fixed maxAmount = 1.0 // liters amount = 0.0 // liters } // RCS monopropellant TANK { resourceName = Hydrazine utilization = 0.85 // common bulkhead type = fixed maxAmount = 200.0 // liters amount = 200.0 // liters } // Bipropellants for the main SPS engine TANK { resourceName = RP1 utilization = 0.85 // common bulkhead type = proportional maxAmount = 0.35 // 35% of the remaining usable volume amount = 1.0 // this tank starts out 100% full } TANK { resourceName = LOX utilization = 0.80 // common bulkhead, insulated type = proportional maxAmount = 0.65 // 65% of the remaining usable volume amount = 1.0 // this tank starts out 100% full temperature = -184 loss_rate = 0.0000000000567356572258533 // 0.1% per day at 20°C } } This is a notional tank definition file for an Apollo-esque service module. It's got life support tanks (assuming you're using IonCross, 'cause really, who isn't?) and a monopropellant tank, both of which have fixed volumes. The rest of the usable volume is divided up into 35% RP1 and 65% LOX for the SPS engine. That's the contrived example. To parse this, start by setting the tank's remaining usable volume to its total volume, obviously. In this example, I'm gonna say that's 3000 liters, just to pick a round number. Now iterate over the "TANK" nodes. For each one of type "fixed," divide the maxAmount by the utilization and subtract that from the remaining usable volume. In pseudocode: remainingVolume = volume foreach tank { if tank is fixed { remainingVolume -= tank.maxAmount / tank.utilization } } Just to walk through that, in this case we'd start out with a volume of 3000 liters, then subtract 10.0 ÷ 0.9 from it (2988.8), then subtract 1.0 ÷ 0.9 (2987.7), then subtract 200.0 ÷ 0.85, leaving us with about 2752.5 of remaining volume. Then we iterate again, looking this time at the proportional tanks. For each one, take the remaining usable volume, multiply it by the amount (which is a fraction less than or equal to one), then multiply by the utilization. foreach tank { if tank is proportional { tank.maxAmount = remainingVolume * tank.maxAmount * tank.utilization } } Here we have two proportional tanks, RP1 and LOX. For RP1, that'd be 2752.5 liters × 0.35 × 0.85, or about 818.9 liters. For LOX, it's 2752.5 liters × 0.65 × 0.80, or 1431.3 liters. If we add it all up to check our work, we have the 10 liters of O₂, the liter of CO₂, 200 liters of hydrazine, 818.9 liters of RP1 and 1431.3 liters of LOX, all of which come to a total of 2461.2 liters, giving us an overall utilization fraction of 82.04%, which is right on the money. Now, just to reiterate, this is only a suggestion. I think this would be an easy-to-use, (relatively) easy-to-code and pretty darned flexible system for allocating tank volume. It wouldn't be way better than what you have now, but I think it'd be better, and if I'm suggesting you need to open up the patient anyway, 'cause of my aforementioned bug, then I think changes along these lines might be worth considering. Bottom line, though? Spectacular mod, as always, and thanks very much for it.

Ok kerbals, we have run into a problem. We have been funded for a mission to Duna (hooray!) Yes, that was our, um ,reaction as well. We thought it was cause for celebration too... How can I put this? We drank the budget. Most of it anyway, but we still have to do a mission to Duna. We would have to close the program and get proper jobs otherwise. One more thing, our funding next year depends on how cheap we can get this done. Each part costs money and all that mass doesn`t grow on trees, well except for the parts Janfer over there makes but we won`t go there today. Right get busy! We have jobs to keep! Make it flimsy! Make it cheap! Funding next year (In M£) EDIT : adjusted funding to make things more `interesting` Under 25 Tons £150 Under 30 Tons £100 Under 50 Tons £50 Under 80 Tons £25 Under 150 Tons £10 Added to Under 7 Parts £150 Under 10 Parts £100 Under 25 Parts £50 Under 50 Parts £25 Under 100 Parts £10 Mechjeb is allowed to fly your creation, this is an engineering challenge more than a piloting challenge, but there must be a kerbal on board for the press conference later and the mission must be a success. The kerbal must walk on the surface of duna and return. Make sure you take photos so we can convince the bosses we really spent the money. We don`t care what shape the ship is in when is returns as long as the guy you send out can walk up to the mic and talk into it afterward and say he went. Screenshots will be proof, your kerbal must survive. A posted craft file would be nice then we can reproduce the shockingly cheap journey. Please list all mods. I have made a quick attempt. I had a part count of 78 and a weight of 46 tons so my score is £50+£10=£60. I may try to shave a few parts and tons and see if I can get mre funding later but I wanted to post the challenge. I ended up landing with 1000Dv of fuel left so there is a lot of room for imrovement... I used Mechjeb and one of the engines from either KSPx or Novapunch (the one on the lander) Here is the craft http://www./view/c8densm7ne659a0/Munjet_Va.craft Current Leaderboard Mod 1, Adammada 20 parts 12.42T £200 2, John FX 78 parts 46T £60 3, 4, 5, Stock 1, Frash23 6 parts 29.5T £250 2, Metaphor 7 parts 29.7T £200 3, 4, 5, Overall 1, Frash23 6 parts 29.5T £250 2, Metaphor 7 parts 29.7T £200 3, Adammada 20 parts 12.42T £200 4, John FX 78 parts 46T £60 5,

True, I suggested infinite talk with pirate, but one of their team members made it very clear that it is all up to him. Well, it's a game of wait an see. .

Don't worry, I think we can all see you're working pretty hard A bit off topic though, I've just been wondering why you were on leave. I can see that you're working on a few projects on the forums and unlike Claira, HarvesteR didn't state a reason of why you were on leave :l I'd understand if you couldn't talk about it but I didn't see any harm in asking

*Facepalm* That might be it... I know I used 0.19 configs for the initial part setup and never updated it... Thanks, I'll get right on it! I think the lack of "PART{}" was contributing to the loading issues you had and not the raycast derping, since the parts that have the solar heating module were based of of 0.20 configs. Again, I think the issue is the code getting the collider(s) every frame and not using a single collider found in OnStart (or potentially OnLoad). I'll still probably talk to one of the devs to see if I can figure out what they're doing and what I might be doing differently/wrong.

I understand, but I don't. If I live on the 46th floor of the building, it takes less effort for me to get to the swimming pool on the 50th than it does for a guy coming from the lobby. I mean sure, I had to get myself there in the first place, and I had to lug all my food up there, but those are sunk costs by the time I start my climb from my front door. I don't start more tired than the guy in the lobby. Would it make more sense if I said "It takes less fuel to launch interplanetary transfers from a high altitude..." rather than talk about efficiency?

You should talk with Pirate... he's making canister based anti aircraft missiles like SEA RAM and Patriot... so his mod could complement your mod. XD.

10/10 There are only so many creative things to say about people I talk to daily...

One more day and the current mission objective will be complete! Jeb decided that the Grasshopper VTOL offered the quickest and most versatile platform to hit the last two known anomaly locations. After taking off, he set course due east: He discovered yet another floating monolith, this one even higher than the previous: The VTOL is proving to be a very capable platform and sufficient fuel remained to continue to the next point and still return to KSC, so Jeb set course for the last remaining anomaly: He noted that no lights are currently installed on the aircraft and that he would need to talk to engineering about correcting this. He arrived at the final location only to discover that it was in fact an almost complete Space Center. The radar station appeared to be operational, but no landing strip could be seen and there were no signs of activity otherwise. After placing a beacon/flag, Jeb hopscotched the VTOL to the top of the ridge to snap a few pictures for further analysis: MISSION OBJECTIVES COMPLETE! Now it's up to the management back at KSC to decide what the next mission series shall be. Rumors abound about the Mun and a substance called "Kethane"....

I was reading all the trash talk in the SC2013 forums and feeling disappointed about that game. Lo and behold I saw a post about a sim game that was actually fun it was about ksp. I got the game the day it came out on steam and haven't looked back!!

I'm sure they would surely like it - talk about designing and launching rockets at your heart's desire without budget restraints and other complex shenanigans

Banned for you're one to talk!

You wanna talk no music? http://youtu.be/VpnuubCJjCU I'm so sorry... T_T

The truth has been spoken but then again how can we even begin to talk about reality? Our kerbs survive centuries in space inside the equivalent of a mercury capsule. We can create thrust from spinning fuel tanks and fly forever in gliders. Oceans have the density of lead and planets are denser than Uranium by a fair bit. I will forgive the lack of realism for the sake of art but more importantly because of the GODLIHOOD OF JEBEDIAH AND MOAR BOOOOSTERS!!!!! (please don't even try to disagree with jeb)

You don't have to pretend that it is "balanced", because if it really were, why didn't you use the stock rockets? why did you choose this one? Obviously its advantages far outweigh the disadvantages and therefore not balanced. If such mods could be used, your challenge becomes pointless because I can always make an engine with even higher ISP, lower weight, and huge thrust. Hell, even warp drives are undergoing "theoretical work", somebody had done some math at least right? besides, If you really want to talk about realism, any sort of energy based propulsion technology, whether it's electric or nuclear, must deal with radiators, especially the high ISP ones, because they use more energy per unit weight of propellant. Such engines will require huge radiators which cannot form angles of less than 180 degrees with each other because it will radiate into other radiators and therefore loose efficiency. This limitation will render your massive fission rocket array totally impossible because just one of those rocket will need a radiator bigger than the rest of your ship combined. And no, it is not simulated by the large heat generation because the game has no accurate thermo model. If it did, your engine would over heat, and it would take ages for them to cool back down again. In the end, you might as well carry less engines and burn them for longer. Making an engine that will overheat by itself is just a stupid design for so many reasons. First no engineer would be stupid enough to make it that way, there would be some kind of built-in limit to prevent it. And secondly, it doesn't give you any legitimate challenge to the game because you can just keep it under a certain thrust and it will never explode. Might as well just make the max thrust lower. And thirdly, it's just plain annoying because you can't control engine thrust separately, if you have this and other engines running at the same time, those would also loose thrust.

I had heard people talk about it in the Beamng forums but never really looked into it. One day someone said something about it in some thread and I had nothing else to do, so I googled it and downloaded the demo. That was back in march. I didn't join the forums till April and got the game in early may. I'm completely hooked now.

From a magazine which talk about the demo (the old 0.13.3) and how to build our first rocket. I download the demo and bought the game few days after.