Sean Mirrsen

Haha, yeah. I remember a screenshot I'd seen, from the game IL-2 Sturmovik, that shows a severely beat-up plane, with torn off wings and broken engine, burning, in a vertical dive, with its pilot too injured to bail out. And the sole warning message on the screen is "Flaps Jammed".

Best solution for stuff like that is to just make it grabbable. What's the point of storing it in a container, if it's by itself a container? Just put it on your pod and it's with you.

The Cupola has less space than the Mk2 Can because it's a cupola. It has all that space devoted to being a huge dome-shaped window, and its internal structure is mostly empty space to look through. It still has more space than the Mk1 Lander Can, but the Mk2 Lander is literally nothing but two seats and a tiny window, the rest is storage space.

Seconding the inline container idea, both a small and a large one if possible. I like the capsules having some storage, but the capsules really shouldn't have a lot of stuff in them. Landers could have more space, but not that much. Here's the numbers I'd propose: Mk1 Command Pod - 10 <- Absolutely barebones, at most a solar panel or some connectors. It's a tiny thing with just enough space for the kerbal. Mk1-2 Command Pod - 30 <- Bigger, but not lavishly so. Three crewmembers and life support occupy most of it, and cargo space is scarce. Mk1 Lander Can - 20 <- A roomier pod, but for only one kerbal. Has space to bring some extras. Mk2 Lander Can - 50 <- Large pod, only two kerbals inside of it. Plenty of extra room and compartments. Cupola - 30 <- No matter how useless it may otherwise seem, it's still a two-meter pod for one kerbal. Plenty of space for parts. And forgot one more pod, even if it's not a pod: Hitchhiker Module - 80 <- Even with 4 kerbals inside of it, the sheer size of the thing allows for plenty of storage room. It'd be quite nice to have these actually added into the mod proper. Also. Is there any chance at all to make an option for a compact container GUI? I'm playing 1280x720, and I have to move the window to see the button at the bottom. I'd be fine to see less of what's inside the container or a smaller part selection window, but it's way too large for me as it is.

I think the best and most logical solution to this is to have the root-selector plugin be integrated into KSP proper. Let it have some limitations perhaps, but part trees can already be jumbled in any given direction by the docking system - having it available in the VAB would be a great help. And of course the bug I mentioned in the subassembly manager thread should be fixed. Root parts at the moment do not get checked for their surface-attachment node, so a craft built around a fuselage or a fuel tank (i.e. a custom booster or spaceplane) will not be saveable as a a subassembly if both of its stack nodes are occupied, despite the surface attach node being free - something that works easily with identical constructions detached from a surface.

No, not all rockets. What I meant is that stock Liquid Fuel is not hydrogen. Not innately at least, because kerosene is far more probable. Heck, it gets the first three letters right. And here stock Liquid Fuel is used in place of hydrogen. Where actual liquid hydrogen gas can be used, in plasma thrusters and the science lab - plus of course any upgrades to conventional rocketry might happen, since liquid hydrogen is indeed very much rocket fuel.

I don't think "most rockets" are really the focus here. Even less so than in the NFPP. Let regular rockets use Liquid Fuel, but advanced thrusters should be able to use pure Hydrogen. Would make sense for the science lab to split water into LOX and hydrogen, as well.

I wonder if you've any plans to switch to actual hydrogen instead of Liquid Fuel. Because Liquid Fuel isn't hydrogen. It's as dense as oxidizer, and way denser than xenon. Would synergize nicely with Near Future Propulsion, too.

I am not quite sure who you're replying to, but I'll assume that's me.Okay, so. I don't know how the plugin's logic works, or rather I don't remember because I don't have it on hand. Right now, this is how the ingame implementation works: If you grab any part other than your craft's root part, you disconnect a "ghost", of all the parts attached to the part you grabbed, with that part being the "root" of the ghost. Regardless of other circumstances, if you have detached this part somehow, then by definition it has a means of being attached. Therefore, any "ghost" disconnected in this way will be accepted as a subassembly. If you grab the craft's root part, however, you cannot actually attach it to anything. By sheer definition of being a root part, it can only have things be attached to it. However, the game is smart enough to know you want to save the craft as a subassembly whole. It checks the root part for active connection nodes, and if it finds them, it determines that the whole craft will be able to attach to something else. But this is where the game's logic fails. The root part is only tested for open stack nodes, which are two-way connections. It's not checked for the part's surfAttach node, which is used for surface attachment, and thus you can have a situation where your booster rocket, having a fuel tank or fuselage as its root, cannot be saved as a subassembly - because despite having a free surface attachment node, it is not checked for it. This is a bug, which Squad can likely fix in short order. Now, there is the matter of the mod that MedievalNerd speaks of, which changes the root part of the craft. It is absolutely unrelated to the mechanics by which the subassemblies are determined to be acceptable or not, as it changes the root part, and therefore allows a part with free stack nodes to be selected as the root - therefore bypassing the problem with surfAttach nodes. Once a different part has been selected as the root, the same mechanics and problems will apply to it. Presumably, as I haven't actually tested the root-switching mod yet. I probably should.

I don't doubt the effectiveness of the rootpart mod. It's yet another one of those things that could easily be stock functionality, for active craft, subassemblies, and ghosts all together.

No, it always checks just the root part. As I've said numerous times, subassemblies are the same thing as when you detach a part of your craft and leave it hanging as a ghost. No matter the configuration of the ghost, you will only ever be able to attach it back with the part you detached it with.

No, it has to do with the fact that the root part does not recognize its surfAttach node as such, and will show as "can't be attached" even though it technically can.

Well, your example is not valid because the pod is not surface-attachable, but I tested it with a long tank right now, and that does seem to be the case. In which case - bug report, anyone? That's not supposed to work like that. It works perfectly with regular subassemblies, if the assembly root part is surface-attachable it allows saving just fine. The craft root part just doesn't seem to register its surface attach node, perhaps because it can't actually be attached to something normally.

I seriously have zero idea what you people are smoking. (I mean it, I'd have to have surveillance over there or something. You probably aren't smoking anything even, but I seriously dislike to have to question peoples' regular cognitive abilities.) You can grab anything and make it a subassembly. It follows the same basic rules, it just has to be attachable to something. That means having a free attachment node, or an available attachment surface.

The built-in one allows surface-attached subassemblies. Please check whatever you are smoking for impurities and look again. Anything you take off from a surface, will be attachable back to a surface.

Does it launch frogs as it launches like the real thing as well?

He does seem to get concerned when his crashes crash the universe, however.

I spot a few missing buttons. Namely, a pretty important one for Fine Control toggle, and a set of somewhat important ones for trim, as I see no way to set trim currently. The nature of these buttons sort of requires there being some ways of having precise controls. Also, consider moving the Abort button to a separate panel and making it more distinct. Perhaps larger. By its nature it's a button you want to be able to reach quickly and hit reliably when you need it, while letting it be out of the way at all other times.

I'd propose LDS, but that's an entirely different system. Which I'd still like to see in KSP in some form, probably. People who have no idea what the Independence War games are about might also know it as Stutter Warp.And personally I was always in favor of a "Decompression Drive", or "Space Decompression Drive". Because as you know, the KSP universe's space is innately compressed tenfold...

Hmm... no, I don't. I literally went through every post of mine on this topic just now to make sure I haven't said anything that can be misconstrued as such, and no I am not referring to my desires as "realistic" by any stretch of margin. FAR attempts to be realistic. KSP is set in an unrealistic universe. Together this results in complexity, which is good, but too much of a decrease in difficulty where that complexity doesn't show as much, or is easily overcome.(I have, for the record, just reinstalled FAR to see what actually changed since I last played with it. Jeb's expression says it all. Clearly I need to get used to building these things again. ) It does accomplish a change in difficulty, but I feel it does this from the wrong end. FAR is about the atmosphere and aerodynamics. It has no business adjusting engine parameters (and I mean to take FAR and KIDS as one mod in this case, as they're by the same author), especially not if doing so affects things not otherwise affected by FAR - like VTOL craft on oxygenless planets, that need to hover without jets.And indeed, I aim for verisimilitude over realism, in the same way KSP itself aims for it. Accurately realistic mechanics are good, complexity is good, but it's also good to remember what kind of game we're playing here.

There is a game - or, well, will be a game - called Space Engineers. If there's anywhere the two playerbases shall meet, it will be there. Turns out ships need reverse thrusters to stop. Who knew?

Hmm, now that might be worth looking into. Thanks. I'll still do that experimental testing thing later on, to get some proper numberage on the differences in difficulty between FAR and KSP Stock. Right now it seems this discussion can't progress further without that data, since general ideas seem to be hitting a brick wall.

It does not guarantee that at all. But it's a closer mark than FAR itself is. And I don't want FAR to be altered for everyone. I want to be able to tune it - preferably without rooting through the whole of its config file, manually multiplying coefficients. Plus of course I'm trying to promote my own viewpoint, because it is much easier for an idea to get traction if more than one person agrees with it. The troubles people have with FAR stem mostly from control, or at least that's what I would expect given my experience with it. I mean strictly rockets here, spaceplanes are a whole different kettle of fish with FAR. The changes FAR makes to control surface effectiveness and rocket stability at high velocities make rockets harder to steer, large ones especially. But once you adapt to make the rocket steer well and learn how to avoid the pitfalls of the new system, the aerodynamics aren't nearly as harsh as they could be. Maybe I just adapt too quickly to the challenge, who knows. But I don't find the control difficulty a sufficient tradeoff for the reduced air resistance - as I said, even for bad designs. One of these days I'm going to reinstall FAR and perform some actual science on this. Probably around the same time I unlock all of the tech tree in Career. I'll be back with the experimental data then.

No, the three are basically the extreme ends of the "unaerodynamic" versus "aerodynamic" rocket shapes scale, with a kind of a middle ground inbetween. The "middle ground", whatever it ends up being, should probably be what the FAR/Stock dichotomy should be balanced against - with both room to improve, and capacity for worse design. I basically suck at making recognizable charts, is probably the thing to take away from this.

Correction. I want to displace Earth-universe realism in the service of "I want FAR to be KSP with improvements". Kerbin, by its very dark-matter-comprised nature, is not realistic. By using realistic aerodynamics in an atmosphere a tenth as thick as it's supposed to be, FAR is making launches that are already easy, unrealistically easy.I... really don't know how to put what I'd like to see in better words. Maybe a picture? Here, I'll treat you to the kind of artistic prowess I am only capable of when not using my Intuos: KSP vs FAR illustrated chart. I want realism and complexity, but as long as that doesn't make the game easier across the board, darnit. Yes I know spaceplanes are harder. Yes I know supersonic control issues. But the new atmosphere is just a little too thin.