cantab

@silvermistshadow can you reproduce the issue in only stock KSP + FAR? If not, I suspect the evidently modded runway you have is contributing to the problem.

It's doable, but yeah, grind is not difficulty any more than delta-V is difficulty. The Caveman Challenge, now that's difficulty. And if you still think it's too easy, well 1) Go do a Caveman Jool-5, Eve Return, or Grand Tour, or B: Try even more aggressive restrictions on mass, part count, or tech tree level.

The link to "atom" was added on the 8 May this year. So Randall was not necessarily wrong when he wrote his comic. Before that the first link was "light", and light will indeed currently take you to philosophy. No edit reason is given for making "atom" a link, but quite possibly it was to break Randall's very prediction. Since there's no reason for it to NOT be a link, though, it's likely to stay this way.

Big wings should help, and fly a high angle of attack entry to bleed off plenty of speed in the upper atmosphere where heating is gentler. If desired you can bank to maintain a draggy high AoA while reducing vertical lift.

To have budget cuts, first we would need a budget.

The stock game doesn't currently do this. In its aerodynamic model the only way would be for the spike and nosecone to be a single part , because a surface-attached part is only ever going to increase drag.

is rail transportable. This pasta bake factory ...

Can that be any part, or are there limitations? For example can they destroy a "middle" part and thus split their vessel in two, something that I think the scrap/salvage mechanics in UKS disallow.

Confirmed that this restores familiar behaviour for my aircraft. Graph screenshot if you need it: https://flic.kr/p/GhBpfW

Could that discrepancy be down to the reaction wheels? A Mk1 cockpit offers 10 kilonewton-metres of torque. That's equivalent to a one ton weight hanging off a 1 metre lever arm trying to turn the plane around. I know from experience that aerodynamic forces often do overwhelm reaction wheel torque, but nonetheless it's gotta count for something when it comes to post-stall control hasn't it?

Nah, KSP just has bugs. In particular KIS/KAS connected bases are notorious for these problems. As I understand it it's a major reason why Roverdude added loads of "logistics" features to UKS, to make functioning bases that don't have everything physically connected.

Confirmed it in a clean install with just FAR, and launching and reverting to SPH doesn't change things - and like I said, the plane is actually flying unstable in Kleinhans. Let me know if you want logs Ferram (or others) and where they're located on Linux.

So I know you changed drag a bit, and I know this is a bit of an unusual aircraft, but should the latest FAR have this much impact on the handling? Kindelberger: https://flic.kr/p/GgAckw Kleinhans: https://flic.kr/p/GgAe5y Craft file: https://onedrive.live.com/redir?resid=40CBF49A479D54A8!428&authkey=!ACAzB2PctETTGeo&ithint=file%2ccraft Flight testing backs the graphs, it few beautifully in Kindelberger but is totally unstable in Kleinhans.

Regarding stuff moving around, in my experience Sun, Kerbin, and Mun are "immutable", their IDs are always the same so bodies orbiting or landed on them stay there. Though remember Galactic Neighbourhood makes the Sun into the central black hole and Kerbin orbits a different star. Every other body can have its ID changed if you add or remove planet packs. The stock bodies are less likely to change IDs but even they still can. You can put vessels back by editing the savefile and checking the IDs from the Kopernicus.Log, or just use Hyperedit.

The staff of any website can log in "as" any user anyway. Reset the password, cracking the hash in the database, or modify the code to allow it. And remember the code that actually runs the website doesn't have to be the same as what it says on github or another public repository. So that feature in Spacedock doesn't allow anything that's not already possible.

The first time you load KSP with any new planet packs, there'll be a pause during loading because Kopernicus does some stuff, and then saves cache files so it doesn't have to do it again. Maybe 5 mins on a slow PC. If that's not the problem, then I don't know what is. Here's an example of one of my configs, to make Sarnus a Vanor trojan. @Kopernicus:AFTER[New_Horizons]:NEEDS[OPM] { @Body[Sarnus] { @Orbit { @inclination = 9.1 @eccentricity = 0.101 @semiMajorAxis = 301846876551 @longitudeOfAscendingNode = 110 @argumentOfPeriapsis = 124 @meanAnomalyAtEpoch = 2.0472 @epoch = 2000 } } } Note that I apply it AFTER[New_Horizons] and it NEEDS[OPM]. The needs line isn't so important for personal use though. Watch out for other patches getting applied after yours and overriding your configs! Sometimes you'll need FINAL to ensure your patch is applied last and takes effect. Here's my patch for using New Horizons, OPM, and Trans-Keptunian. Putto is positioned as an "anti-Plock" just like Orcus in the real world, and the others have their orbits pushed out. @Kopernicus:FINAL:NEEDS[New_Horizons,Trans-Keptunian,OPM] { @Body[Putto] { @Orbit { @inclination = 16.15 @semiMajorAxis = 935833706086 @longitudeOfAscendingNode = 340 @argumentOfPeriapsis = 50 } } @Body[Arane] { @Orbit { @semiMajorAxis = 1089554285957 } } @Body[Oorma] { @Orbit { @semiMajorAxis = 1029990621355 } } @Body[Flo] { @Orbit { @semiMajorAxis = 1619626397014 } } } Both patches http://creativecommons.org/licenses/by-nc-sa/4.0/ and derivative works of New Horizons, OPM, and Trans-Kep.

Try it and see. IIRC it's much the same but bigger, with Sarnus being put beyond Vanor. (I made my own config that puts Sarnus as a trojan of Vanor, to get it away from Kerbol Plus's Sarin and make my wild system more fun.) EDIT: Eeloo stays as its own planet in NH+OPM, which means one fewer moon for Sarnus.

You also might not be packing enough delta-V. In general when your delta-V requirements are low, a light but inefficient engine can do better than a heavier high-Isp one.

Agreed with this. I like having many worlds, but I'd like even more having better worlds. The surfaces of KSP's celestial bodies are pretty bland. Even Kerbin, the richest we have, is boring close up and only gets interesting seen from an aeroplane. But I'm not sure it will ever happen. It could be a lot of work just because of how huge even KSP's 1/10 scale planets are, the land area that needs designing dwarfs almost all games credited with "large open worlds". And, I suppose, the emphasis of KSP is spaceflight, rather than planetary exploration.

If your refuelling depot will have ISRU, then put it at Moho, it's closer to mid-way delta-V wise. If you don't have ISRU, then what I might do is just drop fuel depots like breadcrumbs as it were. Ie: Depart Kerbin and set periapsis level with the stranded Kerbal's orbit, and timed for rendezvous During your burn at periapsis, drop full fuel depots. These will be in a series of elliptical orbits round the Sun. Once you have the rescued Kerbal on board, use those fuel depots to refill. You might be able to chase them down right away, but otherwise just make extra orbits of the Sun and rendezvous with them at periapsis. And one more thing to watch out for: Last time I went to Moho, the heat was enough to slowly vaporise my heatshield. If this is still the case then you may need to plan for a powered capture at Kerbin on your return, and then another rendezvous with a re-entry ship. (Or just a powered capture to LKO, and then you can re-enter a capsule without needing a heatshield).

Well, I think FAR should basically be stock, so yeah ... correct lift with Mach please. I do find a few things difficult aerodynamics-wise. One is handling "Mach tuck" and other effects that shift CoL with speed. But now that we can pin right-click menus, I wonder if it won't be easier to use fuel transfer to trim that out. And in-flight views of the CoM/L/T would help a lot too I feel. Another is that flaps seem nearly useless. 10 m/s slower landing if I'm lucky. Either I'm doing something wrong, FAR makes them too weak, or they're actually nearly useless in real life. A third is just that everything seems to glide really well in FAR, and shedding speed is a pain in the backside. That may be real of course.

By the way, I resolved the cat-and-toast idea a long time ago. The cat lands on its feet as normal. At this point the toast hasn't fallen - because it's still tied to the back of the cat! Then Murphy's Law and feline behaviour take effect, and the cat goes to the most expensive furnishing or carpet in the house and rolls over, smearing the butter all over said expensive furnishing as it tries to get free of this thing tied onto it.

You can use solars quite far out, you just need to be prepared to take a lot of them. I took an ion ship out to the Jool system once and while it was Ec-starved I was still able to enter Bop orbit then return to Kerbin. For power per mass the RTG beats solars at Jool, but for power per funds solars are considerably better even at Eeloo, though I suppose the extra mass may impact the cost of lower stages.

Back when Portal was the Big Thing, I conceived of putting a portal on the floor, one on the ceiling, a waterwheel between, and then dumping a load of water in so it perpetually fell between the portals and turned the wheel.

I did what I should have done first: actually tested it. And you are correct. Both supplies consumption and grace period are the same in seconds (or minutes or hours) whatever the game's Kerbin/Earth time setting, which is the behaviour I would expect. So I think there should be no need to change USI Life Support's settings unless one wants to change the actual consumption rates and/or grace period. Or change what happens when the Kerbals run out. Sorry for mouthing off @RoverDude . I misunderstood what you said and my reaction was basically "What the [expletive]? That's ridiculous'. And indeed it was - what I thought was happening was so ridiculous that it wasn't true. The only time-related issue I found is that the top line that states the rate of supply consumption (eg 16.2/day) is always using Kerbin days.