renhanxue

Missing part "orbital-engine-0625", so I can't load it. That being said, what does "absolutely won't launch" mean? Does it perhaps flip over when you reach a speed somewhere in the neighborhood of 300 m/s? In that case, that's not because it's unbalanced, that's because it's aerodynamically unstable. The aerodynamic center is in front of (or perhaps more accurately in the case of a rocket, above) of the center of mass. Try sticking four fins at the bottom of the rocket, but I suspect in this case it may not be enough because of all the incredibly draggy stuff you've got hanging off it. The lander should be covered with a fairing, and you don't need pretty much any of those struts at all. If you need to stabilize the asparagus boosters just use autostruts. External fuel lines are downright exotic in the post-1.2 era as well (they're essentially never needed, just enable fuel crossfeed on the decouplers and the external tanks will be drained first automatically - only disadvantage is that KER still doesn't calculate dV correctly).

I don't get it. Like, at all. I play with no extra ground stations once I've unlocked the RA-2 because I can't be arsed to set up three sats with HG-5's only to scrap them five minutes later when I get the RA-2, but I don't get it anyway. With two sats in modestly high orbits (which the HG-5 of course isn't useful for) you get coverage of like 95% of the surface of a body like 95% of the time (actually it's probably very close to 100% in practice with the default occlusion settings, but that's beside the point). Adding a bunch of HG-5's in impractically low orbits around everything is just busywork for no meaningful practical gain. I mean, I guess if building relay networks for 100% coverage is what you enjoy doing in KSP, go right ahead, but you really don't need much of a network in the stock game. A lot of people I've seen overbuild theirs to an incredible degree. I put relays around the Mun and Minmus in one game and then I got tired of all the busywork and never bothered again. Once the network for bouncing around the sun is in place and I have a few random RA-2's on scansats and other various spacejunk the blind spots never really become an issue again. I mean, the thing here is that powerful relay antennas are so cheap and so light that it's much more practical to get good coverage with a few high power general-purpose relays very far away than it is to have a whole bunch of specialized low power relays close by.

How does that figure? A probe core weighs about as much as a HG-5 does. In general you never really gain anything by getting more relays with smaller antennas. The limiting factor for relays isn't really delta V or weight anyway, it's how much effort you can be bothered to expend getting them in place. I really wonder how on earth you're setting up your relays though if you have that many HG-5's. I mean, KSP is pretty much a sandbox even in career mode so if you want to need HG-5's of course you can create a need for them, and it's not like using them is "wrong" in any way, but still. If all you want is a "good enough" relay network, you only need two relays per planet (highly eccentric polar orbits around the primary with apoapsis near the edge of the SOI, 180 degrees out of phase with each other) plus maybe a few to let you bounce around the sun. That only leaves very small blind spots near the equator of the primary and on the far sides of the moons, and while you can go to the effort of putting three evenly spaced HG-5 relays in a low circular orbit around every moon in the entire Kerbin system to get perfect surface coverage everywhere, I personally really can't be bothered. Just slap a RA-2 on the transfer stage and leave it in whatever orbit you end up in around the moon you're visiting and there you go, good enough.

Well, as I said: the practical use cases where that would actually be meaningful are rather contrived. You have to try pretty hard to find a spot where a HG-5 in low orbit (and you can't really put it in high orbits because it's so weak) can reach a stronger relay but the lander on the surface can't, and even if you do have such a spot, why not use a RA-2 instead? Sure it weighs twice as much (a whopping 80 kg more) but it's also four hundred times more powerful, so you can leave it in a much higher orbit where it's over the horizon for longer and easily reusable by other missions in the same system, and it's much less likely to drop connections or devalue your science transmissions.

The HG-5 is pretty much a toy antenna. There are some rather contrived use cases for it, like Apollo-style missions to the far side of the Mun with the HG-5 in a low orbit above a lander, but really, there's no real reason to ever use it. It's just too weak. A command pod using its built-in antenna will lose contact with a HG-5 relay at the impressive distance of 158 km (one hundred and fifty-eight kilometers, not a typo). If you put on a Communotron 16 (the humble red-and-white extendable whip antenna), you can now reach the HG-5 from an absolutely jaw-dropping distance of 1581 km, or about half the altitude of a keosynchronous orbit. If you're going to Duna, bring a RA-15. It should be able to reach even a level 2 tracking station at the KSC (unless Duna and Kerbin are very far away from each other), and a Communotron 16 can reach it from anywhere within Duna's SOI. Here's a handy cheat sheet for max ranges (in meters) between two craft with a single antenna each (and between a craft with a single antenna and a fully upgraded tracking station at the KSC):

You're kinda missing the point Boris-Barboris is trying to make, here. If the aircraft is statically unstable at a given set of conditions, then any perturbation (such as control surface input or turbulence) will lead to a self-reinforcing pitching, yawing or rolling moment - that is, a positive feedback loop. Pitching up will cause a moment that works to pitch up further, for example. That is what Boris-Barboris means when he says that such aircraft are good at flipping over very fast. To fly such an aircraft in a controlled way, all such moments must immediately be counteracted by counter-moments, so instead of fighting the correcting moment you're fighting the tendency to flip over. If the aircraft is statically neutral on the other hand, a perturbation does not lead to a correcting moment, but neither does it lead to reinforcement of the perturbation. What you are describing is essentially that, and Boris-Barboris wants you to use the correct terminology for it. (I think. Sorry if I misunderstood anything.)

The TF30's in the F-14 (which entered service at roughly the same time as the Viggen) suffered from the exact same problem, possibly to an even greater extent, but unlike the F-14 the first Viggen version was a strike aircraft, not a fighter, and in practice didn't care as much. On the air superiority version which came along ten years later, Volvo Aero added an extra compressor stage to the engine and much reduced the risk of compressor stalls at high AoA. Still, though, the Viggen is still a gigantic, vaguely triangular, flying barndoor, and while the air superiority variant actually had a legitimately good instantaneous turn rate for its time, if you had to make more than a full circle, well, you might as well call it a day.

The Viggen's canards have flaps (which incidentally cannot be directly controlled by the pilot, they have three possible fixed settings that are configured by the ground crew depending on the weapons load to keep trim reasonable in flight, and otherwise only deploy together with the landing gear), but are - as p1t1o correctly points out - not control surfaces. Instead they serve both as vortex generators that increase lift on the main wing, and to improve local stability at certain angles of attack. The concept is known as a close-coupled canard wing and it was (as far as I know) invented at Saab in the early 1960's (at the very least they filed for a patent on it). If you want to know how it works, there's a lot of interesting details to be found in one of the few really in-depth texts about the Viggen in English: a NASA technical memo that is a translation of a text by the chief aerodynamic engineer of the Viggen project, Krister Karling. It's actually a fairly accessible text even though it goes into a lot of detail, since it starts from a quite basic level, giving you a quick crash course in aerodynamics, and works itself up (or down, depending on how you look at it) from there. The Gripen's and Rafale's canards both exploit the close-coupling effect to improve low speed/high AoA characteristics (basically, to get a lower landing speed), the Gripen because it was designed for short-field operations and the Rafale because there is a naval variant for carrier operations. The Typhoon on the other hand has far smaller canards that only really serve as control surfaces - they were intended to increase maneuverability to a ridiculous degree in combination with thrust vectoring, but the Typhoon's thrust vectoring engine was cancelled and so it maintains its position as king of expensive boondoggles and bizarre developmental dead ends.

It should take signal strength into account, but as far as I know, it only recalculates every once in a while to avoid constant path switching and other unwanted side effects. I've also heard rumors about the path calculation occasionally bugging out, but haven't seen anything conclusive about it.

I'm sure the guy who posted this back in 2013 appreciates this advice!

Yep, that's it. I don't remember the exact numbers off the top of my head but the orbital period for a 100 km Kerbin orbit is something like 30-35 minutes, so by halving a 26 minute burn you'll end up starting on the wrong side of the planet. You need to split your burn into many smaller ones - probably around 3-5 minutes each. The longer they are the more dV you lose to not burning in the right direction at the right time, but on the other hand the longer you take to complete the burn the further off the correct ejection angle you'll be. It's a tradeoff.

No fight, just contributing pointless trivia here

I may be missing something completely obvious, and this is an extremely minor problem even if I'm not, but... I think the standard size flexotron docking port is upside down. On regular docking ports you can tell which way is up by the "window" on the docking side (up) and by the yellow arrow on the mounting side (points towards down), but when I choose "control from here" on a flexotron mounted like that, the navball is upside down from what I expect. Again, this is a completely trivial problem but it's nice to be consistent, isn't it? Haven't tested the jr and sr variants.

The accuracy of a IEEE 754 double precision floating point number in the range 221 to 222 is about 4.66*10-10 - in other words, the "spacing" between representable numbers is about 0.000 000 000 466 (spaces added for ease of reading). The more you know! (The accuracy in general for an IEEE 754 double in the range 2n to 2n+1 is 2n-52, which gives the usual rule of thumb of 15-17 digits of precision.)

Right, seems they reworked this at some point and the wheel controls (steer left/right and drive forward/reverse) are completely separate from flight controls now. They're bindable under input -> vessel, default to WASD (IIRC) and you can select when you bind them which flight control mode(s) you want them to be active in. If you want to drive in linear docking mode, bind wheel forward/reverse to shift/ctrl and steer left/right to A/D and deselect staging and rotational docking when binding them. I think?

What's the orientation of the command module (and hence navball)? If the navball isn't showing you as level with the horizon, you're gonna have a bad time no matter what your controls are. I've never actually used docking mode ever so I don't know how that even works on rovers (I guess you accelerate/reverse with the throttle controls and steer with the yaw controls?) - personally I just mapped the wheel controls to the numpad.

Technically possible but highly unlikely to be the sole cause of the problem. The 16-S isn't combinable, but a single 16-S vs a RA-2 still has a max range of around 31.6 megameters. Duna's SOI radius is only around 47 Mm. Under what circumstances does that happen? I really haven't done any testing of this but I have noticed that my ships are quite willing to choose a path through a close relay even though Kerbin is directly visible and in range, if it gets them a better connection.

I can't see exactly where the relay's connections are going but even before you decouple you're not connecting through it, you're connecting directly to Kerbin even though you only have 4% signal strength. That shouldn't happen - the routing will tend to choose the strongest signal path. Either there's a broken link between the relay and Kerbin or it's not actually acting as a relay for some reason. edit: a common problem I've seen people run into is putting a weak relay antenna and a strong normal antenna on their interplanetary relays. That will give you a scenario like this one: it looks like the relay has a connection to Kerbin, and it does, and it looks like your ship has a connection to the relay, and it does, but you can't relay signals through it because the relay antenna and the direct antenna do not combine signal strengths with each other for the purposes of actually relaying. The relay antenna(s) on the relay sat need to be able to reach Kerbin on their own for relaying to work.

This is getting off topic for this thread, but... I think there's a point I'm not getting across here, so I'll try one final time. Your intent is good, and I apologize if I'm coming across as antagonistic or hostile, but I am still of the opinion that you're approaching the problem in a fundamentally flawed way. Optimization is very much an empirical science, and without profiling you are like the ancient Greeks trying to theorize on the workings of the universe without ever really observing it. It is not at all uncommon (in fact, it is probably the ordinary state of affairs) that when you profile software to see a few very small "hot spots" that are responsible for the majority of the total run time and every other function in the program contributing somewhere between a few percent each and approximately nothing. The difference between a "fast" function and a "slow" one can be (and usually is) several orders of magnitude. Once you realize this, it is easy to see that trying to optimize a function that is taking 0.5% of the total run time will in practice have no meaningful performance impact whatsoever even if you manage to eliminate it completely. That's why I'm trying to tell you that optimizing code without profiling is a fool's errand - you can improve performance by 25% but you can also do absolutely nothing, and then why did you go to that effort? To a certain extent it is possible to reason about the performance of software on an abstract level based solely on the code as written, but modern systems (especially managed ones like Mono) are so complex and far away from the hardware that the results when running in the real world can be completely different from what you expect. You simply must profile to have any idea about what you're doing. As a rule of thumb though, basic arithmetic operations on a modern CPU are so cheap as to be basically free. I'm not kidding - if you try to do a few dozen arithmetic operations on a number, put a lot of numbers in RAM and then see how many of them you can process per unit of time, you'll actually bottleneck on RAM bandwidth long before you are anywhere near saturating the CPU's ability to crunch numbers. As long as you only do simple arithmetic and don't try to do I/O or allocate/deallocate memory in a function, you can regard that function call as (essentially) free until profiling proves otherwise. If you start doing many thousands of calls per frame, then maybe you'll notice it, but otherwise, nope. KER assumes (rather reasonably, I'd say) that calculating the cost of a part isn't a very complex operation (for fuel tanks it's a few multiplications and additions, for everything else it's a constant), and so does not hesitate to call that function often. All of that being said, having looked into the simulation code with the intent of getting into KSP modding and possibly fixing that bug I posted about above, I think the simulation code could probably use a once-over... but that's a lot of work.

You're trying to eliminate code that you don't know if it has a meaningful performance impact or not. It's a good instinct in general to try to avoid calling code that doesn't need to run, but it's the definition of premature optimization to do so before having benchmarked it and finding that it has a meaningful performance impact that you want to avoid. Have you profiled it?

Yes, KER calls GetModuleCosts once on every part every time it constructs the parts tree, which it does every time the fuel flow simulation runs, which, in flight, is "all the time" (like, literally, it hooks Update() and starts a new simulation as soon as the previous one is complete). In flight it wouldn't need to do this since I don't think you can actually show the cost in a GUI readout, but unless you're doing some heavy calculations in your GetModuleCost implementation this shouldn't be an issue in practice. Try benchmarking it and see if you can even get a meaningful run time measurement out of it. As Donald Knuth (peace be upon him) said: premature optimization is the root of all evil. The relevant code is at PartSim.cs line 130 and PartExtensions.cs line 81.

For interplanetary, I think most people just come to terms with the five to ten minute burns. If you think the nuke is bad, you should try the ion engine. The actual lesson here though is that building very small rockets is actually really cool and interesting. There is a point where bringing along three tons of nuke engine becomes a very unappealing option, and then you can start doing zippier rockets with small liquid engines.

No need to apologize, if anything I should be the one to apologize because I think I was rather unnecessarily rude in my response to your well-intentioned advice. I do have some vague memory of the message you describe as well, but I've been away from the game for a long time and can't remember any details. As an aside, another thing I discovered is that mounting a mk1 structural fuselage on the bottom of an engine works fine. It actually is hollow as far as the thrust collider is concerned.

I don't know what the log may or may not have done in the past but I can tell you that right now it most definitely does no such thing. It won't even say that if you attach something directly to the node on the bottom of the engine. It'll tell you that whatever you put there exploded from overheating sure enough, but nothing about thrust occlusion.

Bug: while in flight, KER considers engines that have been activated through staging and then shut down manually as active for the purposes of dV and thrust calculations. This is mildly annoying on spaceplanes if you use an action group to shut your airbreathing engines down manually rather than letting them flame out on their own, because when you shut them down, KER will continue showing airbreathing dV until you reach the point where the engine's thrust curve reaches zero, and after that it will show your dV as NaN regardless of what your rocket engines are doing, so there's probably a negative root or a division by zero somewhere. The vessel mass is shown as 0 / <total> once you shut down the air breathing engines, so that seems rather suspicious in context. MechJeb does it right and does not consider shutdown engines. I haven't debugged it, but taking a quick look at the code I noticed that when looking up which engines are active, there's a check which after a couple of layers of abstraction ends up being the equivalent of ModuleEngines.isOperational && !ModuleEngines.flameout that may be intended to prevent this behavior. I'm not sure what isOperational actually means but are you sure you shouldn't be checking isEnabled instead?