swjr-swis

I honestly don't know. This forum keeps playing tricks on me - inserting replies before others that were already there when I replied, completely 'forgetting' I posted a message forcing me to repost to make it show up... nothing really surprises me anymore. So why not time warping too.

Pretty sure it's horizontal instead of vertical, as per rule 7:

Steam has recorded 441.5 hours for my least-used install of KSP - the one in the Steam library. I don't play that install, I have it only to download the different updates/versions, and every now and then fire it up just to see what's in the latest update that just landed. I have no way to really tell, but I suspect I passed the 10k hours a long time ago. Perhaps it's best I don't know.

You might want to try this fast and easy to handle Mk3 transport: https://kerbalx.com/swjr-swis/Transport-3a. It can circumnavigate Kerbin in under an hour, so getting to the iceshelf should take less than 15 mins flying at normal time. It's an evolution of one of @Hotel26 designs, helping to make it leaner and balance it out. Turned out quite useful... I've been using it regularly since then. There's plenty of notes in the plane description to reuse the ideas in other planes of your own design if you wish. Check out the forum thread as well - there's more planes and advice offered by others.

I didn't really believe Elon played KSP until I saw this picture...

Not easy to answer accurately, this poll. I marked the first, third and fourth options. I have used the one stock part that plays this role, but I can build better and more reliable LES out of other parts, so I usually do that instead. I also put that one particular part on craft sometimes, but certainly not always, and mostly not for its intended functionality.

This is specifically mentioned as being fixed with the upcoming 1.6 patch:

Look for lakes or rivers enclosed by land with the tundra biome. You'll find the 'splashed down in tundra' in the water, close to the shore. It doesn't exist everywhere, but that's the only places you'll find it.

Yay for consistency and/or logical progression. The same can be said about the 'mits' of data each science instrument uses. One would expect reports that comprise just a single biome name/sensor value to need only tiny amounts of data that vary very little from each other in size (mits) - thermometer, barometer, accelerometer, gravioli detector. Then would follow the composite experiments that return values of multiple sensors - materials bay and atmospheric. More sensors in one but basically still the same concise biome/sensor value pairs, so still pretty compact in data size. Then there's the experiments that require verbose reports, like the crew report and goo containers, which would basically be descriptive texts of undetermined length, probably including photo or video material. Tiny remark: it's not immediately obvious that the first column combines the results of three separate antennae. Interesting observation: the Communications table in the Parts wiki page lists the 16, 16-S, DTS-M1 and RA-100 as needing 6 EC/Mit. This corresponds -disregarding decimal differences- with the values we can calculate from the in-game part information (EC/sec divided by Mit/sec, which is the same thing). However, your results deviate considerably from that. The wiki table also suggests the HG-5 and HG-55 to be the next less EC-hungry antennae, in that order, while your results show the opposite order. If you stand by your results, this would mean the part information is incorrect. The odd part is that those values in the part information are derived directly from the actual part configuration details... so they should be correct. Thanks for doing this. I would say as a separate page linked from the Parts table column headers?

Short answer to that: no, there isn't.

It's up to you, really. Do whatever feels right to you. There's as much (or as little) to say about sharing craft with DLC parts as with any player mod, and look at how many modded craft are published every day. Obviously people are ok in large numbers with modded craft being shared. Personally, I don't see me sharing a DLC craft (yet?) for the following reasons: I try to share craft that can be loaded by anyone, with as few prerequisites as possible. The only prerequisite most of my craft have is the version of KSP they can be expected to work in, and even that annoys me, but I can't do anything about that. I can and do avoid mods. And DLC is really just a stock mod... one that needs to be paid for on top of that, so even less people are certain to have it. That will likely keep me avoiding DLC parts regardless. I dislike many of the choices Squad made for this DLC. I accept that Squad deserves to make a living, and that current artists/devs adhere to different views than previous ones, but the end result is that I feel little draw to use or promote MH. What I don't build, I can't share. It doesn't help that none of the game versions after 1.3.1 have yet managed to convince me to upgrade definitively. Since I keep playing 1.3.1, that automatically rules out DLC entirely. We'll see what 1.6 does.

Agreed. I do the same thing - load the 'plane' section separately in the SPH, and do any finetuning of fuel/payload balance and CoM/CoL positions in there. Once that is done, I assemble the launch vehicle in the VAB. The CoL 'lift arrow' in particular often does very random things in the VAB.

I'll guarantee you that someone somewhere has reason. Tis. Stock solution: multiple docking ports that will dock at the same time and force the alignment you seek. Hidden stock solution: the stock KSP code actually already contains the means to make docking ports snap to certain angles... it's just not enabled in the default part configs. Check out the community patches thread.

Usually what you describe here is achieved by building the craft with symmetry. In flight this has the side effect that changing (most!) settings in one part of a symmetry group automatically makes the same change in all other parts of that group. Which when it works (most of the time), works better than the example you describe from Factorio (no need for copy/paste at all). The downsides: There is no stock way to group parts to act on rightclick changes without using symmetry. If symmetry is not an option, the only alternative is to use action groups, and hope that the specific setting you wish to change is available for action group usage (many are not; slider setting never are). It's not entirely consistent - for unclear reasons, there are exceptions to some settings that will ignore a symmetry group and only change an individual part even if the rest of the settings of those parts do act in symmetry (eg. the auto/manual switching of RAPIER engines will always act on only a single engine, despite all other settings obeying the symmetry grouping). Tl;dr: your suggestion sounds helpful. The KSP way of doing this is through symmetry, or to a lesser degree, through action groups.

I think key to your issues is that parts in the VAB are by default orientated with their 'belly' to North instead of East. Which makes rockets by default tilt sideways (yaw) on their way to equatorial orbit, instead of tilting down (pitch). This default is pervasive, because even when you rotate the entire rocket eastwards, any time you pull off a part or section that has not been individually rotated before, or when you hit space to reset it's orientation, it will go back to this north-facing default and be off by 90 degrees with the rest of the rocket again. If you like your rockets (and every sub-section of them) to be orientated East to make gravity turns be about pitching instead of yawing, you're going to need to get into a constant habit of rotating parts 90 degrees, every other step. Or, you could bat your eyes at @Snark and ask for his VABReorienter mod. It will turn the default orientation in the VAB such that these issues become a thing of the past. Subassemblies do not really help, btw, because they have an even more irritating default behaviour: they forget their root part orientation the moment you save them, and only the root part counts in how the subassembly loads into the editor.

I agree with your main point, but these time estimates seem way off in my experience. How does it take a whole hour RT to complete an average rocket contract, or 2-4 hours RT for a spaceplane? I finish designing and building a rocket/spaceplane in those times, and that includes multiple trials to test flight stability and establish optimal ascent and descent profiles. If every trial run took that long, I'd never get to finish my builds, let alone play the actual career. If you're taking more than 10 mins RT to get your average rocket payload to circularized orbit with a run of the mill gravity turn, something's wrong. That's even considering untypically shallow ascents (30 degrees above horizon at 10km); if you always go the more typical 45@10km, 5-6 mins tops. Spaceplane ascents are generally (but not necessarily!) shallower and so typically take longer, but even with those I never take more than about 30 mins RT at most for the entire mission, including payload deployment and runway landing. This comparison seems a bit off. The atmospheric trajectory and time spent before you pop the chutes is not going to be any different than for a typical spaceplane - so that can't be causing 'hours' of difference. And I can't imagine any reasonable landing approach taking much longer than what it takes to float down on chutes. If you remove the restriction of landing at the runway, I think landing the plane in the flat KSC vicinity could even be faster. I concede that landing the 'plane way' requires one to actually pilot the craft down, where chutes make it care-free and practically automated... but I can't see it making any significant difference in time.

Ok, clear.

That's not a moon... I'm at a loss for words. It's a thing alright. Going for some records? I notice that the screenshot angle is deceiving: there is actually no angle of incidence on those wings, as far as I can tell at all. The lower wings are just cambered progressively up to bring the tips together. So you can ignore my previous remark about that. Angle of incidence would help, a lot, with getting this craft to take off faster, and to get to orbit with more dV left (or less fuel/engines required). It's the main suggestion I can make, the thing that would make most difference in the performance of this craft. Second suggestion: the engine nacelles on the main body are too clipped into the fuselage. Those engines are either not providing any thrust at all, or too little to justify them. KSP penalizes blocking the exhaust path of engines with a severe loss of thrust. Pull them out so their exhaust path is clear, it will make a ton of difference. Or... just delete them entirely. Like this, they're almost just dead weight. Curious to see how this develops.

Tl;dr. (P.S.: your exclamation point key seems to be sticking...)

It's very hard, near impossible really, to give any meaningful suggestions about a craft based on just a single picture from a single orthogonal angle. You add a lot of text, but it adds more questions than clarification. One thing I notice immediately though: you're using a diverse spread of angles of incidence on your wing sections, which will basically cancel out any beneficial lift and leave just the detrimental drag. That's not going to help you get this craft to orbit - it's like flying the whole time with giant airbrakes/spoilers deployed. As best as I can tell from your text, you're wondering which is better: to have the CoL higher, lower, or at the same height as the CoM. It won't make a difference for how fast you can take off - that's purely about lift/weight ratio. It won't affect wing strength either - that will depend on attachment method and (auto)strutting. I can't figure out what "higher speed adjustment of the nose" means, so I can't say if it would make any difference for that either. If you mean a more reactive plane to control inputs - that depends on your control surfaces and how far away from the CoM they are (your CoL and CoM are already relatively close, that won't need much change). The height of the CoL relative to CoM mostly affects flight stability and behaviour at high angles of attack or when banking. In my own experience, having it slightly above CoM, combined with a bit of camber, tends to help with stability during reentry. Theoretically the aero forces would then keep the craft heading belly-first, or trying to get back into that attitude if disturbed. But it's a delicate combination of factors that can't really be taken individually only - sometimes it adds more instability instead. It highly depends on the specific craft. A few more screenshots from other angles would be useful. Ideally, a craft file. Help people understand the craft, so they can help you.

Quoting for relevance (and for the awesome and accurate title ):

Not really much to offer there. If you stick with tall and topple-happy, the best you can do is pick an absolutely flat piece of terrain to land on, land very very carefully, and keep SAS on radial out... and hope it's enough to keep the rocket balanced on its end. KSP is still having trouble with random bouncing of landing legs, and oscillations in SAS... neither of which are going to help much. And it's pretty hard to pinpoint a perfectly flat, unsloped spot to begin with. It sucks to have to redesign a craft, but in this case I think it's pretty inevitable. Not to say it's absolutely impossible to use as is, but I think most experienced players would not even try this. But don't let that stop you - sometimes the best way to get a feel for what works and what doesn't is by simply trying out what you build. There's something to say for not taking anyone's word for it and just learning from your own experience.

Well, it's a very tall rocket, which is not very stable for a lander. Main rule of thumb for landers to stay upright is to keep center of mass as low as you can, and the base (distance between landing legs) wide. A table can't fall over on to its side very easily, but a stool only needs a little shove. If your payload is intended as a lander, you need to consider building it wide and low.

Not necessarily expensive: my PassengerRocket1 uses a few tier 6-8 parts, and 78 parts in total... but the per-passenger cost is very cheap (204.08 in the one challenge attempt, just the fuel and recovery cost) and remained unbeaten in a previous cheap passenger SSTO challenge. Even the total cost is pretty low (65350 for 64 kerbals to orbit and back). With a few small changes it could be limited to tier 6 parts (it does need a probe core capable of pro/retro SAS) and go down to 63520 total. A few trial runs to tune fuel for 71km LKO and an exact deorbit burn (there is a bit of excess fuel), and per passenger cost could go below 143.44 (assuming 100% recovery). That's a pretty harsh depreciation for a recovery. The stock game doesn't depreciate that much even when the craft lands half-way between KSC and the mountains (96.4% for the challenge attempt). Anyway, obviously your rules are quite specific and not exactly default, so my rocket will not be a valid entry. It can serve as example of how low things can go. Good luck with your challenge, should be interesting to see what entries come in.

Those nodes are only meant for engines, even the center one. It's not meant to be used as an interstage, the center node is not big enough for that, which is what causes the bending. It's a bit of a puzzler to me, because as far as I can tell, the only configuration that even works ok is placing 5 Mastodons on those nodes, and then only in the bare variant. Might as well just've made it one part with the engine bells included, like a supersized Mammoth. Not sure what to say about that one. The center nodes of the engine plate are definitely the right size, it should be stronger - assuming you used the largest size one. Either way, looks like you'll still need to do some additional strutting to rigidize it.