Fraktal

Spent about six hours in the VAB today in a single non-stop session, adding abort groups to all my launcher designs. Then to actually give the day some meaning, I put down a simple scientific monitoring station on the Mun (this was the second), intended to supply Kerbin Spacedock's laboratory with data using the Science Relay mod. More will follow, one per biome, in order to keep the lab supplied (as it's currently producing <1 Science per day), followed by dropping more stations on Minmus as well. Speaking of which, I also intercepted and deorbited the Spacedock's old and obsolete core module and control module, both having been dumped off the station a few days ago and floating a couple dozen kilometers away. It took about half a dozen orbits (the Spacedock is in a 300km orbit) to move all the modules over and while I was at it, I also brought the station a present in the form of a single-seat worker pod for performing such operations by themselves. I'm thinking of setting up a second station in munar orbit. Fuel and power. definitely. Lab, not sure. I have a probe on its way to Eve and my next milestone will be launching a manned Duna mission (my first ever), but the transfer window is still over a year away so assembling the ship in orbit can wait for now.

Currently using science mode to R&D stuff for an eventual career. I'm also a bit masochistic and do said R&D with 10% science gains from experiments done in order to force myself to design stuff using as few tech nodes as possible, going for efficiency over style.

You might also want to consider looking into the administrative strategies that convert another resource into cash.

Thinking of KSP recently, I remembered that the biggest issue with using an aerodynamic nosecone instead of a fairing is that even if you stage off the nosecone with a decoupler upon reaching a high enough altitude where aero isn't a problem, the now-unpropelled nosecone immediately collides right back into the still-propelled rocket, potentially breaking stuff if you don't have the time and fuel to briefly thrust radial-out to avoid it. I had to scrap a Duna mission once due to the nosecone I used to cover the command module's docking ring having smashed into and broken the antenna when I staged it off during circularization. So I thought, what if there was a decoupler variant that's still mounted inline but when staged, applies force diagonally instead of exclusively on the fore-aft axis, specifically to fling stuff staged off the front of the rocket out of the way? Because using a Sepratron for a mere nose cone is a bit of an overkill, not to mention draggy, costly and heavy enough to defeat the whole point of using a nosecone instead of a fairing..

Does it actually matter how close or far away they are? I've heard both that it does because of torque and that it doesn't because KSP applies the torque without taking that into account. Which?

I recommend checking out the Craft Manager mod. It lets you organize all your stuff, both crafts and subassemblies, with tagging and filtering. It's an absolute lifesaver if you have lots of saved designs. The only issue with it that I've noticed is that it does not work together with KSP's subassembly categories @Skorj mentioned: if you tag an existing subassembly saved in a category, it's removed from the category.

I already pulled this challenge off last year. Rocket was over 100 parts and lagged like crazy, but I landed on the Mun and got back without using a single Terrier.

Wouldn't it save ablator to have the decoupler stay on and burn off from the heat?

Something that came to my mind today after reading post after post about 1.8's heating issues. Radial heatshield specifically intended to be attached to the underside of spaceplanes. Something like the existing non-edge radiator panel models that conforms to the hull's curvature but larger, possibly procedural, and with ablator instead of active cooling.

Started assembly of what will eventually be a spacedock in medium (300 km) Kerbin orbit. Took about three hours to successfully pull off the first launch, containing the core module, the fuel module, the propulsion module and the control module with Bill at the controls of a HECS core, as the six-axis core module was highly un-aerodynamic and too wide to fit inside a fairing. I had to resort to an almost vertical ascent until I was well into the upper atmosphere because whenever I tried a normal gravity turn, the rocket flipped at 8 km during the tail end of the transsonic region. I was also slowed down by my own idiocy because I actually had the payload in low orbit when I reverted because I wanted to put lights on the station core to be found easier during night flights and it took me another hour and a half to find the sweet spot where the rocket didn't flip during ascent. Second launch will contain the ventral power module and the starboard docking module. I was actually about to launch this when the game crashed, so tomorrow. Third launch will be the portside antenna and a short-range shuttle pod, the latter of which will eventually be followed by at least one more shuttle. Separate escape pods are not currently planned because the station's location means the shuttles can theoretically survive reentry with minor damage. While the construction is taking place in a science mode game I use for prototyping things, for the final design I'm thinking of outfitting every single module with RCS thrusters. Would it be worth it for scenarios like chasing down drifting undocked modules during refits or should I rely entirely on the propulsion module's Poodle engine for such things? Even the Poodle feels like overkill: with the propulsion engine's fuel tank and the fuel module, the station has over 4000 dV available (though the fuel module isn't intended for that, only for refueling ships that come in for docking).

The aero drag on takeoff. Being awesome at reentry doesn't quite mean anything if you can't get it up there in the first place. The only workable configuration I can think of that does not require a fairing is using the stage carrying the pod as the core of a short but wide asparagus configuration. My questions about these three pods: If all three are supposed to be launched exclusively inside fairings, then why put two of them before the first fairing in the tech tree? Why make the Onion require an external reaction wheel, then put the Pea on the same tech tree node as the first RW so that by the time you actually have what you need to use the Onion, it's already obsolete? In order for these to be properly usable, I feel the Onion should be moved to the same node as the Pea (where the first reaction wheel is), the Pea should be moved to the same node as the Mk1 Lander Can (available around the same time as the first fairing so that aero is no longer a problem) and the Pomegranate should move to the same node as the Mk1-3 pod.

More organization today. Question to you folks: is it worth it to sacrifice efficiency for safety? I'm asking because I took a look at one of my munar lander designs for improvement purposes and I think I may have overkilled it a bit. It used to have one FL-T400 tank which was fine for a suicide burn landing and return, but the narrow tank meant the legs couldn't extend far enough out to keep the lander from tipping over if landing on a >10° slope. So I decided to do some fuel rearrangement to lower the center of mass and spread out the landing gear and in the end, I ended up with a single T200 tank and three T100 drop tanks, the extra fuel being required to offset the dV loss from the drop tanks' nosecones. Good news is that the lander casually landed on an 18° slope without even trying to tip over, which the old design couldn't have managed. Bad news is that the extra weight meant I had to add more fuel and a second Terrier to the transfer stage (which is now heavy enough to turn like a sloth with reaction wheeling only), which meant I had to add even more fuel and thrust to the launcher stage. It still flies with minimal trouble and gets back to Kerbin with 400 m/s to spare after a non-ideal equatorial landing and retrograde takeoff, but I feel I sacrificed too much in the way of efficiency just to not have to worry about tipping over. Frankly, an early-game low-tech single-person lander shouldn't require three SRBs, three Reliants and a Swivel on the first stage alone (the previous designed needed one less SRB and one less Reliant).

Today a new era has dawned, as the 8 gig RAM module I ordered back in August finally arrived, allowing me to at last experience KSP the smooth and responsive way it was meant to be experienced. Seriously, startup and shutdown times dropped to something like a tenth of what they used to be, with scene changes finally taking seconds rather than minutes. No big construction happened, just a reorganization of my inventory of boosters. Also finished a mission that consisted of Jeb and Bob prototyping the MH Mk2 command pod to fetch some science from Minmus for processing in the lab at Kerbin Gateway Station. Problem is, they got greedy and visited a second biome to double the data. By the time they got back to a 275 km orbit around Kerbin in preparation for a rendezvous with the station, they didn't have enough fuel to pull off the rendezvous and match orbital velocity on arrival. So they instead burned to an equatorial inclination so that Val launching from the KSC in a single-seat pod could fetch the data and take it to the station. The second complication arrived from the fact that after the transaction was carried out, Jeb and Bob didn't even have enough fuel left to deorbit (shouldn't have wasted the fuel on an inclination change when Val had enough to spare). It took them about 20 packs of EVA fuel to manually deorbit their vessel, by which time Val also missed her rendezvous burn with the station by six minutes and was forced to take a more aggressive approach. In the end, the data was delivered and everyone came home safely, with the station's lab now producing slightly more than 0.1 science per day. More hardware reorganization is planned, followed by a major expansion of Kerbin Gateway Station with fuel storage and a docking grid to serve as the eventual assembly point of a Duna mission at the next transfer window (over a year away), while waiting for an Eve/Ike probe to arrive in ninety days. Also thinking of building a second station far out at the edge of Kerbin's SOI as a future launch point for interplanetary missions.

So you don't need to upgrade the Mission Control as well?

Both of these are very good advice. I always had trouble keeping a science payload launched before I had the 1.25m service bay surviving through reentry, even when I offset it into the capsule as much as aesthetics allowed. But following this advice, I experimented with hanging goo canisters off a girder between the top of a Mk1 capsule and a parachute and it was perfect, with the canisters never even showing the overheat bar. For an added bonus, it also made the final stage's silhouette resemble that of a Mercury capsule. While this tower configuration adds some stabilization as well, it's sadly still not enough to make a KV-1 usable beyond a short atmospheric hop.

Are you gonna build more AC aircraft? The Morgan and possibly the Raven is a no-brainer, Wyvern would need Breaking Ground for the wings.

Considering that I won't have a rig capable of running KSP 2 for at least five more years, absolutely.

It it looks like and quacks like Kerbin's equivalent of a duck...

Turning a hamster wheel with high-pressure monoprop, perhaps?

Flatspin is usually caused by too small/too few vertical stabilizers. One of the mods out there contains a static stability analysis graph tool, you may want to consult with that. I found that it helps during reentry if your shuttle has way more reaction wheel torque (and battery power) than what it would normally need. I have a 10-ton passenger shuttle with three small reaction wheels and four 100 EC batteries stuffed into a service bay at the aft, thing's rock-solid stable during reentry as long as I leave maintaining a 20° reentry angle completely to SAS and don't touch the controls until after I'm gliding mostly horizontal.

The only way to get fuel through a heatshield without turning off "Resource Transfer Obeys Crossfeed Rules" in the difficulty options is an External Fuel Duct attached above and below the shield. It'll automatically disconnect when you stage off whatever is below the heatshield (since I presume you've got a decoupler immediately below the shield that you'll fire prior to reentry).

Nope, 64. And as of this noon, I have another 8 GB of RAM ordered and on the way. We'll see in a few weeks if this will improve performance (though I doubt it, as CPU is also 98% during flight with a constantly yellow mission timer; back in 1.4, it used to be green without physics warp).

Because if you don't, the wheels have a habit of kicking out like a horse if they touch the ground at an angle far from "straight down". ---- As for me, doing some testing on a three-seater ground-to-LKO passenger shuttle. She's ugly on the ground, but she does the job, able to make it to orbit only by following prograde and varying throttle to keep apoapse 60 seconds ahead (thank you for the idea, @OhioBob !). Just needs a very careful transition from surface navball mode because it's a mite aerodynamically unstable during takeoff due to a pair of diagonal winglets on the bottom to shield the two ventral Junos' intakes from reentry heat (there are four Junos and two Terriers on the shuttle itself). In fact, during this particular test flight, it actually spun out of control in the upper atmosphere but still made it to orbit after I cut the engines and let it drift a bit for the SAS to stabilize it. And for reentry, I gave it three small reaction wheels and 400 power, which allows it to maintain a 20° descent AoA and go into a horizontal glide at 30 km altitude without engine power or me touching the controls. Doesn't really fly well at subsonic speeds, though, as I can't use trim without making it backflip during takeoff.

Um... UAC has nothing to do with RAM. UAC stops programs from starting with admin permissions without the user's say-so while an access violation is a piece of already running code touching memory outside of what it asked the OS to be allowed to use, causing the OS to instantly banhammer it out of existence not only because it could break other programs or even the OS itself by overwriting someone else's memory, but also because reading someone else's memory is a security risk (since it could be used to steal passwords and the like).

My mistake. I meant 1.7. And I ran the game today with Task Manager open on a second monitor. The results are here, since my game didn't crash this time and as such I don't want to muck this thread up.