Jovus

Don't I know it. The other part, however, was serious. It seems like saving the shape of the craft on build and then treating aerodynamic forces according said shape might actually save cycles. On the other hand, maybe voxel-based calcs are actually more intensive than part-based calcs? I don't know. But I'd be interested to hear someone with more expertise opine on the subject.

Yeah, @Claw, that was the joke.

I have another tip: Remove all foreach and LINQ occurrences in the code because the compiler the latest version of Unity ships with is handling them in a non-optimal fashion. Anyone? What? To be serious for a moment: you might get away with a lower altitude switchover from planetary textures to planetary colliders, or whatever the appropriate technical terms are. And (perhaps) a voxel-based aerodynamic system that saves the voxelization and uses it instead of calculating the aerodynamics on a per-part basis might cause a performance boost. You could save several voxelizations based on control inputs (flaps deployed, full/partial roll/pitch/yaw) or calculate the effects of control inputs using solely those parts as deviations from the default voxel-matrix. (This isn't a snide 'look at how great FAR is', but actually a serious suggestion. But it'd need someone to think hard about it to figure out if you'd actually have any runtime savings.)

Ooh! One I think I can answer! I believe that RSS' RemoteTech config uses the Root calculation method instead of the Base/Line/Whatever-it's-called default method. What this means is that range is not a simple flat number depending on the weakest antenna involved, but is a function of the power of both antennae in the link. So your basic integrated omni has a nominal range of 200km, but when it's talking to a ground station with a range of something like 1800 Gm, it can do so from quite a ways away, because your DSN dishes are good at picking up weak signals. Unless I'm totally wrong, and there's a config error somewhere.

What are you doing, trying to encourage moderation? ... Probably a good idea; this thread needs some moderation.

IS THIS BETTER? you discriminatory human

Thread 10/10 would read again But seriously, we're all being narrowminded. Why stick with RCS and SAS variable inputs? Imagine the possibilities. If I mash Z harder, the craft goes faster. If I mash B harder, the craft decelerates faster. If I slam on the pitch enough, the craft goes to higher/lower altitude. This way my cat could play KSP. And really, isn't that what we all want? Cats able to function in modern society despite their disadvantages? You disagree? What are you, some kind of felinist?

@Padishar I pretty much agree with you, and I think making it toggle on solves a lot of the issues raised by those arguments. Not that I'd be sad if it were a toggle off, or just on all the time; I'm in the camp of not seeing how you can play this game without a delta-V readout. Just trying to do my bit to represent another facet of the issue in what I hope was an accurate manner.

Yes, it did. Yes, the argument applies to pulling out or never adding maneuver nodes. That doesn't make it invalid, just uncomfortable. Of course, there's such a thing as too much of a learning curve. Without Z, the game may be better, but without X & Y as well it may just never be played. And no, I'm not making any arguments about what KSP is intended as. I'm talking about use cases, not developer intentions. Further, I don't mean it's a tool you can have fun with, but rather a game that, by playing it (and doing what's necessary to play it) causes you to learn.

There's a qualitative psychological difference between going out of your way to install a modification of the base game vs. disabling a feature that ships with the base game. That's why we're having this discussion in the first place. Because "there's a mod for that" isn't an acceptable answer.

I'm going to take a stab at two arguments for not having a delta-V readout. Before I do, I will emphasize I am strongly in the camp of 'it should'. If I didn't have a delta-V readout (via mods), I would have stopped playing this game a long time ago. Nevertheless, these are arguments I find sympathetic, and I haven't seen them in this thread. Argument one: KSP is a game about lego-like construction and experimentation within that structure. One of the primary pleasurable skill-curves in this game is figuring out roughly what a rocket with various capabilities 'looks like' and figuring out how you can change that while still accomplishing your objective. With a delta-V readout, this aspect of the game and its experimentation is completely quashed. This is an aspect some people find enjoyable, whether or not you do. (I don't.) Argument two: KSP is a game about rocket science. In that sense, it's a vehicle to have a good time learning more about rocket science. KSP gives players a real incentive to learn about things like orbital mechanics, momentum, the Tsiolkovsky equation, the vis-viva equation, etc. Providing a delta-V readout gives players an 'easy out', meaning it will stunt that knowledge-growth endeavour, much like having maneuver nodes means I don't have to learn anything about orbital mechanics other than some gut-feeling basics, instead of understanding the mathematics behind a Hohmann transfer. Some people find learning in this way enjoyable, whether or not you do. (I do.) For both arguments, a common response is, "Then we'll make the delta-V readout optional, and you can turn it off." But this misses the point. Human nature and human weakness are such that, if there's an easy way out, people will often take it, even if they wish they wouldn't. So a delta-V readout would largely quash both methods of playing the game, even if optional.

OK, I think I understand the confusion. The reason you can't use Duna to get to Moho is simpler than you think. In a Kerbin-Duna transfer orbit your apoapsis is at Duna. At apoapsis you're moving slowly. For a gravity assist, you want to be moving fast. In fact, a rule of thumb is, the faster, the better. So you couldn't use Duna for your Moho transfer - at least not profitably. Aside, I think what the author means isn't that it's mathematically impossible, but rather that it's not worth the time and effort because your gains are either going to be miniscule or take an absurd amount of time to realize. However, again, I haven't actually run the numbers, so I don't know.

Either the thread is wrong, or you're reading it wrong. Venus is a very popular assist option on the way to Jupiter.

I haven't looked at the math, but if I were trying to slingshot to Jool, I'd use Eve or Kerbin instead of Duna. Why? Because Eve and Kerbin have higher gravity wells, and the setup costs are lower.

Thanks for the in-depth answer! As to the QA process, I can 100% back you up there. Even when you have a huge team of developers and QAers, the dev process for any enterprise-level product means bugs get through. There will always be critical bugs. Which is why I really appreciate your work here in this thread and these fixes. You're really going above and beyond. These may not be showstoppers, but players really appreciate the fixes regardless for quality-of-life. This goes double-especially because some of these simply wouldn't get fixed, due to larger concerns. It's a sad fact of life for any large product that some lower priority bugs exist in perpetuity, because other things are simply always more important. And, as I've said, that's what makes your work here so great.

This makes me curious about the release process of your stock bug fixes. To wit, you're Squad staff, but these aren't part of stock KSP. Why not? The most immediately obvious answer is that you're volunteering your time to fix bugs that slipped through the QA process, and (possibly) planning to include them in the next patch/version. But that doesn't have to be the case; there might be other answers. Please don't take this as an attack or a passive-aggressive "why didn't Squad do this better?" post. I understand that QA isn't perfect; I worked in QA for 3 years before quitting to pursue my PhD. I'm honestly curious how the relationship works out.

Can we also disable engine gimbal when those engines are disabled, throttled down, or out of fuel? It looks silly to have my rocket plane's butt wiggle all over the place.

I like the proposals to move it somewhere not-immediately-obvious but still close by. One other possibility is to just make it invisible from the KSC view, but keep it in the same place. Honestly, what we need regarding Easter Eggs is something tying them all together, for the player to figure out... On a completely unrelated note, I hear if you turn off the lights and face a mirror while saying "NovaSilisko" three times he jumps through the mirror and uninstalls KSP from your computer.

Posting here to remind me to do this when I get back to my real computer. My laptop can't handle this, but in around a month I may have something for ya'll...

I might take this up, though I won't be going for a 'win' or anything. I have grand visions of Mk3 parts. A couple questions about mods: what's your feeling on FAR? Also, Modular Fuel Tanks?

If your alcohol is a solution, you need to work on your distilling process. ...aaaand now we're really off-topic. Uh...another thing to check is to make sure Jeb hasn't drunk the rocket fuel?

Speak for yourself. Careful Living Through Chemistry!

So that's what that noise was. To actually add to the conversation, my biggest bugaboo is staging. I rarely take off without at least enough stuff on the craft to do the job. (e.g. I might not have all the solar panels or antennae I want, but I usually do, and I can't remember the last time I left the ground without at least enough). My problem is getting it all to go off at the right time. Usually this is fairly innocuous, because it's something like launch clamps before ignition Usually this is also fairly harmless, because I catch it on the launchpad. Sometimes this is hilarious, like the time my upper-stage decoupler and fairings went off at the same time as my booster-stage engines and I had to carefully wobble the thing to space.

I'm trying to figure out how to turn TWR through the flight of a stage into a function for programming purposes. Clearly TWR as a function of time must follow the form F(t, y) = Aert + Besy Note that I'm talking about a single stage; there are discontinuities upon staging. Also, I'm assuming instantaneous ignition and a fixed throttle. t is time, y is altitude, taking the launchpad as zero (for ease of calculation). The coefficient A is clearly an expression of the throttle, so let's set it aside. The B term is likewise a scalar relating to the Isp at sea level. The s term is fairly easy. It's a coefficient to altitude, intended to represent change in Isp with thinner atmosphere. But I'm still having some trouble with understanding how to use it; how does the atmosphere decay? It's clearly ln(something) depending on the celestial body, which means we could rewrite the second term as Bsy Similarly, the r term is related to the mass-flow rate of the engine(s), or, if you like, the mass-loss rate of the rocket. F is in Newtons. t is in seconds. y is in feet. This means r must be in Newtons/second and s must be in Newton-seconds. And at this point I'm lost. How do I go about giving specific values to my r and s terms? For example, let's say I have a rocket that at F(0,0) = 300kN. Therefore 300kN = A + B. Easy, but unhelpful. What else do I know about this rocket? I know the mass-flow rate. I know the specific impulse at sea level and in a vacuum. How do I derive the rest? For background (and because perhaps there's an easier way to do this), I'm trying to take a given, arbitrary rocket and calculate, to a rough approximation, a zero-lift ascent from Earth (or another celestial body, but let's skip that). Thanks to anyone who can help.

Everyone wants to name their pet projects Orion. This way, they can fly a drone up over it to fire a nerf gun and become Roy Batty.