swjr-swis

Like @bewing said, they're just plain text files - they just end with the extension '.craft'. Any text editor you have installed can edit them. Make a backup copy of the file you want to edit so you can get back to the original, and you can experiment without worry. Do me a favour though: please, please change your folder view settings to show the file extensions. I don't know who at Microsoft decided it was a good idea to make that an option, let alone turn it off by default, but I sincerely hope that the closest those persons get to UI programming in their next seven lives is by cleaning out pig sties.

This only happens with bays and fairings, which is not the case here. No other parts will 'occlude' anything, as the game code treats any other part clipping as if the parts are fully exposed to space.

It's explainable though: the craft is basically in a decaying orbit (due to water drag) around the point mass at Kerbin's center. Enjoyed the documentary!

"Don't make me flip this rover over, because I will!"

It's the Russians. (See the movie "The Abyss". Applicable scenes may be from the director's cut.)

The debug menu. On Windows: Alt-F12, Cheats, Ignore Max Temperature. Heating still happens, but parts don't go poof anymore when past their temp limit.

Inverse square relation with distance... it's gravity after all.

Looks like the lil geek imploded...

Mission accomplished, I would say.

<nods sadly> He's obviously hallucinating.

Soon now he'll start typing garbled text... then he'll be silent for a while and come back much clearer, but claim that he can see light from below.

Not just that, but he's actually accelerating as he goes deeper - gravity is increasing. KER is either very confused already, or sub-surface physics follow a different set of rules. I almost feel the urge to ask Jeb to turn on his helmet lights. Almost. Then the thought occured to me that we may not want to know what may be swimming right by him...

About 9 hours from the moment of your screenshot Jeb should be reaching a depth of 600000 m. It would be interesting to see what happens then.

And I wrote in the wrong value. Thank you for alerting me to it.

To paraphrase Nemo: "You underestimate my antenna arrays. You underestimate them... greatly."

Before starting KSP again, do the following: In the main KSP folder, open the file 'settings.cfg' in a text editor, search for the following line and change 'True' to 'False' and save it. MISSION_SHOW_EXPANSION_INFO = True The expansion dialog will no longer show when the game loads. This is assuming a Windows platform - on Linux and MacOS the settings file is named/located elsewhere, but the entry to change is the same.

You could place them one by one as suggested by others... or divide the symmetry up a bit for more convenience. E.g.: 1x center. 2x 2-sided symmetry in +. (north-south, east-west) 1x 4-sided symmetry in x. (NNE, NNW, SSE, SSW) Using the offset gizmo (set to snap and absolute) you can form a perfectly aligned ring of 8 vectors around the center one, and you only need to make 3 separate offset and settings adjustments instead of 8. To ensure the 4x symgroup is aligned exactly the same as the two 2x symgroups, rotate the rocket 45 degrees so the 4x engines end up north-south-east-west, and then make the engine offset adjustments - that way, they will align exactly as if you had a single 8x symgroup. Then you add the 4-sided symgroup and one of the 2-sided symgroups into a separate action group to toggle (*), leaving just the center vector and the other 2-sided symgroup active - 3 vectors to land with. (*: with toggle instead of deactivate, you keep the emergency option of quick short bursts of full power in case you need extra braking power at the end of the trajectory.) Quick video demo:

The decoupling side of the hardpoint would need to attach to the base of the fairing - not the shell, or the interstage nodes... that will indeed not work. Keep in mind the root order required by KSP for part attachment, and the attachment rules for hardpoints (surface attachment on both 'ends'). For the hardpoint to work as the decoupler of the torp-like craft (the payload), it would need to be the root of that payload. If you already have the main craft and payload craft separately built, you would need to follow a few steps to make it attach by the hardpoint: Attach the small hardpoint to the base of the fairing. With the re-root tool, make one of the Mk1 tanks the root of the craft - you need to use a part that can be surface-attached to place it on the hardpoint. Load the main craft. Load the payload craft with 'Merge'. Now you can attach the payload to the hardpoint. The hardpoint adds a tiny bit of drag to the payload craft, even if clipped - but much less than the CO construct you use now. So it's worth doing. Yes it is. As long as the fairing is closed it's shielded. But don't take mine or anyone's word for it: Alt-F12, Physics, Aero - enable the first option to see drag numbers in the rightclick menus and confirm for yourself.

Yes it still is a thing, for the exact same reason. However, now it's also significant to minimize the transition between attached parts. In other words: since RAPIERs are 1.25m, the small nosecones are not the best choice anymore, since that attaches a 0.625m to a 1.25m part. The Aerodynamic Nose Cone or Advanced Nose Cone do a better job on a 1.25m node. Tip: call up the debug console (Alt-F12 on PC/Win), and under Physics/Aero, enable the two first options to get some insight on design vs aerodynamics. The KSP aero model can sometimes still be pretty counter-intuitive, so it helps to see 'live' how things play out. Very touchy subject. There's been a few upgrades to the game engine (Unity), which at one point completely borked the wheels/gear system. They were forced to change over to a new system, which has never quite got back to the level or stability the old wheels/gear had. One of a number of things lost in that transition was the option to lock suspensions - it no longer exists, and there doesn't seem to be any outlook on getting it back again. In return, the system we have now sometimes decides to ignore friction, or creates phantom self-amplifying forces and bouncing, and generally likes to explode a whole lot more than it used to. Yay for progress. In general, yes. Resource extraction has been made a bit more complicated and overall seems to result in less ore than in 1.0.5: you now need to keep in mind the optimal core temp of drills and converter, which requires radiators appropriate to the gear. Also, the small drill and converter have been nerfed so they basically never operate at optimum anymore - they overheat regardless of the amount of radiators you install.

¿Qué?

Using either the internal nodes of a (closed!) service bay, or an interstage node of a fairing, will add no drag to the craft.

Another method: Add a 1.25m service bay and use either of the internal nodes of the bay for a decoupler. One more: radially attach a Jr docking port to the last part before the Juno that allows surface attachment, then rotate and offset so the free docking node is at the end of the Juno.

Those will allow radial attachment. Attach a small hardpoint to one of them, offset it inside the tank, then use that as the root/decoupler of the torp subassembly. Attach to the side of the fairing body, adjust the release force to zero if you don't want any push off the fairing centerline - for the purpose of release it won't matter. Second method, if you make a 1.25m fairing part of the torpedo body: place it as far aft as possible, rotated backwards, and use one of the interstage nodes for the decoupler on the fairing that houses the torp craft. This one is probably the most 'seamless' method, as the fairing interstage nodes can invisibly extend a good bit beyond the end of the Juno, so no need for offset or clipping.

You are over-complicating things. The cut-scene would be a completely predetermined animation path without any need for physics whatsoever, since there will be no unexpected interactions at all. The only variable would be the launched craft , and it would only need to be rendered as a completely non-interactive static model pinned on top of the crawler. How much physics processing is spent on rendering the vehicles driving around the tier 3 VAB/SPH? It's the same basic thing. If your computer can switch back and forth in and out of the VAB/SPH without a moon three planets over getting destroyed, it can render a non-interactive cut-scene too.

This is why I said 'live action cut scene', and not 'video'. This feature would only have a (small?) recurring entertainment value if the craft used in the cut-scene was rendered from the actual craft launched. Being rendered 'live', I don't see why the processing power would matter much: if the computer has enough power to fly the craft, it can also render a predetermined animation path - even easier, since physics calculations would not be required. And for those that left the option on and don't want to wait through the entire animation for a particular launch, a quick tap of the mythical 'any key' could stop the animation and move on directly to the flight scene. A bigger issue may be that we regularly come up with contraptions to 'launch' that would be decidedly silly or impossible to put on a crawler - but with the option to skip the animation when we don't want it, I don't see why that should have to be in the way of a bit of eye candy. Heck, it might even provide some entertainment of its own.