tater

It's funny, people complained that aero was going to get fixed, because it was bad for so long that "bad" was equated with "the way things should be." The soup "is a challenge to be designed around," etc, ad nauseum. If they could suddenly make all the planets have awesome, realistic craters and landscape features down to cm resolution with no performance hit at all, people here would post that lousy, boring planets were "kerbal" and making them better was a bad idea .

When they first came out, this virtually never worked for me, so ever since I have never bothered even trying that. This is why QA matters. The part itself should be flush, though, that or it should form the bottom arc away from the tank (the SSTU fairing does this) so the fairing looks like it isn't surpassing from a rib.

Right now the little box in the top right is checked and says I am following THIS thread, and guess what, I'm not following this thread. I never told it to follow this thread. Every thread I post in gets followed, then I have to unfollow it. This defeats the purpose. I thought I had fixed it, but if I have to do something with every thread, I might as well just ignore the functionality (since there isn't any).

I managed to figure out interstages in PF, but gave up on that in stock a while ago, though maybe they work... I think that as part of the supposedly forthcoming improvements in rocket aesthetics they should fix the stock fairings. There is no need to replicate PF, just make stock fairings "not ugly." That seems a pretty low bar to me, to have them not be awful.

I only added the small parts idea to make you some early junk parts .

EDIT, the fact that you say "Can you prove it wrong?" is pretty telling. Nothing needs to be proved wrong. Positive claims need to be proved true.

At the expense of an extra part for every single such attachment in a game that is fundamentally limited by part count. The net result is exactly the same, except for those extra parts. Nothing is added, except parts. It's the very definition of a slippery slope fallacy. "Where does it end?" You are making a claim, so for it to be true, you must demonstrate that it is true.

@adsii1970No, actually I don't. My view is the distillation of what is being discussed. Every single part in KSP can already be radially attached by 2 mechanisms. You can slap on the radial attachment part, or you can use the entirely stock offset and rotation tools. The former needlessly adds to the part count for virtually zero reason (do what OP suggests, and those parts are entirely unneeded). The latter has many other complications as anyone who has used those tools knows when you then move a part by mistake (or intent) and it goes wonky.

@The_Rocketeer, there are really no impossible combinations. We can do everything radially right now, it just adds a part. There is no innovation bread. Slap on radial attachment point, add non-radial part. There is no there there, just an extra part. In stock KSP mass is pretty meaningless, demonstrated by how trivial it is to create SSTOs, so the extra parts are not a mass constraint, just a part count constraint---this on top of a stock game purpose-designed for wobbly rockets that require numerous ugly struts.

Bad design is bad design. This is a thread in suggestion for the stock game, the "use mods" answer is not appropriate, @regex actually makes mods, so telling him about them is pretty funny, he knows. I use mods already, and in fact for the engine clusters I have abandoned stock engines altogether in favor of a mod that clusters engines as a single part (and I can cluster them in number, arrangement, and mount type at will (entirely addressing regex's concerns with my image post in his post above)). The point of the thread is that the choices of which parts can attach radially is not some master plan to encourage innovation, it's arbitrary, and often nonsensical and counterintuitive.

@KSK, I don't disagree that parts could have varied aesthetics over time, but the problem is that we have to use the same parts at every stage. 1. Currently the earliest parts are in fact sort of sleek, the middle parts are junk, and the late parts are sleek again---but early, middle, and late are defined only based upon size. 2. Having a texture toggle (check out SSTU for this) would work, and you could even predicate it on tech unlocks. Have allowed textures change as the tree is advanced. Once all the parts are unlocked, "sic-fi" textures become a thing. 3. I hate the junkyard aesthetic, but even if I didn't, then the spaceplane parts need to be junkified. Either everything is junk, or nothing should be junk. The schizophrenic mixture is absurd. Here's an idea. Add a new class of 0.625m rocket parts that look like they were cobbled together in an actual barn (I hate the barn, too, BTW, but I'll accept the notion for this). Those are tier 0 test rockets. Have a launcher part they come with (a rail) that you explicitly set to a launch angle, and they are unguided. Learn rocketry with it, it can be ugly.

Tech unlocked by time and money makes sense, and it also makes sense that particular tasks ("contracts" "missions," whatever) might speed things up. Certain science might also either speed things up, or actually be a requirement for tech to get past some milestone. So imagine my idea above. You start research, which incurs some cost in funds, and might also have required precursors (in facilities, other tech, or even specific science). That node appears on a timeline with milestones every "Minmonth" (I use Minmus months because the munar month in KSP is 6 days, and a Minmus month ("Minmonth") is ~50). You get there by simple time progression, but perhaps each milestone could have a way to jump to it via completing science/testing. Note that some milestones might require the previous milestone, but others might not, letting you leapfrog. Want to develop the Hitchhiker? Say that one gets 4 minmonths of dev time. Since as a station/base part, rendezvous and docking will almost certainly be a thing, perhaps the first month can be jumped by completing a docking of 2 vessels. The third milestone might allow an orbital mission of at least a month, but no precursor, so you could launch that mission, and a month later you'll leapfrog and save 2 months. You get the idea.

Yeah, like I said, I was looking for a small image to show the idea, did;t want to spam a huge image, so I took the first one I found that was : 1. small, 2. had an even number of engines depicted.

I make the best out of it by not using hardly any stock parts any more. Yeah, that was the first image that wasn't huge that I saw with multiple engine bells that were even in number. I could have used 5 F1s or J2s, instead, I suppose one on the node, and 4 radially, I was thinking in terms of 1 part with radial symmetry turned on though, so I looked for even numbers .

@Bomoo, that's just another game design flaw. Every rocket part in the game looks terrible. Even if they would look wrong, the functionality is needed (for example tanks becoming available in the tech tree with no appropriate engines, and the fact that any stage separator (also ugly) places fairings to the engine, and not the tanks it separates.

I gave up on stock interstages a long time ago... I hadn't realized that they had fixed that functionality. That's the problem with bad design that gets released, people learn that certain things are not possible, and never try doing it again. The interstage thing was so flakey for me, I gave up (I don't really like them at this point anyway). My biggest complaints are merely aesthetic at this point. Like every single other rocket part in KSP, the fairings themselves, and the base part are all transcendently ugly. That any parts are being added at all to KSP before making the rocket parts look decent sort of bugs me. Spaceplanes look like stunning craft from science fiction (which, you know, they are), whereas rockets---something that actually exist---look like they are made out of stuff cobbled from the junkyard. The base part (and every, single stage separator) needs to be flush. The fairings need a slight rounding to the transitions to look real.

Treating oversights on the part of the game designer as places to facilitate innovation on the part of the player makes little sense. You can stick an I-beam radially out of a fragile fuel tank (how many times have you seen this particular construction in the real world?), but you cannot have 2 or 4 rocket engines radially arranged on the bottom of the same tank, something you see literally all the time in the real world.

More in my continuing Apollo missions in 6.4X. (this was mission 2 to the Mun, taken before the LEM was pulled from the adapter) ' OTW back to the CSM.

I said in (astro)physics, not at NASA. Like I said, I'm sure that engineers, even after training otherwise use imperial for the simple reason you state, legacy tools (and training/staff used to those).

I think the pope that built the Space Shuttle and all our space probes "did" physics in the real world. Regardless, in astrophysics all the measurements are at scales small and large that are outside human experience, anyway (and we used metric, exclusively). It's absurd that military/NASA contractors kept using imperial as long as they did, but they had a workforce and tooling in place, so it was easier to just go with what they had and were used to. For actual hardware it doesn't matter, arbitrary units are arbitrary. Of course maybe cognitive science people have determined that imperial negatively affects cognition .

I don't think a rescale discussion is entirely off-topic. A user's guide to various rescales might not be a bad thing for us to bash out, anyway, as we're the ones using SSTU for that, not Shadowmage. I used to use KIDS for 6.4x, below that I simply use stock parts. If we nailed down definitive settings, maybe with 2 options (a MM patch, vs a mod dependency like SMURFF with the cfg settings) for common rescales: 2X, 3.2X, 6.4X, and RSS (10X), this could become a readme. Last night I simply experimented, figuring that if an R7 didn't make orbit there was an issue. I wish the gravity turn mod was updated to 1.1.3, because it would make replicating launches easier for this sort of testing. That said, I made Saturn V that was fairly convincing looking with all the right parts except for the LEM, and it got to the Mun. I didn't bring it home yet, so I think the CSM likely has more dv than it needs, which might mean a slightly lower SMURFF scaling than 0.64. I want to say that @blowfish had mentioned 6.4X someplace, I'll have to reread the thread.I was trying for as vanilla as possible.

I have SVE on, and I added SMURFF with it set to 0.64 except for the pods, which I set to 0. I don't know what others are using for their SMURFF settings for 6.4X, my goal was for an R7 with a Soyuz SM/DM/OM to make LKO with a little dv to spare. Set to the RSS value of "1" that combination makes it easily with the core stage retaining enough propellant to not want to throw it away.

We never used slugs in physics. Or pounds. Ever. We didn't even discuss Imperial units as a thing, not even in the early 80s, just SI. Someone did, I'm sure, but not anyone I ever saw.

So I decided to take my own advice, and instead of testing in stock, I reloaded k64. I made an R7 with a Soyuz on top... and just got it into orbit, so clearly something is working . I then started messing with an Apollo copy (I need to make S1 and S2 a little smaller). Still, got me to the Mun 6.4X as far away tonight. Version 1 of this lander made it to the surface with a few hundred m/s to spare. In testing an Apollo-like staged take off, I left that valuable fuel on the Mun... I made orbit only with about half the pod's RCS to spare for docking. The next version got some extra fuel.

Yeah, In English the trouble is that seconds vs m/s with the same term used is pretty confusing, hence "effective velocity" vs "specific impulse" usually being used for the two terms. I was trained in the 80s, and my professors were certainly of the 60s . I can certainly see the utility of the mass formulation, but I'd be worried about mixing up figures with available dv (in my head).