georgTF

I care not wheter it's called a planet or plant, i just wish it's historic significance were recognised. It shouldn't be reclassified because romantic notions cannot overrule scientific fact and proven falsehood. Also, what kind of mess would the classification system be if any planet were classified according to fact AND romanticised indulgencies. I am only sad that a representation of the solar system counts 8 planets and stops at Neptune because i am so used to there being a lonely and out of place ....ty little rock at the end of the list. Put a big asterisk next to it, refer to it by an insulting or silly classification, i don't care just put it back on the list. We no longer draw silly mermaids, giant squids or Lovecraftian monsters on maps of oceans and we certainly shouldn't but at the same time we killed off a little bit of romance and made the style way to factual and boring. We can't will ourselves to believe the Earth is flat nor should we make any special dispensation for the fact we believed it to be flat for so long and for the same reason we cannot include Pluto among the planets when it became obvious it doesn't meet the requirements of actually being one. But it has been at the tail end of every model of the solar system before it was demoted and there is no scientific, statistical, encyclopedic or whatever-elsic reason it cannot still occupy it's place especially since other small person planets are also included. And they should be, why make the thing less interesting. Voted no, still cling on the the "Classical 9 planets" model of the solar system even if one of them isn't a planet but is satan's droppings or something.

The most dramatically apropriate outcome would be for the probe to malfunction right now. How is it possible to quote someone and still misquote them at the same time? ^^ I clearly wasn't serious anyway, but i also said right now and "right now" is timestamped at 29th June 2015, 08:35 I am only guilty of providing NASA with a plausible excuse, because what could be more plausible than "Well, we were clearly jinxed by some arse on the internet." Lol, anyway i do want to see close-ups of Pluto in my lifetime much like the rest of us. [edit] That said, i'll take the bashing if it helps. The cruel gods of space anomalies might be amused if i were tossed into a volcano or something. Heck even i would be amused.

The most dramatically apropriate outcome would be for the probe to malfunction right now. All these questions, and no mission scheduled for another 20 something years. At least. Part of me wants to jinx the probe now. And think of the amount of bs that will be spewed out by idiots who will claim there are 'faces', alien pyramids, death stars, visitors, and if we're lucky maybe even a mass suicide cult. The potential is enormous! It's not often that i think science should shove off in the name of entertainment, but the more i think about it, the more my IQ seems to drop. Die New Horizons?

Well i have been a user for several years now and in my experience the updates were allways slower. Never to the point where it upset me or took more than 1-2 days, but if a patch rolled out just as the folks who work there left office, it could obviously affect time it takes to roll out updated files. I suspect in this case the delay was caused by the 1.0.4 hotfix coming on the heels of the 1.0.3 update, but that's just a guess. I don't exactly know how KSP and it's updates fare in gog land because i update from the store. By downloading the entire game... Generally the update song and dance is similar across games these days. Steam is usually first, sometimes quicker than dev's own website or less clogged up. Other distributers such as Gog, HumbleStore or whatever are hours or up to a day or so behind.

Gog is usually slow with updates and it usually takes 24h or more as they don't have people working round the clock or manpower/resources of Valve. Memories are short and people forget just how terrible Steam was for years and how long it took for it to become a very good client. Gog Galaxy has been in alpha for about 6 months and is currently beta with LOTS of features still missing or not working properly. Gog does provide updated installers for the standalone new version of a game and usually an upgrade patch that patches the game to the latest version. These are created manually and though it's not a terribly slow process by itself, there could be a queue of updates for multiple games each day. It also doesn't help if there's a patch followed quickly by a hotfix patch, which is kinda exactly what happened with the two updates of KSP they've had to deal with so far. Yes i'm defending them here, and it's true they should pickup the pace of updates, BUT the forgotten upshot here is that whereas Steam just steamrolls over your current version of the game, Gog allows you to download each version installer separately, back it up, install it unlimited times and play it whenever you like. This is the other side of the coin with games that are still getting frequent updates because often those bork mods or change gameplay. Steam is quick to update but unless you made manual backups, you're going to be playing the latest version wheter you like it or not. You also need internet access on every computer you wish to update your game on, whereas Gog's installers/patches allow for offline installs. Steam is definitely more convenient and easier to use, until it stops you from doing what you want like updating offline, disabling the client or playing an outdated version. Gog is slower but less likely to interfere with the customer playing the game they own in the way they want, which includes butchering and modding it. I don't think they're evil, in fact i kinda think they deserve some love. But if slow updates are a problem send them feedback that they can go to hell and wont see any of your money again until they improve the update process. It's an effective threat.

I'm not alone in thinking that what i'm seeing here looks a bit like Minmus, am i? I know it's still too far away and pixellated/artificed, and maybe i'm seeing what i want to see, but that planet looks kinda lumpy.

I'm a Gog user though i own KSP in the KSP store and update from there. I also use Steam. Gog tends to be a little slower with updates and it's not unusual for patches to arrive a day or two after release. This is partly because Gog doesn't have the resources of Valve and partly because they provide update packages. Not sure if this is the case for KSP but normal practise is to see an updated installer for the full game and a separate patch to avoid having to download and install the entire game. Gog Galaxy (Gog's new Steam-like client) should automatically update the game much like Steam would. The upside is that with Gog it's possible to install separate versions of KSP to separate folders and keep multiple versions running or play an outdated version. Something Steam normally prevents because the client insists on only allowing the updated game to start. Don't get me wrong, i like Steam a lot but this is one of the few things that can really get in the way of enjoying the game, latest version or not. Gog Galaxy is supposed to introduce a rollback feature and allow the user more control over which version to install. You can still use Gog's installers even if you let Galaxy manage the game and it's updates. Also handy for downloading patches/games on one machine then installing on another where there's no internet. So slow updates = bad, but more control = good. Depends how much you like to mod games or keep installers of previous versions.

Call me lazy but when departing Minmus i just burn prograde or retrograde relative to Minmus' orbit and ignore the period businness altogether. The influence of it's gravity accounts for less than 100 m/s or thereabouts. It takes about a week to reach Minmus, and orbiting there can be painfully slow (and burning direct to target is not 100% accurate). Add in the whole business or constructing an orbital base and i certainly understand why it would be more complicated. Thing is, i like having a station there anyway. Plus fuel production is very cheap in terms of Dv lost to gravity, and there's a lab there analysing various types of icecream collected from the surface, and i enjoyed constructing a station from several bits.... In a way, since it's there anyway i like using it, but it's not THE way to do it. And using Minmus for departue can mess with ideal launch windows, i have to admit that.

I had fun with sky cranes but eventually stopped bothering with them because they increase the complexity and workload. Most of the time it is more practical (it is a game afterall) to include self-landing capability when designing whatever surface vehicle/base/craft. Sky cranes are separate craft designed to de-orbit and safely land other craft, usually bases or surface facilities that will not take off or move anymore. Sky cranes are usually disposable though sometimes they can be recovered and refueled for use with another landing payload. Think of them as reverse lifters or semi-landers. The upside to dedicated sky cranes is that that are re-usable as long as they can be refuelled in orbit of whatever body they're used in. One other use of sky cranes is surface delivery of a lander that WILL takeoff and return to orbit but does not have enough fuel for both landing and takeoff.

I build satellites that have a free node on top so that i can attach another satellite there. Alt+left (IIRC) click allows you to "pickup" a collection of parts so you can grab the entire sat as a copy, then stack it on top of the first one. Repeat as needed. - It may be neccesary to change the root part to make it possible to pickup the entire sat, sometimes VAB/SPH can be a bit silly. In this example, the stack separator + satellite can be stacked indefinitely. Or as long as the fairing allows.

For me Minmus is the takeoff point for interplanetary flights, not LKO. I lift things with less than full tanks, reach Minmus, refuel and away we go. Having a mining operation in LKO strikes me as fairly pointless since Kerbin is itself a source of fuel. It's true that lifting that fuel costs cash in droptanks and fuel used but i what i usually do is take a lifter without payload into LKO and leave it there for spaceplanes and such to use, then deorbit and recover what is possible. A nuclear tug can easily move larger bits to Minmus for assembly or refuelling. I know LKO offers a bonus from the Oberth effect, but Minmus has almost no gravity to interfere with either mining or launching interplanetary flights. Maybe i just prefer it.

There are lifting engnies, airbreathers, tiny/ion engines and then there are orbital engines. Those are usually not very powerfull but are economical and the nuke is extremly economical so it's often the engine that gets the best range. 909, aerospikes and poodles are all very good engines and are often picked over nukes when the craft is very light, or needs a high thrust engine. Landers need to burn very quickly sometimes for example. Nukes are also terrible for orbital insertion burns when there's no chance of airbraking. They're also very heavy and the craft needs heat management. I don't think it's hype per se, it's just that it's damn hard to find a reason not to use them simply because of the glorious range they offer. Since spaceplanes use LF tanks and are usually not too heavy they are very well suited for nukes, and SSTOs are very popular so there's some hype there. Tugs or fuel tankes also also ideal craft for nukes. Basically any craft that isn't too light or too heavy, or doesn't need to be thrifty with fuel or high Dv burns done in very little time, is better off using the nuke than anything else. The fact that is't heavy, bulky and hot is for balance and to give other engines a purpose. They're far from underpowered. They're pretty balanced with their problems, otherwise they'd be OP.

In fairness real engines and tanks are much more efficient than those in KSP. Since KSP has a smaller planetary system the real engines would have been overkill. Probably the main reason would be to not risk the return vehicle getting damaged on the Moon. It was a first landing afterall and nobody knew for sure if they'd land safely or return after landing so in the worst case at least someone would make it back. Someone close enough to help understand what went wrong. Reliability and crew safety are comically ignored by KSP. I don't mean that as a knock on KSP, just saying it's something our flights never have to factor in.

It's not just the engines themselves, it's the rest of the craft that plays a large role in heat distribution. For example i've cobbled together a nice SSTO with two nukes that can burn in excess of 10, maybe even 15 minutes without overheating (partly in athmosphere though). The heat distributes across small LF tanks and then into Mk2 LF tanks, then wings and other bits. On the other hand when i pushed 6 nearly empty orange tanks using 4 nukes (it was part of a space station assembly), the engines threatened to explode before completing the Kerbin LKO - Minmus transfer. That was only 2-3 minutes... In that case nukes were attached to converters and orange tanks, and i suspect the orange tanks, despite being good heat insulators were also guilty of not dissipating heat to the rest of the craft quickly enough, so the heat accumulated in the engines themselves. Pictured: SSTO after Mun takeoff. Heat overlay showing heat distribution. Station module in the VAB; I don't have a screenshot of it overheating but it is atrocious. Heat management is a thing now that nukes produce so much heat, and it's a fair trade. They're already beating almost every engine out there in vacuum performance, they need some weakness/downside.

I'm not 100% sure this is true. I still occasionally get 'science from space around Kerbin' type contracts, even after orbiting Eve (and i get NO science from EVE...). It does make sense that docking contracts would dissapear though as they are more of a milestone than a source of income/research. For the record, i have seen the contract but can't remembe if i've taken one. I was mostly busy rescruiting, to invent a new word...

All can be done landed/splashed. All but Seismic scan and Athmosphere analysis can be done in high/low orbit. Some can be done flying over a biome, other at high altitude but i can't say for sure which. Best carry a suite of all instruments you've unlocked in sciency craft (athmospheric planes, suborbital turbojets, science landers, etc...) Temp - available in all situations. Pressure - available in all situations. Gives no reading in vacuum (but can still gather situational science for a biome). Seismic scanner - only when landed and stationary. Gives reading in flight/space though (but no situational science/experiment). Athmosphere analyser - only in athmospheric flight. I think it treats high and low altitudes separately but can't say for sure. Gravioli detector - haven't used it much but it should be available in all situations. It refused to conduct an experiment a few times, maybe when the craft was moving/burning/in flight. Goo/Science Jr. - all situations. Crew report - all situations. EVA - all situations though cannot be safely performed in athmospheric flight. Can be done unsafely... Ore scanner - Not science but should point out that it gives a continuous readout best used when moving on the surface and trying to pinpoint the richest spot. Mobile lab - Can analyse all experiments to gather research data, wheter done in the craft with the lab, or delivered by hand from elsewhere. Can reset equipment (goo canisters, science jrs.) on docked craft. Does not need a scientis for this. Needs a scientis to convert data into science. [edit] For max science it's best to remove data from each instrument by hand before moving to another biome. If you have duplicates, place them in separate capsules/cockpits. Then cover a new biome with fresh instruments. For example on Minmus it's possible to score midlans, slopes and one of the flats with minimal fuss. It's generally more expedient to analyse results in a lab, then transmit back home. I'm a pedant so i carry the damn things with me, but you don't have to.

What Blu_C said: I forget which one is Flight planning, but ideally you want both at the same time unless you've grown very comfortable with eyeballing Mun/Minmus orbits. Since playing this career i have pretty much ignored maneuver nodes when transfering but they are extremly usefull for setting up early career 'free-return' flybys (you basically do not have to use fuel to return to Kerbin) and are almost essential for rendesvous and rescue work. Eventually you just have to have them, but for a long time you can indeed just eyeball flybys by burning prograde when Mun/Minmus are above horizon (or even eyeball it using the map). Minmus is a touch trickier since you have to match inclination once you eject from Kerbin, but it's a cheap maneuver. Anway, lvl3 Mission controll gives unlimited contracts (up from 7 at lvl2), and lvl3 Tracking station allows asteroid tracking. [edit] There is something that can be done to simulate planetary transfers at least. It requires that you place a small probe just outside Kerbin's SOI, then once it's a bit away from the planet, match Kerbin's orbit as best as you can. The probe will lead or follow Kerbin at a short distance. When you want to do some 'flight planning' switch to this probe and place a maneuver node along it's path to check what kind of Dv you might need, how long the trip will be, and where can you expect to find the target. When using this method allow for the fact that the probe is already outside Kerbin's SOI and whatever you intend to launch will have to bother with escaping it's gravity first and will thus be late. It can still give a rough idea of what to expect. This is a feature that is missing from stock KSP. It's silly that only a vessel that is already in orbit of something can use maneuver nodes to plan course changes.

Finnicky payloads require or even demand a different lift approach/ascent. Here's a few tips: - Use a stable lifter with above average fuel. You *will* waste fuel. This is intentional. - Fly straight up to above 35km using lower than normal thrust. Try to keep velocity between 200-300 m/s. Do no break mach 1. Not even near it. This minimises the effect of drag and reduces the likelyhood of the rocket being pulled by air friction. This costs/wastes fuel. - Try to avoid SAS lock because it has a nasty habit of wobbleing rockets to death. If you must make manual inputs be very gentle and try to keep pointing straight up. - Don't worry too much about inclination (veering north/south), but try not to let the rocket turn retrograde. - As your lifter climbs, the effect of gravity decreases and velocity increases. Adjust throttle as needed to avoid going too fast. - Once past 35km air friction subsides to the point where it is safe to gently begin turning prograde. Gently. Hit Alt-F5 to quecksave a specific save and use Alt-F9 to reload if bad things happen. In addition to being susceptible to drag, fiddly payloads often lack structural integrity and can be broken off by high thrusting engines. Sadly high thrusting engines are needed for sub-optimal 35km prograde turns otherwise the rocket will fall back down before it reaches orbital velocity. If high thrust is impossible, then it's best to keep the angle of ascent high and keep wasting fuel. If the payload can be strutted up tightly then it's time to throttle up and gain orbital velocity. If you keep running out of fuel, use stonger engines and bigger tanks. This ascent is initially slow and steady but eventually needs to make up for it. Maybe someone has a better idea but i prefer Mainsail + Skippers for the job unless payload is also stupidly heavy as well as drunk & disorderly. If wobble is incurable then the lifter needs to be redesigned. Try a more vertical lifter with additional vertical support structures. Gratuitos struts should be used to connect the payload to the load bearing part of the lifter. If drop tanks are used, struts *can* be used to attach payload to them, but keep in mind that they will be dropped. By 'more vertical' i mean a central stack with 2 additional companion stacks that can be used as anchor points for struts keeping the payload in check. Image of a medium sized rover/lander hybrid craft strutted up on top of a medium lifter. This failed to make orbit on the first attempt but second time with an extra bit of fuel and better piloting it worked. A rather silly ore transporter rover/lander secured using vertical extensions of the lifter. I was too lazy to rebuild the lifter with fuel tanks instead of girders. Both ideas would work. In conclusion, i too have been driven crazy by KSPs refusal to let me lauch silly things into space. My stubborn solution was to WASTE FUEL, lift straight up above 35km thereby wasting more fuel, make sure that i have firmly strutted up the payload, keep wasting fuel and eventually it relented and let me have my way. [edit] Also, if you have rover wheels, engage the parking brake to keep the wheels from spinning. Not sure if they affect anything but they might. That trick capi3101 mentioned to secure central tanks to one another is an oldie but a glodie. However i will be damned if i will ever resort to it again post 23.5 joint strenghtening. It's a flaw in the game and using this as a solution would increase part count. But it does work. I just hate it.

This is one of the most helpfull posts i have read on the subject: Basic Aircraft Design Explained Simply With Pictures It is not up to date for 1.0.2 and some references are made to old aero that did not feature realistic drag. But the main jist of the post still holds.

Just turning off PPFX was enough for me. I keep the gauges and suffer no crashes. Of coruse *now* i've asked for it, but up to this point i had no crashes...

I admit to and apologise for not having browsed the thread. Just saw the title and since i've recently established a gateway around Minmus to act as an interplanetary launchpad, here's the album with pics of the mining ops and orbital refinery. I chose a fixed mining location harvested by a rover/rig with 2700 ore capacity. A 2700 ore cap lander/rover collects the goods then takes off for the orbital refinery. The refinery itself has no ore storage. The docked transporter acts as storage until it's emptied. Currently, the station is incomplete and is missing the fuel storage + power generators. In my defense i squandered career funds and couldn't afford to lift it. ^^ Not too happy with the transporter. The CoM moves when it's full so i must alter the thrust limit of one 909 engine. It's also not so great to have to use the small ore tanks, but for now it's good enough. I plan to make similar operations at other mineable planets, currently looking at Eve and Duna. Craft files: Gateway Station - Built in the VAB in such a way that you can detach different pieces and launch them separately. Each "module" has it's own power, unmanned probe and RCS thrusters. This is to eliminate the need for tugs and allow easy re-configuring of the station. It increases part count though. Mobile Mining Rig Ore Transporter - It has a claw so remove that if you don't want it. It's there just in case, but isn't needed.

There's lots of issues with the LV-Ns. Same as other engines. Isp is certainly important and the nuke is king in Isp, but it's also heavy, large, tends to overheat small/sensitive parts, uses LF only which forces a slightly different fuel tank solution, and above all else it has crappy thrust for the bulk. Is it allways the best engine for the job? No. Not unless your craft is an interplanetary SSTO or system tug/fuel tanker. It is often the most efficient choice, but not allways the most practical one. Given how good it already is when used in it's ideal conditions, why should it be improved further? It would make other engines useless. [edit] Atomic motors should really use a separate type of fuel, but Squad must be loathe to include yet another one. It's also neglected that when using garbage can or orange tanks, the craft benefits from better heat management in addition to carrying a bit of deadweight. It evens out.

Clawphobia is a bit overhyped. I've had one single issue caused by driving a rover into a clawed rover by mistake. A mistake i made sure not to repeat. So far i've used them on recovery landers to return junk to Kerbin, recovery orbiters/airless landers, as a backup docking port in case surface docking fails, as a straigh replacement for docks on surface fuel tankers, etc. They're fine for many uses and i've had clawed vehicled dock with complicated stations without issue. There is a limit to claws, and they're definitely buggy but not to such an extent that their use should be completely avoided or relegated to asteroid capture. SAS going berserk is a much bigger and almost constant problem for me.

Well the answer is obvious but not very easy to engineer. Build your lander as a rover. What good is a craft that gets you to surface but can't really do anything or move you about without using a lot of fuel and performing dangerous surface hops? Make the whole thing a rover first, then figure out how to position engines so that it can function as an orbiter, THEN work on getting the whole thing balanced on top of a rocket. The engineering difficulty is in having to solve two diffrent sets of problems with the same vehicle. Orbting and generally behaving as a space craft is one thing. Driving on the surface is obviously another (Then factor in wings for a spaceplane design and you're in KSP hell. Or heaven). An all-in-one solution is not going to be as efficient as a dedicated lander nor rover but it doesn't have to be. Nothing is perfect, though it could perfectly suit your needs. I have dirtside bases that feature engines and tanks so they can land themselves. They would be more efficient if they were delivered via skycrane, but do i allways feel like bothering with a skycrane? Or would i rather pilot them down to where they need to be then shutoff the engine and forget it exists? The anwser is that i regret not having built them as rovers because now i'm unhappy about where i landed them. In any case, i find that in the long run, things without wheels feel badly lacking and as a result i try to build bases/landers as rovers with a secondary purpose. Ground vehicles generally don't care much about CoM position, but when orbiting, it's crucial. Fuel lines can be used to ensure fuel is depleted evenly, and building craft symetricaly helps. If you forego symmetry, then use parts as balast to ensure CoM is as fixed as possible. And never use tanks as ballast. Never do that! It will be frustrating, but owning a nice land based vehicle with rocket engines that can propel it through space and takeoff-land feels like one of KSPs achievements. If it's accidentally also the lander you're looking for, even better! [edit] On the subject of re-docking a rover on the surface with a mother craft. I wouldn't bother. Docking is way to fiddly on the surface, and the claw only works when you claw into things. When things drive into the claw, the game crashes. Not that it can't be done with docks, but if you're going to invest that much time and energy into it, you might as well try what i originally suggested instead.

The idea was indeed to ditch the fairing along with the booster into a suborbital trajetory and avoid lugging it around. The rocket is overpowered already so the weight penalty is small enough to be irrelevant. The smallest fairing doesn't increase in mass with size quite as much as the medium and large ones do. The criticism is fair though because i intentionally didn't optimise it for efficiency, but rather went for a "Phillip J. Fry" approach of completing satellite contracts in the Kerbin/Mun/Minmus system as lazily as possible regardless of wheter they're easy or complicated. Load craft, fly into position, lose a drinking contest with the autopilot, profit. It's also possible to double or triple stack satelites inside the fairing, if you're lucky enough to get contracts with similar orbits.