Northstar1989

I don't think I explicitly addressed that- so you didn't miss anything. On critically fuel-limited missions (such as when moving extremely heavy payloads, where it's just not possible to cram in enough fuel tanks for a robust Delta-V budget), the best strategy is to perform what I like to call an "Oberth Dive" from Minmus. Basically, it works something like this: (1) Set up a refueling depot in low orbit around Minmus. (2) Refuel your interplanetary vessel there (3) Perform an ejection burn with your interplanetary vessel from Minmus orbit such as to return towards Kerbin with a low periapsis BUT NOT ENTER THE ATMOSPHERE. How low of a periapsis is fuel-optimal depends on how far away your target is from Kerbin Delta-V wise (and how fast of a transfer trajectory you opt for- if you opt for speed over fuel-efficiency). (4) At or near periapsis with Kerbin, perform your transfer burn towards your intended destination (obviously, this requires some planning in advance such that your burn/periapsis is at the correct Angle to Prograde) The large fuel-savings from both the Oberth Effect and the high velocity you will already have when beginning your ejection burn make this method extremely effective. Note that you will still need a substantial TWR for an accurate ejection burn (lower TWR will require a large adjustment burn later- though this may be worth the reduced engine mass, and corresponding increase in Delta-V) despite the small Delta-V of the ejection burn, as your Angular Velocity will be VERY high at periapsis, leaving you a very short window to make an accurate burn. For even more fuel-critical missions (I've utilized this method once before when I was sending a SSTDABK-capable spaceplane to Duna on a very suboptimal transfer window) you can set up a full fuel tanker in the same orbit around Minmus, but at a slightly later phase- such that there will be enough time to switch to it and perform an identical ejection burn from Minmus when in reaches the same Angle to Prograde as your interplanetary vessel made its ejection burn... You then have the fuel tanker match the transfer burn near Kerbin, and rendezvous with the interplanetary vessel as it is on its outbound trajectory to provide the necessary fuel for the adjustment and capture burns at the destination (any fuel needed for the return voyage can be more easily/cheaply provided be fuel tankers in orbit of the destination- which can be sent either ahead of or behind the interplanetary vessel, with much lower TWR). Note that this will require substantial skill/knowledge in both orbital maneuvering (MechJeb will help, but even then you need to know how to make use of some of the more advanced maneuvers it can plot) and rendezvous, as well as as a high TWR on the fuel tanker to help it make an accurate burn to follow/rendezvous with your outbound interplanetary vessel. The actual docking is no more difficult than one in a normal orbit though- simply match velocities at closest approach (by burning along the retrograde vector of relative velocity in "Target" mode), get closer, match velocities again, and repeat ad-infinitum as usual until you're close enough to dock the two vessel with a simple burst of thrust (from the frame of reference of the fuel tanker/ interplanetary vessel, the two vessels will be stationary relative to each other when their velocity is matched and distance is small, even if hurtling towards the edge of the solar system at thousands of meters/second). Regards, Northstar

Altitude ceiling in excess of 7000 meters on Duna are easily achievable using Firespitter propellers on Cargo Throttle and either a 0.625m KSP-Interstellar fission reactor (which is relatively lightweight) or stock OX-STAT solar panels (which are massless and dragless with their current Physics Significance setting, as are the radial batteries). The key is using multiple (generally more than 4) propellers, low wing-load, and "Cargo Throttle" which increases propeller thrust by 50% when you trigger the appropriate Action Group. At high-altitude on Duna, the corresponding 50% greater energy-consumption (ISP remains the same) on Cargo Throttle is laughable, as thrust still remains extremely low (and energy-consumption is proportional to actual, realized thrust: not thrust at Kerbin Sea-Level). Regards, Northstar

I'm going to have to argue STRONGLY against extra points for simply having life support (and the points for extra life support supplies fit perfectly well under the existing "Cargo" rule). As it currently stands with mods like TAC Life Support, most crewed command modules (and even utility modules like the Hitchiker) have built-in life support systems. Enough for up to 3 days, actually- which is more than enough time to circumnavigate Duna, even with a slow electric-propeller aircraft (the only aircraft that could conceivably take longer than 3 days is a helicopter- like my Hornet Helicraft currently en-route to Duna). So, life-support doesn't actually add any weight in itself, as no new parts are required- only for the actual life-support supplies themselves: which can count as Cargo-mass in the same manner as Kethane (except counting even life-support that IS consumed during the flight). Lfe-support recyclers, and the mass of the supplies themselves which can be held in a command module or extra tanks (or removed to same weight- Kerbals can survive something like 6 hours on the life-support built into their EVA suits with TAC Life Support: which is massless, and enough for a fast cricumnavigation in vessels like the TESLA II) can be counted as Cargo weight: in the same manner as unburned Kethane, and Kethane drills. In short, Geschosskopf, stick with your own values- keep the rule constant. Arguments that life-support adds weight which is somehow different from cargo-weight hold little water: the supplies Kerbals need are carried in their EVA suits when in command chairs (for no extra mass, and flights up to 6 hours) or in the command/utility modules themselves (extra mass, but can easily be counted as cargo by measuring mass with/without the extra supplies, and can be removed for flights less than 6 hours), and so in no way necessarily weigh down a Duna plane for the short flights needed to meet this challenge. Rewarding players for using life-support mods simply rewards them for having extra RAM on their computer to run them: as I've clearly outlined, TAC Life Support doesn't necessarily have to add any mass or parts at all to a Duna plane for flights lasting less than 6 hours (and the extra supplies can count as cargo for longer flights). Regards, Northstar

The Aquarius was designed to allow a 1/3rd *failure* rate. That's a 2/3rd success rate, not a 1/3rd success rate. And that's not saying 1 in 3 launches WOULD fail- only that the rocket was designed with that considered as an acceptable failure rate: http://www.astronautix.com/lvs/aquarius.htm Aquarius was designed for launch of things like fuel and ISS supplies to orbit, *not* probes or satellites- things that would be needed in bulk (necessitating many launches- as the payload capacity was low), and could be cheaply/easily replaced. "ISS consumables demand alone supported between 17 and 80 metric tons of basic supplies annually, or 20 to 100 Aquarius launches per year." Over the course of four or five dozen small launches like that (over the course of 1-2 years), the 1/3rd failure rate would have averaged out to statistical noise, and the overall cost-per-kg to orbit would have been extraordinarily low. At $1,000/kg and $1 million/launch, with the rated 1000 kg/launch payload capacity, you could launch more than thirty 1000-kg payloads to LEO on an Aquarius (with an average of 20 payloads reaching LEO) for less than HALF the $61.2 million cost of a Falcon 9 v1.1 launch, which can lift 13,150 kg to LEO in each launch (http://en.wikipedia.org/wiki/Falcon_9_v1.1) Aquarius could also be used to launch fuel for interplanetary missions (the mission profile called for automated docking and fuel transfer). The mission vehicles would be launched dry, and fueled up with Aquarius launches. Thus, the low-cost, easily-replaced component of missions (the fuel) would be launched on low-reliability vehicles, while the high-cost difficult-to-replace mission vehicles (probe missions, manned vehicles, etc.) would be launched on other high-reliability launch vehicles. In fact, of the $700 million proposed development cost, only $150 million was for the Aquarius launch vehicle itself, the remainder was for the development AND launch of two unmanned orbital tugs (which would act as unmanned fuel tankers for fuel payloads) and a high-tech cryogenic-storage fuel depot. In summary, the designers made this historical analogy: "Bread was delivered by a bread truck, not a Brinks truck" All-in-all, a great example of another "Big Dumb Booster" design (so-called not for its payload capacity, but its low efficiency and cheap construction) that was rejected without very good reasons. Regards, Northstar P.S. It's also worth mentioning that Aquarius was a SSTO design (reaching a very low 200 x 200 km orbit), utilizing LH2/LOX from the launchpad- meaning it had quite a bit of launch-vehicle dry mass that would also reach orbit with the payload. If the launch stages were towed to "graveyard" orbits by orbital tugs, instead of de-orbited as planned, then you would have a substantial basis for an orbital-scrapping operation some day in the future... Each Aquarius was planned to have a dry mass (after disposing of all propellant, RCS propellant, and tank pressurant) of 10.0 tons (with a 0.5 ton margin). Meaning each launch really nets you a 1.0 ton payload, and a separate 10.0 ton piece of scrap material- some components of which you could eventually (with further developments in orbital infrastructure) recycle to build things in orbit...

Kind of my point- fuel isn't the cost-driver, so why bother with efficiency on the launch vehicles? Steel (rather than aluminum, advanced alloys, and composites) rockets are cheaper (as steel is easier to machine), and more durable relative to the level of engineering that goes into the rocket- they're just not as efficient. But since efficiency isn't the main cost-driver, why bother using aluminum? I've known a lot of engineers over the years (in fact, I come from an entire family of engineers- I'm the only non-engineer in the bunch), and they ALL seemed obsessed with efficiency in any design, really just because it's cool... I've tried pointing out to a number of engineers that a bridge, building, or rocket could be built much more cheaply if less money was spent optimizing the design for efficiency, and just building "quick and dirty" with wide safety margins- but none of them ever seem to listen. I think a big part of the problem is that they don't count the engineering man-hours as part of the cost in their minds, since to them it's more like play than work when they're doing something they love... Regards, Northstar

This is a suggestion geared towards Budgets, which I understand will be coming out 'Soon' . There's already a count on how many of a part is "in Stock", even if it currently doesn't do anything. So I imagine at some point, a part-purchasing or supply scheme will be coming into effect (maybe with Budgets, maybe later). What I would like to see, quite simply, is a system for purchasing rocket engines (by far the most important part) in batches, instead of individually. The reasoning for this is that it would create realistic and interesting in-game incentives to stick with older technologies, rather than switch to newer engineering (from 1.25 meter engine clusters to 2.5 meter engines, for instance), and would also create benefits to doing things like re-using the same engine type for upper and lower stages when neither would otherwise have a cost-advantage. Bulk-purchasing would reflect real-life economies of scale and mass-production, and real choices rocket designers face, in a simplified (and fun) format- rather than implementing a more complex part-cost mechanic. It would also reduce the tedium of purchasing rocket engines a bit, if this ever becomes a mechanic (one click buys 20 copies of a part rather than just 1, with a bulk discount). I think it would simplify gameplay and ease the burden on players if only rocket engines were limited in any meaningful sense- which is why I limit this suggestion specifically to engines. Regards, Northstar

After reading up on the Sea Dragon concept of the late 1960's, I've come to the conclusion that we're over-thinking this whole rocketry business. http://en.wikipedia.org/wiki/Sea_Dragon_%28rocket%29 You see, the concept of Sea Dragon was simple- it's a LOT cheaper to build a large, heavy, powerful, sloppily-designed rocket that can lift the same payload to orbit with a lot greater inefficiency; than it is to build a carefully-engineered, narrow-tolerance rocket like most current US rocket designs. This concept is known, quite simply, as "the Big Dumb Booster principle". http://en.wikipedia.org/wiki/Big_dumb_booster So, why do we waste so much effort on ultra-engineered rocket designs, made out of fragile composites and high-tech alloys, when it would be a lot cheaper to slap something together out of corrugated steel and just launch the payload to orbit on THAT? It's not like we've been re-using any of our current rocket designs, anyways... The current US approach to rocketry strikes me a bit like building a Ferrari just so you can take it on one short drive off the edge of a cliff, when any old junker would do... My best guess is that we're not ACTUALLY utilizing our current approach because it's cheaper or more effective (because it's not)- we're utilizing it because of lobbying (launch companies can charge more for high-performance designs) and because politicians want to generate more jobs in the space industry for political reasons... Please discuss. Regards, Northstar EDIT: See also the posts and links below on the Aquarius Rocket- a more modern cousin of the Sea Dragon proposed for initial launches in 2005/2006.

Must be some kind of record!

@Raven I posted the info for all the planet's in Krag's Planet Factory except Pock (which I can't seem to find the data for anywhere out-of-game, but it's a moon of Erin a lot like Pol). Take a look at it, and see what you come up with. Regards, Northstar

Thanks- but what I really need is the thread author's permission... Best luck!

This is a simple question: could somebody provide the hard numbers (*specific* altitudes) at which spacecraft disappear on all the planetary bodies with atmospheres besides Kerbin? (Eve, Duna, Layther, and if you're playing with Krag's Planet Factory both Erin and Skelton) I need the information- particularly for Duna- to eventually build heavy Space-X style reusable launch vehicles for bases on the different planets. Those of you not in the know: NO, it's NOT 23 km for all planets. It seems to be set based on a combination of atmospheric density and possibly gravity for the different planets, for instance I know it's lower than 23 km for Duna- even though I don't have the specific numbers I need. Regards, Northstar

I know this may seem like a weird question, but does anyone have the default orbital parameters of Sentar? I can't find the data anywhere- the config just says it's not configurable in a comments section- which is the only thing visible to me when I open the file. I'd appreciate it if you PM'd me the answer, just so I don't have to try and find it over a week after it was posted (I'm leaving town soon on vacation- no computer access) in this EXTREMELY busy thread. Regards, Northstar

I just KNOW somebody who doesn't have experience with KSP-Interstellar is going to come around and criticize it as "cheaty" or "OP'd", and the thread host will believe their (unfounded) claim, and that will be the end of my request to utilize KSP-Interstellar Microwave Beamed power for some realistic and innovative mission strategies for this challenge... So I'm going to pre-empt that with some concrete examples of how it's not really OP'd. You guys are lucky here- I'm sharing these screenshots on this thread before even posting them to my ongoing Mission Reports thread. Anyways, take a look at this picture: 8.34 Gigawatts of beamed power- seems like a lot, doesn't it? And it is- it took me no fewer than NINE enormous 3.75 meter reactors and two 2.5 meter reactors (as well as corresponding generators, control, transmission, and heat-management equipment), all of the highly advanced Solid Bed Molten Salt Reactor variant, which is a bit more advanced than the Liquid Fluoride Molten Salt Reactors I've requested to use for this challenge; a 2.3 MW solar array, and several smaller solar arrays to obtain that much electricity- more than 40 GW at the sources, but only 8.3 by the time it reached this spacecraft! But want to guess how much thrust I'm obtaining using that in an appropriately-sized plasma thruster? (a real-life type of electric propulsion, that actually can be scaled up to such mind-boggling power levels- if only our spacecraft had access to that much power...) Not coincidentally, the size of it I used has a maximum rated power capacity of approximately 8.314 GW, so this is at MAXIMUM power for a thruster of this size, with realistic ISP and Thrust levels (unlike the stock Ion Thruster, the KSP Interstellar ion thrusters DO NOT have higher Thrust-per-kW than their real-life counterparts) and based on use of Hydrogen as a propellant (optimal in ISP for this thruster type, but lower in thrust than heavier propellants)- which KSP Interstellar takes LiquidFuel to represent... 56.8 kN. You read that right- FOR MORE POWER THAN I COULD HOPE TO LAUNCH FOR MY ENTIRE MASS BUDGET FOR THIS CHALLENGE, assuming I launched nothing but nuclear reactors, I only got 56.8 kN of thrust. Which adds up to an anemic TWR of 0.15 for this craft... It's more powerful than the stock ion thruster, to be sure (though it actually gets much less thrust per kW of electricity). But it's certainly not a game-breaker. And it *IS* realistic technology- real life electrical engines could get this kind of thrust and ISP (in many cases, ISP increases with power levels in real life electrical engines) if they had access to 8.34 Gigawatts of power (and they could have access to 8.34 Gigawatts of power if NASA would just suck it up and pay for a Microwave Beamed Power network instead of shuddering at the initial-investment cost of $2 million a MW for both the generation capacity and transmission capacity to do this at small-scale: and costs decrease as this is scaled up) And some of you might be wondering why this thruster (or the Microwave Receiver dish) didn't melt at this power level. Well basically, they did- or rather they rapidly heated up, and quickly overwhelmed the limited mass of coolant and radiator I built into this spacecraft (approximately 200 kilograms' worth)- the engines could only run like this for about 20-30 seconds before things began to overheat and went into Emergency Shutdown: And at a heat-dissipation of 8 Megawatts of WasteHeat a second at close to maximum-temperature of 3500 Kelvin (if I had actually reached this temperature, things would have begun to explode), this is going to take a LONG time for the spacecraft to cool back down... (heat-dissipation via radiation follows the Stefan-Boltzmann Law, meaning it increases or decreases with the fourth power of temperature. WasteHeat is going to start bleeding off a LOT more slowly as the spacecraft cools...) Of course, this was a flawed design, and entirely my fault- I built the ion transfer tug you see here with far too light of a heat-management system (with a half-dozen or so metric tons of equipment/radiators, heat levels like this could be handled...) But I think it gets my points across that the modern-era technologies such as these (as opposed to later futuristic technologies) of KSP-Interstallar that I want to use are FAR from a "free ticket to Duna". Regards, Northstar P.S. For those of you curious, the spacecraft pictured here is a tug docked to a reusable lander hopefully destined for the Sentar system (a second gas giant, analogue to Saturn, added by Krag's Planet Factory mod), which should explain to you why it has such insane mass fractions for an ion-powered craft. And yet, it will probably end up using 1/5th-1/6th of its Delta V just to get a minimum-energy intercept with Sentar. The leftover fuel is NOT for a return journey- I prefer to send my craft on much higher-speed transfers than necessary, to role-play reduced radiation-exposure and psychological stress on the crew, so it will be accelerating towards Sentar until it has used over 60% its Delta-V, with the remainder being used to reduce the G's of the aerobrake by a last-minute deceleration before atmospheric entry, and to rendezvous with the crewed modules which will also be arriving on fast transfers...

I wouldn't consider the last four to really be a different universe or game mechanic- just a different scale. It's still the same rocket equation, the same landforms, etc. and I think it's the only valid way to "Stock-itize" mods like Real Solar System to some degree at this point- though I really think KSP should have been built to an at least 20% or 25% scale in the beginning, rather than a 1/11th scale... Thanks for the compliments! You're probably right- I'll delete that aside begging for rep. Regards, Northstar

That's a LOT of solar panels- have you ever considered installing the NearFuture propulsion pack just for its Megalador solar panels (bigger than the stock Gigantors). You could even delete all the other parts from the pack and just keep it for its larger solar panels- though its Dual-Stage Four-Grid ion thrusters would serve you well with their much higher ISP ratings (19200s- they match real-world examples of that technology), great for your cyclers... I know you're against using mods for the challenge- but you might want to give it a try. HOW, exactly? The only way I know of to beam Microwave Power is with KSP-Interstellar, and I don't see a Microwave Transceiver anywhere on it (the dish there looks like a large stock comms dish or an Interstellar Microwave Receiver- which is capable of receiving, but not transmitting or relaying, Microwave Power). I'm guessing this is just meta-gaming, and you don't actually have a beamed-power network in place? You COULD install KSP Interstellar, though, and beam the power from that satellite to your Duna base(s) using the Microwave Beamed Power system in the mod, though. Only, don't expect very high power output at Duna-distances when running the mod, even with that many solar panels- KSP Interstellar also implements a realistic Inverse-Square law for stellar illumination of solar panels, meaning your solar panels will produce even less power at Duna-distances (but more power at Eve-distances) than you're used to, as stock KSP doesn't implement a realistic rule for stellar radiation with distance... (it's too flat- power production doesn't increase or fade quickly enough with increasing/decreasing distance from the sun) Regards, Northstar

Excellent thread so far. I particularly like the Cycler idea as a solution to the extra living-space and supplies needed for the challenge (it doesn't make sense otherwise- as you are essentially spending all the fuel for a high-energy transfer or carrying the life support supplies for an extremely-slow transfer, depending on the Cycler design used). You might try use of Solar Sails (from KSP-Intersellar) on your cyclers as a more sustainable (zero-upkeep) method of making EXTREMELY small orbital adjustments. Hmmm, that's good to know! I just entered an inquiry on the thread about the use of some mod parts from KSP-Interstellar (Molten Salt Reactors, Plasma Thrusters, Microwave Beamed Power, Solar Sails, Thermal Rockets, and Thermal Turbojets based on beamed-power) that represent technologies feasible in the current day and age (everything on that list but Molten Salt Reactors) or the very near future (Molten Salt Reactors) which simply haven't gotten enough love from NASA for one reason or another... I can wait for his reply though- I have a lot to do in my current Career save before I decide it's time to delete it and re-install KSP with new mods... (my major full-scale Duna colonization effort- which will provide me with experience and some insights for the challenge, even if I'm using banned mods such as Extraplanetary Launchpads; a Sentar system flags-and-scoot mission; and ongoing preparations for a Munar outpost) Regards, Northstar

I would like to attempt this challenge in a future save (I have been eying it for a while), BUT I have the following concerns I would like to address first (and argue as necessary) regarding mod usage: (1) First of all, I would like to carry out this mission making use of as much In-Situ Resource Utilization as possible (like *REAL* NASA mission-plans). I'm not really a fan of Kethane, so instead I would like to make use of KSP-Interstellar for its ISRU refineries and small Thorium-fueled Molten Salt Fission Reactors (a next-generation reactor technology, China optimistically estimates it will have in mass-production in 10 years) to power the ISRU refineries. I'm not planning on using anything crazy or OP'd like gas-core fission reactors, fusion reactors, antimatter reactors, or the DT-Vista engine; although I would also like to make use of Thermal Turbojet planes (a technology designed in the 1950's/60's but never put to use) for Duna-mobility, as well as Microwave Beamed Power (we've had the necessary technology to do this since the 1960's, and to do it at an price affordable since about 2005), and Nuclear Thermal Rockets (the more realistic KSP-Interstellar version of NERVA) in extra-atmospheric conditions. I can foresee concerns about radiation pollution from nuclear-powered Thermal Turbojets, the same way as for NERVA use in Duna's atmosphere (although Indirect Cycle thermal turbojets or rockets would eliminate much of the radiation hazard), so I would like to use Microwave Beamed Power to beam the power for the Thermal Turbojets to my Duna aircraft using Microwave Beamed Power and Thermal Receivers, and keep the reactors (and all the radiation) safely in sealed stationary reactors on the ground on Duna or in orbit of Duna (although this scheme involves power-loss of the beamed power over both distance and through the atmosphere, it keeps the radiation and reactor weight both safely on the ground). The Microwave Beamed Power I can see as being the most possibly contentious issue, so I would like to set some rules in advance about how many MW of it (if any) I am allowed to use ground-based at the KSC (mainly to power electric or thermal propulsion systems for trans-Duna-injection) or from solar-power satellites deployed as part of my mission payload limits, but not sent towards Duna- instead sent towards Kerbol and Eve orbit where there is more sunlight available... (the same rules applying to use of aerobrakes at Eve as with Duna of course- in fact I might install Deadly ReEntry just so nobody can question my craft survivability, and because I think the stock placeholder-system for this challenge doesn't allow enough engineering creativity in how to handle re-entry heat...) Also, last, but not least, I would like to consider usage of the KSP-Interstellar plasma thrusters (with power levels available from onboard KSP-Interstellar Molten Salt Reactors, they actually under-perform stock ion engines in terms of TWR due to the heavy reactor- they're only better with Microwave Beamed Power, in direct proportion to the amount of power received) and Solar Sails (if I can figure out a mission plan that can actually use them to get any reasonable mass of Cargo to Duna in under 1000 days- most likely they'll just be used for slight adjustments of approach trajectory due to their EXTREMELY low thrust even in time-warp...) Once again, these are all real-world technologies available today (or in the special case of Thorium Molten Salt Reactors, within the next 10-12 years if China's plan is a success) and well-balanced against the rest of the KSP Interstellar mod (which also adds the need to add radiators to my spacecraft- including stock-only craft, for extra mass). Links on Thorium Molten Salt Reactors (note that the same reactor design can also be used with Uranium) http://blogs.telegraph.co.uk/finance/ambroseevans-pritchard/100026863/china-going-for-broke-on-thorium-nuclear-power-and-good-luck-to-them/ http://www.the-weinberg-foundation.org/wp-content/uploads/2013/06/Thorium-Fuelled-Molten-Salt-Reactors-Weinberg-Foundation.pdf http://energyfromthorium.com/2014/03/21/the-molten-salt-reactor-race-will-america-join-the-race/ http://www.whatisnuclear.com/reactors/msr.html (2) Second, I would like to make use of an addition mod in the spirit of In Situ Resource Utilization- CELSS Greenhouse mod. Basically, in combination with TAC Life Support (which I would also have to install in order to do anything) it allows you to build/launch greenhouses as components on your ship. They consume ElectrricCharge and waste-products (CO2, Waste, WasteWater) from TAC Life Support to produce Food, Oxygen, and Water in a closed-cycle life support system. Now before anyone goes calling this overpowered, they are QUITE HEAVY, and the length of time one has to be in continuous operation in order to convert wastes into as much Food, Water, and O2 as its own weight is something like 1200 days- *LONGER* than the length of time of the challenge. So, my purposes in making use of the mod would be more for flavor and roleplaying ("crew morale") rather than any sort of actual advantage. It would also save me a headache on supply-missions, being able to simply launch a few big, heavy greenhouses and then not have to worry nearly as much about resupply in the future- though I could just as easily launch a lighter giant TAC Life Support barge to Duna orbit (and ferry the modules with a reusable-rocket deriving its fuel from Interstellar-ISRU or Kethane as necessary) to accomplish the same thing for less mass, and allow my outpost to continue to be sustainable past the end of the challenge... Regards, Northstar

In-orbit assembly is always !FUN! And by fun, I mean that in the Dwarf Fortress way- boring, tedious, and with the potential for great disaster (luckily no incidents this time). Still, here it is... First of all, the docking of the Sentar System Lander (SSL) with the Sentar Transfer Vehicle (STV) Mk2: The SSL broke into two pieces, for more stable (and less Kraken-prone) interplanetary transfer... The Lander itself remained attached to the small conical transfer vehicle (what I referred to as a "drop tank" before- containing over 83k m/s Delta-V with just the lander attached!) The Service Module, meanwhile, undocked from the Lander and rendezvoused with the STV Mk2. It also stole some LFO from the launch stage of the STV Mk2 that made it to orbit- the LFO will be necessary to refuel the Lander between sorties (the SMV also contains a quarter-load of additional LFO, which will probably be required at some point). The Service Module holds EXACTLY enough for two full refuelings of the Lander- which means enough fuel to rendezvous with the SMV in orbit of Erin or Sentar (to pick up Kerbals) using the STV Mk2 (which will stay with the SMV to act as the then-renamed Return Transfer Vehicle), position the Lander for ground insertions (refueling from the SMV at some point in the series), refuel the Lander one-and-a-half times (a Pock landing can be done on a 1/2 fuel load) for a total of three landings (Erin, Skelton, and Pock: the Lander reaches the Sentar system fully-fueled), and *just barely* reach the Sentar Mission Vehicle with the Lander (and Kerbals it contains) attached- possibly without (for a return to grab the Lander once refueled with pure LiquidFuel stored on the SMV) if landings prove especially costly... Meanwhile, the Sentar Mission Vehicle (SMV) itself moved into a higher orbit around Kerbin, where it rendezvoused with a short-range, rather archaic (chemical, despite beamed-power thermal rocketry providing both better TWR and ISP) fuel tanker that had been in orbit over 2 game-months (since Project Amadeus/Williams) to top off its fuel reserves: The tanker then made a transfer-burn to the Mun to deposit its remaining fuel in the Munar Spacedock and join the growing list of decommissioned ships in Munar orbit, as new debris... (from a roleplaying perspective, most Lunar orbits are unstable- which can justify the constant fuel-runs to the Munar Spacedock as station-keeping fuel, for small station-keeping thrusters it would have been equipped with if necessary, and "Termination" of the debris as their having eventually crashed into the surface if I don't decide to restart my orbital debris-scrapping operations) Finally, for those of you wondering which mission component will be the first to depart for the Sentar System, it will be the entirely non-mission-critical Erin Seaplane. Due to the phasing and altitudes of the orbits, it will have the next transfer window to Sentar (remember, the ideal Angle to Prograde of ejection was approximately 160 degrees- meaning the Seaplane is already a bit past its idealized ejection angle in an East/West direction, as well as past Periapsis- but it also has not yet reached its Ascending Node- the best angle to eject with respect to the North/South component of its inclined orbit). Additionally, it makes the most sense to eject this module first- as it lacks any Microwave Transceivers (it is equipped with smaller Receiver dishes) that could be used to relay power from the KSC to the other mission components for their ejection burns while still in Kerbin orbit... Also, for those of you wondering- I still haven't decided what to do with the Sentar Mission Vehicle Mk1. It's become apparent that I won't need it to meet the primary mission objectives (reach Sentar orbit, make at least one landing on each of the three separate inner moons), and it won't help with attempting a landing on Thud (*shudder*- it has 3 G's of surface-gravity, 50% higher gravity than Eve!) or Ringle (like a different-textured Tylo- the lander can land, but can't get back to orbit without refueling on the surface). But perhaps I could use it to transport a fuel-lander for Ringle, or a parachuted-rover for Skelton... (which has a highly mountainous terrain with a dense atmosphere in the valleys that doesn't reach to the peak of the mountains... Due to its Duna-like low gravity, a landing on a mountain is probably preferable if I can't manage a difficult landing at a "sweet spot" of between about 0.5 and 0.2 Kerbin-atmospheres of pressure on a valley slope- enough to slow the Lander's descent with its parachutes, but not choke the engines when trying to ascend again...) Regards, Northstar

What you're describing is an Earth Orbit Rendezvous (ERO) plan, basically. There's no advantage in waiting to dock the modules until you get to Moon orbit (which is rather unstable) rather than docking the modules in LEO first and having them head off to the Moon together... Which is why NASA did *NOT* seriously consider a plan such as you are suggesting- any such suggestion was quickly replaced by an ERO plan. Saturn V wasn't the heaviest rocket proposed/designed, by the way. There was actually a competing series of rocket developed independently, in-house by NASA (Saturn was based of of Von Braun's rocket designs for the US Army), called Nova that would have been even heavier in some of its last revisions... But Saturn was considered more reliable and economical than Nova. Regards, Northstar

That answer has been made by at least one player to nearly every single suggestion of new features *EVER* made for this game... It's NOT adequate. Mods experience bugs that could easily be fixed with "Stockization" of the respective features (such as the bug I mentioned with Real Solar System terrain), and have to jury-rig code in unusual/inefficient ways rather than simple designing the code to do something. Adding some of these features as difficulty sliders makes them optional (so only players who want to can use them) or allows the same player to have two different saves with different settings without having to make two separate installations of KSP. Regards, Northstar

I hate to burst your bubble, but that's NOT how a Lunar (Munar) Orbit Rendezvous mission is done. The PROPER mission profiles involves the launch of a SINGLE rocket from Kerbin/Earth, which travels to Lunar/Munar orbit. The "Rendezvous" part of the title refers to the detachment of a lander module ONCE IN ORBIT OF THE MOON and then the rendezvous of the lander BACK WITH THE SERVICE MODULE AGAIN after landing of the Lunar/Munar surface: http://en.wikipedia.org/wiki/Lunar_Orbit_Rendezvous I don't know where this idea of a "Lunar Orbit Rendezvous" of being assembly of the mission vehicle in orbit of the moon came from (I've seen it on the forum before)- it's wholly inaccurate, NO ORBITAL ASSEMBLY IS REQUIRED FOR A LOR MISSION PROFILE! My best guess is that it's derived from players reading up on the Earth Orbit Rendezvous (which DOES require assembly of the mission vehicle- in Earth Orbit). There have also been some later hybrid proposals that used BOTH EOR and LOR, as they are not mutually exclusive: such as some versions of Constellation, utilizing the assembly of a transfer vehicle ("Earth Departure Stage"), a Service Module ("Orion"), and a Lander ("Altair") which would be separately launched and assembled in Earth orbit, and then proceed to Lunar orbit where the three would separate, and the Lander would perform an LOR descent/ascent, and the Service Module would return to Earth (in some versions, Altair would remain at a Lagrange Point refueling station, for future landings on the Moon) Regards, Northstar

Surprisingly, I couldn't find this anywhere on the Already Suggested list, so here goes: I suggest the eventual addition of scalable difficult factors in KSP. That is, factors you can adjust when creating a new save. The factors should include (but not necessarily be limited to) the following: Science Multiplier - A basic multiplier that affects the value of science rewards. This would affect the total amount of science available on each celestial body, for each experiment type. Science Transmission Factors - Adjustable factors to the maximum % science gain that can be attained from transmitting a given experiment type. I.e. some players might reduce this to 0% for all experiments- making transmission useless- or set it to 100% for all, so they never have to return experiments. Cost Multiplier - Works on Budgets. Would multiply by some number (could be less than 1 to REDUCE costs) the final cost of spacecraft built in the VAB/SPH. Could also be used for more "realistic" costs when combined with a higher Fiscal Reward Multiplier. Fiscal Reward Multiplier - Similar to Cost Multiplier, but scales rewards for completing contracts. This would be more an alternative for flavor, since the effect would be nearly the same. It might allow players to create a harder or easier "Start", though, by making starting cash (I assume there must be such a thing- and any allowances provided for "free" over time, if they come to exist) less or more valuable, when combined with a commensurate Cost Multiplier (for instance, cutting both costs and rewards by half would make the starting cash twice as valuable) Rocket Scale Factor - Adjusts the relative size of rocket parts (using the Rescale Factor already on parts). Want a rocket that's realistic-size, or on the same 1/11th scale as Kerbin, instead of the default 64% scale? Go ahead! Affects difficulty by affecting the ease of finding suitable landing sites- and affects drag (larger objects have better ballistic coefficients) once a realistic aerodynamics model is implemented, or if running FAR. Planet/System Scale Factor - Adjusts the relative size of the planets and Kerbol system (including distances from the sun and orbital velocities) by the selected factor- with the currently used 1/11th scale being the default (for simplicity, 3-4 settings could be available: Default/Fun, Miniature/Easy, Kerbal-Scale/64%, Realistic). Probably the most significant way players could adjust the difficulty- and allows KSP to satisfy both casual gamers and realism freaks, without having to take sides like the devs currently do on the side of having a "fun-sized" Kerbin and Kerbol system... ISP Scale Factor - Adjusts ISP ratings of rocket engines, within a certain limited range- allowing players to uprate ISP by 5-10% for easier gameplay, or down-rate it by 5-10% for a level more appropriate to Apollo-Era technology (current ratings closely match modern-day technology). By preventing a more than a 5-10% tweak, the look and feel of KSP can still be maintained within relatively tight bounds... Fuel Realism Toggle - Switches the current stock fuels (assuming they are not replaced) with more realistic fuels- that is, Liquid H2 (LH2), Liquid Oxygen (LOX), Kerosene, etc. This would probably be a feature added later than the other difficulty factors, but would go a long way to satisfy realism nuts, without forcing the devs to take sides... Re-Entry Heating Factor - Increases or decreases the production of re-entry heat (once implemented) or part heat tolerance ratings by a certain %. Like ISP Scale, probably only within certain limited bounds- say 15-20% up or down... Rocket Build Time Toggle - Implements build-time for rockets, the default being "Off". Probably not worth adding due to coding complexity except as a post-1.0 release (although it's already been implemented in some mods, so it can't be *THAT* hard to get right). I think that a difficulty system like this would go a long way towards making KSP appeal to a wider audience. It would allow more experienced players to turn up the difficulty (an in many cases also the realism- as with Planet/System Scale) to challenge themselves, while simultaneously allowing newer players to turn down the difficult while still learning. The realism-orientation of many of the difficulty factors would also allow realism nuts to set realistic values for the different facts, and be satisfied. I know of NO OTHER game that doesn't have at least some kind of difficult factor. Even other Indie games, like Faster Than Light, have at least an "Easy" and a "Hard" mode. As well as Sandbox games like SimCity (it affects your starting cash, Demand for growth, and the incidence of natural disasters, mainly) and the Civilization series. I think the devs ought to at least CONSIDER adding difficulty factors for KSP. Regards, Northstar P.S. I make no secret- I consider myself a "realism nut", and would appreciate more of a challenge in KSP. That is, I would GREATLY like to see more realistic scale, aerodynamics, etc. in KSP, and would probably play with up-rated cost factors. But I don't actually PLAY with any of the realism mods because they have too many bugs (Real Solar System, I'm looking at you- and your ground that Kerbals sink straight through), which could easily be resolved if the realism factors were designed into the stock game as a "hard mode" in the first place.

If they're actually at the same TIME, as in the same subspace, there are no problems whatsoever- aside from the obvious ones of players working out between each other who gets to dock to what docking port and how much fuel they can take, etc. No problems with causality or continuity, though. But a station is just another vessel, as KSP sees it. Naturally, only one of the players actually OWNS the station- the other is just using it on configurable permission (or perhaps a third players owns it and is allowing both to use it). You miss the fundamental impossibility of the problem you are bringing up- Player 2 cannot approach for docking in the first place, as he is not in sync with the station. Even if Player 2 could see a ghost of where the ship was predicted to be, based on its orbit in the past, he would have to know that due to floating-point errors, etc (which we already deal with in single-player when trying to plan a rendezvous- which is why you ALWAYS have to adjust your rendezvous as you get closer...) it would be impossible to know precisely where the station would be anyways. That's more an issue of control- namely, who is in control of the Station. If both players had somehow ended up sharing permission for time-warp, it would be their own stupid fault if they couldn't work out an agreement so Player 1 could finish his docking/refueling before Player 2 synced the station up with himself to allow docking/rendezvous. Pretty much. The issues with multiplayer you described are mostly inconveniences of players working out between themselves who gets to control the time-warp of shared vessels (the warp-master solution is just taking this to the extreme, where one player controls the time-warp for ALL vessels). It's not like other multiplayer games don't already have similar issues- the allocation of a limited amount of ammo/medkits between players in many FPS games, for instance. One selfish player can ruin everybody else's experience. Regards, Northstar

Also a great point

PRECISELY. I never even THOUGHT of building a pancake rocket, until I started experiencing how wobbly rockets used to be (they're still more wobbly than I would like, though- the joint strengths still don't scale up enough with larger diameter parts- a 2.5 meter node should be at least 4 times as strong as a 1.25 meter node, due to having 4 times the cross-sectional area). And, in fact, I have only built two or three pancake rockets EVER in KSP- and those were just test rockets, I never did actually figure out a good pancake design that wouldn't implode on the launchpad. Instead, I installed NovaPunch2 as my very first mod, and started using tall 5 meter rockets with 4-6 radially attached 2.5 meter SRB's for my super-heavy lifting needs. It works perfectly fine, and it's actually realistic. I've never relied on pancake rockets- the closest I ever came was a super-large (>12,000 ton on the Launchpad) StretchyTank SSTO Rocket that was both extremely tall *AND* wide, and still taller than wide- and that was more for lolz and scrap metal (I promptly recycled the rocket with a Scrapper Ship- I also was running Extraplanetary Launchpads and Orbital Construction by that point) than for real utility. If experienced players like me can get missions to Sentar (from Krag's Planet Factory) without ever once having relied on pancake rockets (though plenty of mods), with the CURRENT aerodynamics model, there's no reason to think other experienced players couldn't learn to adapt, or that new players will in any way be phased by a more realistic aerodynamics model... (which would REWARD realistic rocket designs with reduced drag) In fact, I was phased by the stock aerodynamics model right at the beginning- I've hated it since Day 1. That's why I installed Novapunch within a couple weeks of installing KSP for the first time- I didn't want to build pancake rockets, the very thought sickened me... Regards, Northstar