Eric S

That's not where I got that number from. I counted the stacks, double checked the number of liquid engines in the staging bar, etc. Unless he's doing something wrong and not firing all of his asparagus stacks at the same time, that ship has 9 asparagus stacks, which means two branches of four stages, coming together at one central stage. The SRBs are another stage, but has nothing to do with the asparagus staging.

Also note that they left the Mun's SoI when you were off doing something else, so it's even more likely that you had warp going at that point. I've never seen a case where that hasn't happened, but I haven't exactly gone digging to make sure that it never happened. I have seen it happen, but most of the time I'm not paying any attention to it.

If I had any idea what he meant by "flight control module" it might be useful input. Unless you're building rockets so large that you need more command authority, I don't see what he could mean, and the limited part selection kind of discourages you from trying something that big. Having more parts would just make this worse. He's not talking MechJeb, is he? If you've unlocked Stayputnik, you've unlocked tail fins, reaction wheels, etc., so I'm not sure what else he could be talking about or why he's having problems controlling his existing craft. Possibly running out of electricity, but if he doesn't know that's what's happening, adding more parts probably won't help. Maybe he's talking about the inline advanced stabilizer, AKA the heavier version of the reaction wheel because he doesn't know about the SAS+reaction wheel changes that happened in 0.21? We don't actually know that. This honestly sounds more like someone with at least a little experience that is either expecting mods or hasn't followed how things have changed within the game, and no arrangement of the tech tree other than including all parts and all mods at the first node (as in, turning it into sandbox mode) is going to help without knowing what the actual problem is. Proven wrong within this thread, and I'll second the comments that did so. I found them helpful. Then again, I had never studied orbital physics, so I didn't know anything about how to do orbital maneuvers.

Exactly. A realistic penalty that makes it not worth doing except under specific circumstances instead of a flat "Don't do that" rule. Actually, I'd disagree on "typical asparagus abuse." Five asparagus stages (counting the center stack) to me is just into what I'd consider abusive. It's the 10 stage asparagus stacks I was thinking of, and even stacking fuel tanks that high, you'd be looking at dropping the tanks in half the time in that case. Still, a valid counterpoint to my idea that would have to be kept in mind during balancing. I had read somewhere that they were at least considering the 4+4+1 plan with the new engine setup.

So you're saying there should be a severe accuracy penalty for using two ranged weapons at the same time? Funny, that's what I said at the time. "Don't do it because I say so" reasons bother me. Even "there's a 1% chance that you'll cross the streams, causing both phasers to explode" would have been more acceptable than just "don't do it." There are reasons that asparagus isn't used in real life yet, the biggest problem is that none of those reasons depend on something currently modeled in KSP in such a way that it adversely affects asparagus staging. Heck, just having stages dropped on the launch pad damage the launch pad which in turn causes repairs that bite into your funds would kill the deep asparagus designs because they don't get far enough away from the launchpad before they drop the first set of tanks. The "unintended consequences" is that would make disastrous launchpad failures even more expensive, but at least that can be "Revert to Vehicle Assembly Building"ed away. Hmmmm.... the more I think about it, the more I like that idea, especially given that it's something the devs have said that they want to do. The more stages you have, the bigger an issue it becomes because with asparagus staging, that means that your first staging event happens soon. Heck, I've had designs where the first staging event happened at less than 500 meters.

When there are more realistic ways of achieving the same effect, yes, this is too unrealistic. Frankly, I agree with what you're trying to fix, just not the mechanism. The problem is the fact that we can use transmissions to grind out all available science in a single trip, and do that in multiple biomes. If either there were a limit on how many time a given piece of equipment could run a single experiment, or if there were a limit on how much science you could get in a single experiment/biome via transmissions, then returning experiments would be more important. Admittedly, pure sensor experiments don't fit into this model well, but for those that do, it's more realistic than what you're suggesting. Not saying that this method would be better in all regards, just saying what I don't like about your method.

Actually, from what reading I've done, it sounds like that wasn't a hard answer. They've given three different answers to questions about life support. "We're not doing it." "We're not doing it right now, and when we do, it'll be mandatory" and most recently (less than a week ago) "If we do it, it'll be optional" that I'm aware of. This is probably because they don't have an intricate plan of the final state of KSP, it's more evolving as they see what they can do, how the players react to different things, etc. The devs have stated that they're not interested in generic difficulty levels (this has been misquoted as meaning that they're not interested in difficulty levels at all). What they do seem open minded about are "realism options" and the like, where you could turn life support on or off. Not one setting, but several, each with specific consequences. And they have said that they plan on making relay satellites a thing to enable science a long way from Kerbin, though they didn't say if that was going to be an optional setting.

Correct, I used a Communotron 16 on my Eeloo lander and on my Jool atmospheric probe with no issues.

It's the same bug, not all of the incorrect results get multiplied by 10. It's actually because the popup doesn't know that different experiments can have different data amounts for the same internal science value. Atmospheric analysis gets 10 times as much data, some of the others get three times as much data, and the popup trips over both categories.

It would have the effect you want, but I think it would have some serious drawbacks in other situations because it doesn't matter what you're using the radial decouplers for, a 0.625 m probe or a 6.25m superbooster, it adds the same amount of drag per stack. Which means that even the perfectly normal and acceptable large center stack with two narrow solid boosters gets penalized. If you want to use aerodynamics to kill asparagus staging (it probably won't, but it could probably kill the multi-layer asparagus abuse), then model aerodynamics to do so, don't hack up something because you don't like it. It reminds me of the old Star Trek roleplaying game, where they actually had rules for dual-wielding weapons that didn't restrict the rules to melee weapons, they just said "Sulu would never consider using two phasers at the same time." Mass that a 7 stack 3.75m asparagus cluster wouldn't notice would be enough to ground my little Mun lander that only uses fuel lines to suck fuel from radially mounted tanks because without them, it would be too tall to land safely. Having different fuel lines (with differing masses) for different fuel flow amounts is just adding complexity to the game that would affect most designs just to stomp on one class of design, but at least it would have fewer negative consequences other than the complexity itself. It's really these kinds of unintended consequences that you have to watch out for with ideas of how to limit asparagus staging.

There's a small part on Spaceport that accepts samples and EVA reports. You can either mount that on something small with a docking port on both ends and have the lander pass it off to the orbiter, or you could add KAS to the mix and have a kerbal unmount the part from the lander and remount it on the orbiter. Neither is an ideal solution as any of your other results won't transfer. Personally, until this gets fixed, I'm just not doing apollo style missions. I'll leave a transfer module in orbit if I want to, and dock back up with it.

Yeah, that threw me at first too until I realized that you had to round up to a multiple of the packet size. Since all the antenna currently have a packet size of 2, just multiplying the Communotron 16's energy requirement still works though.

In flight, you can right click the part providing the KER ability (the Kerbal Flight Engineer part or modded capsule) and toggle the KER interface. Actually, if you turn off the other displays (usually main display, reference bodies if you have it open) and then compact it, you get a window that's just barely larger than the "Compact" button.

I dislike it because it feels too unrealistic. NERVA was in testing before we set foot on the moon, and supposedly ready for a run-up to actual deployment shortly thereafter. As I understand it, what you've done will affect what optional missions career mode offers you, but that's as far as it will go, and as far as it should go unless science gets a lot more complicated than it is now. If science is going to be more complicated, I'd like the complication to be grounded in reality rather than arbitrary goals. That said, I'm not opposed to return samples or even recovery of experiments providing benefits that transmitting results back don't, even if it's just a different diminishing returns cap.

You think that's bad? wait until you start trying to define where "upper atmosphere" turns into "space near kerbin." I've had EVA reports return "upper atmosphere" as high as 68km, which makes sense. However, I've had "space near kerbin" come back from EVA reports as low as 30km. Also, some moons have a "high orbit" that's lower than their tallest mountain peaks. There's just something wrong with lithobraking in "high orbit." It may be that the devs are waiting on the development of something like ISA_MapSat with biome detection abilities to reveal biomes without being directly over them and doing an experiment, but I haven't seen a dev as much as hint at that. While I don't consider this a major omission, serious shortcoming, etc., I do think it would be a nice addition, either as a science part that maps it or just as a "you are over an unidentified biome"/"you are over biome X" status.

I suspect what you're seeing is that trajectories crossing an SoI can go wonky if done at high warp. Since you're not paying attention to the debris, it's quite likely that you're warping when the debris makes the SoI transition. Debris definitely follows ballistic trajectories including gravity of SoI, etc. It doesn't encounter atmospheric resistance, though it will get deleted if it goes far enough into an atmosphere (the limit for Kerbin is somewhere around 25km).

I suspect that they'll be adding range limits on those antennas at some point, along with the possibility of using relays, at which time a satellite could be useful, but not at this time, and it's not even definite that they are going to do this. They've tossed around the possibility, that is all.

And if you want a tldr, it looks something like this (my notes may not be accurate, but they're not too far off if they aren't accurate): Using the communotron 16 as a baseline: Crew Report: 30 electricity EVA Report: 40 electricity Temperature Scan: 40 electricity Mysterious Goo: 50 electricity Atmospheric Pressure: 60 electricity Materials Studies: 130 electricity Surface Sample: 150 electricity Seismic Study: 250 electricity Atmospheric Analysis: 1000 electricity Now, if you're using a DTS-M1 antenna (mid-tech dish) you increase those numbers by 50%. That antenna takes 80% as much time to send a report. The Communotron 88-88 takes 100% more power, and takes 60% as much time to send.

The popup that displays the results and asks if you want to keep them is currently bugged and overreporting the science that that part generates by a factor of 10, and if you watch it when you turn it in, you'll see you get a lot less for it than it claimed. And yes, the devs have confirmed that that is the bug, the bug is not that you're getting less science than you're supposed to. There's two other science instruments that suffer from this issue as well, but I can't remember what they are right now.

Which is also true, but any rocket that can't control a roll has issues to begin with, regardless of what staging it's using. Most people I know that say that angular momentum would kill asparagus staging say it's because the roll is uncontrollable, and that just isn't the case. Yes, if you let a fast roll build up you're going to have a hard time stopping it, worse than in a non-asparagus craft. The point is that you shouldn't let it get out of control in the first place, and nothing about asparagus design would make it that much harder to keep it from rolling to begin with. I agree with that, even if I have rarely taken it to such extremes (rarely enough that I can't remember the last time I did). I almost never go beyond six stacks around one, I'd rather go larger than add another layer, and even with the radial decouplers that put distance between the two stacks, eight stacks just get packed in too close to each other for my comfort. However, I have no clue how to kill multi-layer asparagus without affecting regular aspargus, and I'm not sure I'd want to at any rate, because that would feel like "my play style is ok, but you're taking it too far."

There will probably eventually be optional missions for those that need/want guidance or something to focus on, the devs have discussed it. But they'll be just that, optional.

For my first mission, I tend to use a capsule with a parachute on it, 10 fuel tanks, and an engine. That gets to orbit, then to high orbit, then returns. The return is a bit messy because the one parachute isn't enough for that mass, but 10 fuel tanks makes for a perfectly sufficient crumple zone to make the landing safe, though not quiet. On the other hand, that's enough science to pick up the first four techs without having to go crazy with Munar/Minmus/Sun flyby/orbit missions that take a lot longer and tend to be a pain without decouplers.

I write most of that off to people being highly opinionated about anything that they're THIS passionate about. There are a few people that I'm not sure are ever going to be happy until the game is almost finished, if even then, but most of the complaints are just because people aren't patient enough to wait for polish and this has given them ideas about what they really want to see.

Getting slightly off topic here, I feel that fuel lines are a sticky problem if you want to discourage asparagus staging without discouraging legitimate uses. Fuel lines mostly have three uses. 1) Asparagus staging or crossfeeding (directly towards the center). I'm including drop tanks without engines in this category as well, though those are more practical and barely post-Saturn-V tech. 2) Controlling shift of CoM on spaceplanes. 3) Connecting radially mounted tanks that aren't separately staged. This isn't an issue you encounter in real life often, because in real life, they'd just make a fuel tank with a custom shape, so we're not talking post-Saturn-V tech here. I don't think anyone has problems with fuel lines for cases 2 or 3, and most people don't have a problem with basic crossfeeding, it's just asparagus staging that they have a problem with. Too much of a good thing, I guess. Case 2 probably needs a non-fuel line oriented fix anyway, and assuming we get a fix like that, I've got a solution for case 3. Two levels of fuel lines. One that can only connect tanks within the same stage (not separated by decouplers/separators/etc) which would be useful for case 3 but not case 1, and full on as they are now fuel lines that could be used for case 1. Case 3 could probably also be handled by making liquid fuel and oxidizer flow between stacks like all the rest of the resources but not across any of the decoupler-type items. This way you wouldn't need fuel lines to deal with this, but you're still not draining fuel from one stage to feed another except by deliberate action. I actually like this idea better than my first suggestion, but I'm not as sure that it might not have unseen consequences. Agreed. Personally I think that asparagus staging is the natural adaptation of 100% reliable infinite flow fuel lines combined with lower than realistic TWR so I don't have a problem with that, but I still like knowing that I can get away without it (or even knowing that I can't for my really huge payloads). Especially when you're dealing with a sandbox game where there is no difficulty setting and the only way to make something harder is with artificial restrictions or doing more ambitious missions. This is definitely what I see as the biggest issue in the current science implementation, and I think most people are of the same opinion. Personally, I think any of the three changes here would be an improvement. Which would be the best improvement would depend on just what effect you're trying to have. I obviously have my favorite because it pushes the player towards return missions without punishing early one way trips too much, but it does little to curb multi-SoI missions that get huge returns by doing a little science all over the place. The "charges" on the science equipment is the only proposal short of eliminating transmitted returns on at least some of the experiments that I've seen that would curb that. Then again, not sure that it would feel that abusive if we have decent limits in place that cover the single SoI or single biome missions. Agreed, I think it would be an interesting mechanic, I just don't see how to achieve the desired result. Obviously you don't want to just let them ship all the needed resupply parts/whatever along in the original mission, because then it does become "time warp towards science." Yeah, what I said wasn't really a reason not to, more just a matter of "this might complicate balancing the costs of the tech tree."