Starman4308

I'd either reinstall MJ, or check that you are controlling your ship from the appropriate docking port.

Thanks for the help Master Tao. Probably was a borked mod installation. I'm marking it as closed: while my career game is kinda messed up from having to re-install so many mods, that's not something which can be helped. Might as well start fresh with Paul Kingtiger's 64k distribution. Hopefully I can salvage the .crafts for my Duna mission, though. I spent a crazy amount of time on those.

And to enable coverage over that blind spot, you could try using a satellite in a very eccentric polar orbit with apoapsis on the dark side of the moon: it will always have a relay to those two satellites, and will spend 95% of its time with line-of-sight to the blind spot.

That could work. It'd mean separate batteries and reaction wheels/RCS, but that's not a big deal: those parts basically coincide with the probe cores anyways. The big thing I think would be making sure the control still points upwards, despite being placed radially. If you're feeling humorous, you might try a boxy radial core in Advanced Flight Control, and a "technologically advanced" streamlined (possibly lower-mass for stock players) core in Specialized Flight Control. Very pretty. But I think those tanks are questioning why one would go to space.

The answer to this more or less boils down to "make some rules of thumb, and then experiment with each new launcher". As I understand, once out of the drag zone, you want to maintain a time-to-apoapsis of ~10 seconds (possibly a bit more if you're about to stage into a low TWR stage): that keeps you mostly horizontal, building up orbital velocity while minimizing gravity losses. It also has the advantage of generally keeping your rocket in a good orientation for body lift: body lift will help preserve your altitude, letting you spend less dV fighting gravity. A higher first-stage TWR means you should start pitching over sooner, because otherwise you shoot out and upwards too quickly, having wasted an unnecessary amount of delta-V going upwards. A lower first-stage TWR means a later pitch-over, because it'll take you longer to get out of the drag zone. If your second/third/n'th stages are low-TWR, you want a more vertical initial ascent, because you need more of an upwards "kick" to buy you time to circularize; high TWR upper stages let you burn more horizontally. EDIT: You can optimize ascent profile computationally, by what amounts to simulating different ascent paths until you get the best one. The KSP equivalent is endless revert-to-launch until you get it right.

Just to check, you do have the physical parts, right? If you don't have decouplers, nothing's going to decouple, and if you don't have parachutes, you're going to crash. An image would help greatly.

StupidChris gave up on RealChute for a while after an unauthorized x64 fork coincided with personal difficulties. He's coming back to supporting it in a couple weeks, and RealChute is pretty good (so long as you delete the stock parachute config in the RealChute/Module Manager folder), but there was quite a bit of x64-related drama about it.

As mentioned: play stock or near-stock first. It's hard enough to get your bearings without throwing so much at yourself right off the bat. Some of them (Kerbal Alarm Clock, Kerbal Engineer, Trajectories, etc) are just plain useful, both others, particularly Deadly Reentry and FAR, are just complicating things too much. You can also trim down your RAM usage by using fewer part packs. I haven't needed anything beyond a keyboard, and I suspect you wouldn't need anything more than one of those basic Logitech joysticks if you wanted nice spaceplane handling. Do be aware that because Unity uses the raw joystick input instead of the calibrated joystick input, there may be issues.

One potential suggestion is to use the Tylo lander's own engines for part of the transfer burn, and send a separate refueling mission to fill up its tanks in Tylo orbit. As for myself, I finally got my Duna transfer stage up into Kerbin orbit, in preparation for rendezvous with Duna/Ike landers and the return stage. No screenshots unfortunately; my game bugged out hard, and I'm in the process of reinstalling all my mods. I've spent way too much time optimizing this mission, but with the brutality of 6.4x dV numbers, you pretty much have to shave off every kilogram of payload that you can.

The possible reasons for incompatibility: #1: KSP 0.25 and an old version of MechJeb. #2: KSP 0.24 and the latest version of MechJeb. #3: KSP 0.25, Windows 64-bit, and MechJeb. #3 is caused by many modders not wanting to deal with support requests from such an unstable build: some of them can't even run Windows x64, and half the "bug reports" they get from x64 are caused by x64, not their mods. Use 32-bit, or install Linux and use the Linux x64, which is quite stable. In general, have the latest versions of both Kerbal Space Program and the mod, and things will work well. The only difficult points are KSP updates, which tend to break old mods in terrible ways, and it takes a while for modders to get stuff updated, and to fix the stuff which broke when they updated, and fix the stuff that broke when they fixed the earlier problems, etc, etc.

Hello, KSP's been crashing, and I don't know why: I started it fine, quit by pressing the x-button (must've hit Z when entering something into KAC, causing engines to fire), and the next time I tried to boot, it's freezing up midway through loading. I think it might have to do with RealFuels or some mod using it, because I get error messages about that in the first lines of the log, but I did try uninstalling and reinstalling RF, the RF Stockalike config, and the associated TweakScale folder. I did at some point have two Module Manager DLLs (one got tucked away in a spot I didn't see), but I deleted the second copy, so that shouldn't be an issue. I apologize about the mostly-raw dump of my Game Data folder; if anything crops up, I can provide version numbers, it's just a giant pain to manually do this for as many mods as I have. OS: Linux x64 Log file 001_Toolbar0PinlineFairings 6-4-KerbolSystem-1.1.1 AnchoredDecouplerFix.dll Chatterer ChuteQuickloadFixer.dll CrossFeedEnabler DeadlyReentry EVAEjectionFix.dll FerramAerospaceResearch GameData Kalculator KAS KerbalAlarmClock_3.0.4.0 KerbalFlightData KerbalJointReinforcement KWRocketry LargeCraftLaunchFix.dll MechJeb2 MissionControllerEC ModRocketSys ModuleManager.2.5.1.dll ModuleRCSFX NASAmission NavBallDockingAlignmentIndicator NavHud NavyFish NRAP PIDTune ProceduralFairings ProceduralParts RadialEngineMountsPPI RCSBuildAid RealChute RealFuels RealSolarSystem RFStockalike-1.0.3 RSSBuild Sane Strategies SelectRoot Ships Source Squad StageRecovery TacFuelBalancer ThunderAerospace ToadicusTools Trajectories TriggerTech TweakableEverything TweakScale US_Core_0.9.3.25 US_KAS_0.9.0.14 US_TAC_0.9.2.7 EDIT: Resolved. Probably due to a sloppy upgrade of Universal Storage core, compounded by mis-reinstallation of RealFuels. I'll be more careful extracting mods from now on.

Press [ or ] to switch between craft which are within physics distance, or go to map view or the tracking center to switch between distant craft. I have no idea where you got the "auto-switch" thing from: I've never experienced that myself.

I suppose. My thought process was "How hard can it be to just stuff random stuff around a probe body", but there are sillier things in the KSP tech tree. I wound up putting a few small, cylindrical procedural batteries in a ring around the bottom, and strutting them to the top, because the interior struts in the fairing weren't enough to prevent wobble.

Or MechJeb. I see why people think it's cheating, but I think it's beneficial for new players to watch how MechJeb does things, so they can learn from that, and figure out how they can do it on their own, possibly even better than how MechJeb does it. In any case, both of them display TWR/delta-V, which is amazingly useful. In any case, OP: re-install KSP, make sure it is a sandbox game you start (it defaults to starting a career game), and hopefully things will work. There are also numerous guides available: most of the forum swears by Scott Manley videos*. *Don't try what he does in some of his videos, and don't be depressed that you find it hard to do what he does. You'll get there eventually.

Target the, well, target. Watch your closing velocity (click the velocity meter to show target velocity) as you close in, and just before going past, burn target retrograde until you hit 0 m/s relative velocity. To have the velocity killed at absolute closest approach, you will want to burn for time t, and begin the burn at 1/2*t before closest approach: so if it would take 8 seconds to kill your relative velocity, start your burn 4 seconds before closest approach. One thing to watch for is that you need to be pretty close to judge what relative velocity will be: if you're far away, the relative velocity is dominated by the phase angle*. *For example, if you've got two spacecraft in 2.3 km/s circular orbits, 180 degrees away from each other, their relative velocity will be 4.6 km/s, because they are going 2.3 km/s in opposite directions relative to the center of Kerbin. This goes down to 0 as the phase angle goes to 0.

Hey Necrobones, how hard would it be to whip up some circular probe cores in various sizes (particularly 1.25m, 2.5m, 3.75m, and maybe 5m) which amount to "We took an OKTO, and put an RCS tank/structural element around it"? Particularly with FAR, it's kinda wobbly to have a 0.625m probe core in between two 2.5m stacks, it's ugly, and the existing 1.25m/2.5m probe cores are late in the tech tree. The 2.5m one also has a weight issue: it's 0.4t heavier than an OKTO, and if you don't need the additional electric storage or reaction wheel strength, it's dead mass. I would mostly use it to send LKO boosters into reentry so they don't clutter up my orbits. My current solution is an inelegant mess: to sandwich an OKTO between two procedural fairing rings and strut the hell out of it.

Talk with Wanderfound. I kinda know the theory, but Wanderfound's the SSTO expert. You might try setting a lower periapsis or AoA, which would cause you to bleed off speed quicker at the cost of being a harsher reentry. You'd want to fiddle with it, to get the fastest reentry you can without any Rapid Unplanned Disassembly Events. EDIT: Those 50 km deorbits I were talking about were definitely overcautious: many of them were "well, it's almost a full orbit to KSC anyways, so might as well practice my lifting reentries" things.

You're coming in too steep. Start with a higher periapsis, and consider performing a .To summarize that long video: if you've got positive pitch (your heatshield is pointed below your atmospheric prograde vector), your heatshield will act as a lifting surface and keep you in high atmosphere longer. To help with this, use an asymmetric capsule with the CoM above capsule centerline (a good way to do this is to have two RCS tanks, and shift all the RCS fuel to the upper one): instead of fighting reentry to keep your pitch, the reentry keeps your pitch for you. It will also help to have a lighter-weight reentry vehicle. Larger vehicles will have a greater inertia/drag ratio, which means they will take longer to slow down and have a higher terminal velocity. If you're dead-set on reentering a monster of a craft, you may have to either use a stack of Sepratrons (or similar mod parts) to slow you down to 250 m/s, or use the 6.25m inflatable heatshields as impromptu drogues. EDIT: Also, if you do it right, it's not hard to do a reentry from almost arbitrarily high speeds which is only mildly harder than one from low orbit: the trick is to set up a skip reentry, where you "bounce" off periapsis and then start settling back down again, having shed most of your excess velocity in upper atmosphere. That requires finely tuning your periapsis to manage reentry path: I strongly suggest the Trajectories mod (make sure to set the AoA setting! It assumes you fly nose-first).

Mechjeb for certain. Probably also Kerbal Engineer and Vessel Orbital Information Display.

I think you're overestimating how shallow that is. While I haven't been playing with SSTOs much, I've had capsule reentries with a periapsis of 50km, taking 3/4 of an orbit to set down on Kerbin. Wanderfound's advice is to set AoA to 14-20 degrees: his first goal is to re-establish aerodynamic lift and kill downwards velocity. A 0 degree AoA means negligible drag: you are basically darting straight into low atmosphere. A 90 degree AoA means you are slamming into atmosphere like a brick, killing velocity too quickly and leading to instantaneous stall and aerodynamic failure when you start getting down into atmosphere. A 14-20 degree AoA means moderate drag, and lets you get aerodynamic lift from the moment you hit atmosphere. Too low AoA: you dart into atmosphere. Too high AoA: you are basically a stalled-out brick on ballistic reentry. Just right AoA: You are a space plane​. EDIT: For future reference, I was not suggesting 50 km reentry. I was suggesting that 30km was not "super-shallow": 30km is around the upper limit of what I'd do, but I'm overcautious about reentries anyways. If I wanted an accurate stock capsule reentry, I'd probably aim for 40-45km periapsis.

Almost always 100%. If you ever use less than 100% until the final stages of ascent/circularization, you have either failed to optimize your design, or you messed up your gravity turn/pitch profile. Either option is failure.

I think the major point here is that Crayola would care if it's something which would hurt its business. What you posted does not hurt Crayola's business, and probably helps them (at the very least due to the sale of those crayons). In a similar fashion, modders care when somebody does something which causes excess bug reports to land on their laps. I suspect many of these modders would be happy if somebody added features to their mods, stuff like replacing all 30 TAC life support canisters with two size-tweakable canisters. The only thing they can possibly expect to get out of this is more x64 bug reports. Hopefully it's not many x64 bug reports, but I see why the modders are pessimistic about this.

"Moar delta-V" is a cheesy definition of "harder". For that matter, for large rockets, it might be easier with stock, because you can get away with cheesy asparagus-staged pancake rockets, whereas FAR will be most unhappy if you try that. FAR makes you worry about rockets too: they have to be aerodynamic, you can't bank too hard, and for optimal ascent, you also have to worry about body lift. *Particularly noticeable if you're using RSS: you would still pay only ~1.5 km/s souposphere penalty, so your to-orbit delta-V would go from ~10 km/s to ~11.5 km/s.

Not possible in stock: a Mun-synchronous orbit is outside the Mun's SOI. I'm uncertain about RSS. There's a WIP mod to do N-body physics, but that might be a little much to download just for Lagrangian points.

Well, I suppose if you count slightly higher delta-V requirements and tedious ascents as being "difficult", you could, but I much prefer the difficulty inherent in pulling off a proper gravity turn and flying an aircraft with real aerodynamics instead of a souposphere.