CaptainArbitrary

I didn't keep it. It's not really "code," though. You just type in the equations and tell Mathematica to plot them for you.

Your vehicle may be too heavy. Deceleration due to drag is inversely proportional to mass. I designed my Mk 1-2 pod vehicles to have a reentry mass of about 5 tons, of which nearly a ton burns off from ablation, so by the time it gets through the hot zone it's down to 4 tons of less (depending on consumables).

Kind of. If the boundary were continuous it would also be differentiable across, along the line connecting the radii. But even in that case, it would not be differentiable anywhere else. And it's not the fact that there's a discontinuity there that causes issues; there must necessarily be discontinuities in a patched-conic approximation. It's the magnitude of the discontinuity that causes the problem. You're moving from a region where your trajectory goes thisaway smoothly and sensibly to a region where your trajectory suddenly makes a 90° turn, or flips back on itself, or whatever. Too lazy for that. I just kicked 'em out in Mathematica right quick.

After spending thirty seconds on it, I can't think of a quick way to, no. See, the plots I gave you are mathematical. The first plot is just an illustration of the gravitational acceleration field emerging from two fixed sources: The second one is a piecewise function where the acceleration is a function of one body when close to that body, the other when close to that body, and everywhere else a function of your imaginary barycenter body: In the second case, outside the SOIs of the two bodies (defined by radii r₠and r₂) the gravitational acceleration field is created by a single source with the mass of both bodies that lies at the center of mass of the pair. That's what you described, and the plots I posted show the results. This would work perfectly from outside the immediate vicinity of the system. That's Gauss's law, in essence; the gravitational field created by a distribution of mass looks, from a distance, like the field created by a single point of the same total mass. That's why when we do two-body gravity math we can ignore the fact that the bodies have extent; we can pretend they're just points. But what you're trying to do is model the region between the two bodies in a way that's simple and that can be reduced to polynomials of time ("put on rails," in KSP jargon) but that comes close enough to reality to make it worth doing. You're not going to get there with this approach. The idea of using a piecewise function is fine in principle; that's essentially what KSP already does, with patched conics. But in the patched-conic approximation, you get away with it because the boundaries between regions are relatively smooth. They're discontinuous, yes, which is why you can't differentiate across them. But they're smoothish, because you choose to put your SOI boundaries out in fairly flat space, away from steep gradients. Like so: The flat blue area is flat space, where the acceleration scalar is exactly zero everywhere. Within predefined radii, the acceleration scalar is like normal, going like 1/r². See how there are discontinuities at the boundaries, but they're relatively smooth ones? Crossing a boundary from flat space, the acceleration scalar goes from exactly zero to something with no transition, but the something it goes to is very close to zero. So it's okay; we can work with it without too many problems. It becomes a decent approximation of how things would happen in real life, where there are no discontinuities. But in your model, the discontinuities in the region between the bodies are enormous; the acceleration scalar jumps wildly from one value to another very different value as you move from SOI to SOI. This would create some very weird behaviors, as your orbits make sudden right turns, or even go degenerate and hyperbolic, when you cross an SOI boundary. It really doesn't matter how you implement your idea, I'm afraid. It really just can't work. You're trying to break Gauss's law, basically, by treating a non-symmetric distribution of mass as a single point from within that distribution of mass. That can never work. It can't even be close enough. Sorry.

This is what you're trying to get: This is what you're actually getting: The big problem is that your piecewise function breaks off the axis. Along most of the line connecting the centers of the two gravitating bodies, your piecewise function is okay â€â€*except for a single point where it goes to minus infinity. But just off that line connecting the centers, your piecewise function gives completely bonkers results, compared to real life. I honestly think this would be worse than the status quo. Even if the developers wrote a lot of conditionals to get around the singularity at the center, there are still those discontinuities where the laws of physics would go cuckoo for Cocoa Puffs, resulting in really weird, unphysical orbits that would leave you staring slack-jawed at the map view.

That's the best news I've heard all week. Admittedly, it's been a lousy week so far, but still! Great news!

Any chance you'd consider posting the change you made to FAR, so those of us who are comfortable compiling from source can apply it and try it out? (Haven't even looked at the FAR license terms, so if that's not okay with Ferram, I'll just hush.)

Likewise. I've given up on  not permanently, but in the sense of "KSP, we need to take a break"  this game twice already, once after .16 came out and changed everything, and then again after .18 came out and changed everything. I'd put a lot of work into getting things set up just so, and the updates changed things, and I got frustrated. So I stepped away. I haven't decided whether I'm going to dive right in to .21 or not, whenever it drops. From what I've read, it sounds pretty incremental. There's nothing in it I'm dying for right now. The new ASAS  particular its mod-ability â€â€*sounds really great, but I can't remember the last time I even attached an ASAS part. I've gotten so used to playing with out, and without pod torque. I use MechJeb or ORDA for attitude control and RCS exclusively for attitude control. So while it sounds great, I'm not gagging for it right now. But if the past repeats itself, there's gonna end up being some damn thing in .21 that makes it impossible for me not to play the new version. Some minor feature or API change or part that nobody even bothered to talk about will seduce me and I'll download the new version and nothing will work and all my custom addons and parts will have to be changed and … blar. I wouldn't hate it if the pace of KSP development slowed down a … lot.

The side.cfg config file has parameters for ejectionDv and ejectionNoseDv, which I assume without actually looking at the source code are in meters per second. Maybe play with those values, see what results?

On that note, I'd love to see procedural interstages. The Squad engines have their built-in interstages, of course, but I don't know of any third-party engines that have them. Not even the KW ones. So to satisfy my completely bonkers OCD tendencies, I either have to use those hollow interstage decouplers that were all the rage back in the day, or use only Squad models for upper-stage engines. It's kind of hard to imagine how a procedural one would work, exactly. The most naive idea would be to put a thin ring-shaped part on top of the lower stage that would act like a stack separator, then put another similar part between the upper-stage engine and the tank above it, then have the surface part or whatever construct an interstage between the two parts. If the two parts have the same diameter, you get a cylinder. If not, you get a frustum. But working out the details of that strikes me as very tricky. It'd be a fantastic addition to the game, for me, but it sounds like a lot to ask.

A very quick-and-dirty test with FAR suggests that they don't work, and I'm not sure why. Here's the snippet of FAR source code that tries to identify fairings: else if (title.Contains("fairing") || title.Contains("payload") || title.Contains("shroud")) { if (!p.Modules.Contains("FARPayloadFairingModule")) { p.AddModule("FARPayloadFairingModule"); p.Modules["FARPayloadFairingModule"].OnStart(PartModule.StartState.Editor); FARAeroUtil.AddBasicDragModule(p); p.Modules["FARBasicDragModel"].OnStart(PartModule.StartState.Editor); returnValue = true; } } And here's the part of FARPayloadFairingModule that computes the geometry of fairings and shields the parts under them: private void CalculateFairingBounds() { foreach (Transform t in part.FindModelComponents<Transform>()) { MeshFilter mf = t.GetComponent<MeshFilter>(); if (mf == null) continue; Mesh m = mf.mesh; if (m == null) continue; foreach (Vector3 vertex in m.vertices) { Vector3 v = t.localToWorldMatrix.MultiplyPoint(vertex) - t.position; v = part.transform.worldToLocalMatrix.MultiplyVector(v); maxBounds.x = Mathf.Max(maxBounds.x, v.x); minBounds.x = Mathf.Min(minBounds.x, v.x); maxBounds.y = Mathf.Max(maxBounds.y, v.y); minBounds.y = Mathf.Min(minBounds.y, v.y); maxBounds.z = Mathf.Max(maxBounds.z, v.z); minBounds.z = Mathf.Min(minBounds.z, v.z); } } minBounds.x *= 1.05f; maxBounds.x *= 1.05f; minBounds.z *= 1.05f; maxBounds.z *= 1.05f; } private void FindShieldedParts() { foreach (Part p in FARShieldedParts) { FARBaseAerodynamics b = null; b = p.GetComponent<FARBaseAerodynamics>(); if (b == null) continue; b.isShielded = false; } FARShieldedParts.Clear(); foreach (Part p in VesselPartList) { if (FARShieldedParts.Contains(p) || p == null || p == part) continue; FARBaseAerodynamics b = null; b = p.GetComponent<FARBaseAerodynamics>(); if (b == null) continue; if (p.GetComponent<FARPayloadFairingModule>() != null) continue; Vector3 relPos = p.transform.position - this.part.transform.position; relPos = this.part.transform.worldToLocalMatrix.MultiplyVector(relPos); if (relPos.x < maxBounds.x && relPos.y < maxBounds.y && relPos.z < maxBounds.z && relPos.x > minBounds.x && relPos.y > minBounds.y && relPos.z > minBounds.z) { FARShieldedParts.Add(p); if ( { b.isShielded = true; //print("Shielded: " + p.partInfo.title); } foreach (Part q in p.symmetryCounterparts) { if (q == null) continue; FARShieldedParts.Add(q); b = q.GetComponent<FARBaseAerodynamics>(); if ( { b.isShielded = true; //print("Shielded: " + p.partInfo.title); } } } } partsShielded = FARShieldedParts.Count; } } } Exploring exactly why it isn't working is beyond what I'm up for tonight, I'm afraid, but maybe something there jumps out at you?

I just wanted to say that this version of MechJeb2.dll has completely changed the game for me. I used to fear MechJeb, because the attitude control aspects of it were so violent and unpredictable. It would tear fragile vehicles apart, drink monopropellants like it was going out of style, and completely fail to pay any attention to the roll axis during ascent maneuvers, making the main engine gimbal wildly in both pitch and yaw and waste precious ÃŽâ€v on steering. Now MechJeb controls attitude like it was meant to. My only two wishes are that (1) RCS auto could be a persistent setting, and (2) it could be assignable to custom windows the way "use SAS if available" is.

Huhblahmalah. Muhmamaluh. Gah! Downloading. Right now.

Have you considered FAR? I won't play without it any more, for just that very reason.

Ah, that's a very valid point. The total ÃŽâ€v of the rocket doesn't depend on thrust, but how much of that ÃŽâ€v gets eaten by the Gravity Monster does. Thanks for pointing that out. Too kind. I'm glad you like it. Again, thanks very much. I really appreciate the kind words, especially after the day I've had. It would in principle, I guess. In practice … I'm not sure exactly how that would work. The first problem with that approach that comes to mind is the GetInfo() issue. GetInfo() is the method called on PartModules to generate the VAB GUI. You know, the little window-like things that pop up when you mouse-over a part in the part catalog section, that tell you Isp and thrust and whatnot. If I'm correct  and I'm pretty sure I am, as I've done some fruitless screwing around with this  GetInfo() is only called once, at load time when the game database is being compiled. After that, the game just reports the data it already collected. So it can't be changed dynamically. If I'm correct about that. Of course, it should still be possible to change the maxThrust parameter on a ModuleEngines-by-ModuleEngines basis dynamically, with as you say a button or something. If MechJeb, Engineer et al. work by dynamically polling the engines attached to the vessel and getting their maxThrusts, that would work … but only if that's true. I don't know that it is. I did experiment with having my addon run in the VAB as well as in flight, but I bailed on it when I found that my addon wasn't getting FixedUpdate() calls from Unity while in the VAB. I don't know if that's because I did everything right and that just doesn't happen or if it's because I screwed something up, but I stopped messing with it after just a few minutes of work. Then there's having to add a GUI of some kind to the thing, and there's not a whole lot in the world I hate more than GUI programming. So yeah … whine whine whine, the short answer is that sounds like it could be made to work, but I'd have to really force myself to do it. Not saying no, just … bleh. Freely given. If you wanna write a GUI and make the thing work in the VAB, I know at least a few people will be very happy. I don't know if I've mentioned lately, by the way, just how dependent I've become on Modular Fuel System. It's completely changed the way I play the game. Even my capsules use the mod, so I can configure their consumables (hydrazine, Oâ‚‚ and the like) in the VAB. Thanks so much for it.

Whereas in the real world it's exactly 299,792,456 meters per second by definition, AND THAT MATTERS OBVIOUSLY. ;-)

So here's an amusing little quirk. "Magic pod steering torque" has always bothered me, so I sometimes play without it, by setting rotPower = 0 in a pod's part.cfg. Doing so causes MechJeb to go crazy in an interesting variety of ways. The most consistent one seems to be that the ascent autopilot simply does nothing at launch. It gives no control input whatsoever. If I set rotPower = 0.001, MechJeb works normally. But that amount of steering torque is so small that it's effectively zero, so that's my workaround for the time being.

Oh my god, these are so sexy. I skimmed the kinda-release-notes for .20 and saw the thing about the MODEL node, but I really didn't get it until now. Thank you so much.

So it seems like the version-check and RemoteTech checkboxes only show up if your vessel has a crew capacity on it. If you've only got unmanned pods, you don't get those settings options. Is that on purpose?

The unnamed "fuel unit" of volume is exactly equal to five liters. That's how the stock configs are set up. There's nothing saying your parts can't contain a couple liters of propellant and a hell of a lot of empty space, but that raises questions about moments of inertia and all that whatnot that are easier left unasked. Dude, I totally know where you're coming from. I had to fight the same fight. ModuleEngines actually handles it all automatically, using thrust and Isp. F = dm Isp g0, so it computes the mass flow from the rated thrust and the specific impulse at the current ambient static pressure. (Wrongly, it turns out, but I've got a plugin up that fixes this for people who are bothered by it.) Then it does all the arithmetic to handle propellant flow in a fairly simple way. The density of the fuel mixture is just Σ Ã f where f is the propellant fraction defined in the ModuleEngines config. So if reactant #1 has a density of 5 metric tons per liter and reactant #2 has a density of 13 metric tons per liter and their ratio is set up in ModuleEngines as 0.60 and 0.40 respectively, then ÃÂm = 0.60×5 + 0.40×13 = 8.2 metric tons per liter. Then it takes dm from the thrust equation (mass per time, so metric tons per second), multiplies by the length in seconds of the current frame (giving us mass), then divides that by ÃÂm (mass per volume, so metric tons per liter) to get the total volume of reactants required for that frame. Then it just multiplies that volume by each reactant ratio in turn to get the volume of each reactant to consume. The arithmetic is tedious to get right the first time, yeah, but once you get it right, you never have to worry about it again, because everything that can change  resources, mixture ratios, reactant densities  are all set in config files, and the math is the same as long as you don't go changing units on people. ;-) Yeah, I don't think that's exposed through an API directly. But it should be trivially easy to get it from GameDatabase through something like this: foreach (ConfigNode node in GameDatabase.Instance.GetConfigNodes ("RESOURCE_DEFINITION")) { if (node.hasValue("density")) // do things } It is … which is the problem. For Mr. Wannalauncharocket, it doesn't matter at all, but for everybody who has to open a .cfg file, not having an agreed-upon set of units of measure has made life way harder than it needs to be. Ah, that's the tricky bit. Specific impulse is related to what kind of propellant you use, but it's also related to the geometry of your rocket nozzle. Remember that F = ve dm + (Pe – Pa) Ae, and Isp = F / dm g0. In order to make a good choice about what specific impulse to give an engine, you've gotta take into account the diameter of the nozzle and the exhaust pressure. The diameter of the nozzle is a constant; it's part of the 3D model, obviously. And you can make a sensible choice about exhaust pressure by asking yourself what altitude this motor was meant for. For an SRB, an exhaust pressure of half an atmosphere is sensible, because they're meant to burn during ascent. So in vacuum you're looking at a pressure thrust component of half an atmosphere applied across the area of your nozzle exit; that adds to the thrust you get from the momentum of your exhaust. At sea level, you're looking at a pressure thrust component of minus half an atmosphere across your nozzle exist; that subtracts from your momentum thrust. That's why motors have different specific impulses at sea level and in vacuum in the first place. Point of all that is simply to remind you to remember that specific impulse is a function both of propellant and of engine nozzle geometry … and also that rocket science is fun. :-)

True, but the way the resource system works right now kinda makes it a pain not to adopt some kind of volumetric convention. Densities are defined in metric tons per whatever  and the metric tons part is set in stone. It's hard-coded into the game that if you define a resource as having a density of "1" then an amount of "1" of that resource will mass one metric ton. You can have different resources denominated in different volumetric units if you want to; there's nothing stopping you from unilaterally doing something like this: RESOURCE_DEFINITION { name = Helium density = 166.0 // grams per cubic meter at 1 atm and 20°C flowMode = STACK_PRIORITY_SEARCH transfer = PUMP } RESOURCE_DEFINITION { name = Nitrogen density = 0.23291 // kilograms per liter at 2000 psia and 20°C flowMode = STACK_PRIORITY_SEARCH transfer = PUMP } RESOURCE_DEFINITION { name = Water density = 1.0 // pounds per pint flowMode = STACK_PRIORITY_SEARCH transfer = PUMP } But it makes life a living hell for anybody who's trying to figure out how to assign resources to parts. When you add in something like Modular Fuels, you have to convert all your densities to the same units  whatever those units be  because the whole point of that plugin is to divided volumes up to hold resources. So no, it's not set in stone. But the fact that it's not set in stone is the third-worst thing about this game right now. (The other two being, in my opinion, the complete lack of sanity to how electricity currently works and the baffling ordeal that is heat production. Both make life way harder for people who want to mod their game than it really should be.) But just to reiterate: Yes, I absolutely think this is a very cool idea. I'm just throwing some unsolicited feedback at you in the hope that whatever decisions you make about your mod in the early days are the best ones, so you don't have to go back and make big, sweeping changes to it later. (The density of APCP, by the way, is 0.00195 metric tons per liter. You know, just in case you decide you want that information.)

I really, really like this idea of this addon. Unfortunately, I can't seem to make heads or tail of it. It includes a part (AmpYearPart) which is just a subclass of AdvSASModule, and it doesn't actually seem to do anything. The PartModule, AmpYearModule, seems to contain the guts of the thing, but when I put it on a probe core it not only failed to work itself, but somehow took out RemoteTech at the same time, and filled my log with these errors: LOG 05:22:21.024] dT is NaN! tA: NaN, E: 3.14159265358979, M: -8.40714670366795, T: NaN [LOG 05:22:21.024] dT is NaN! tA: NaN, E: 3.14159265358979, M: -8.40714670366795, T: NaN [LOG 05:22:21.024] getObtAtUT result is NaN! UT: NaN [LOG 05:22:21.024] getObtAtUT result is NaN! UT: NaN [LOG 05:22:21.024] getObtAtUT result is NaN! UT: NaN [LOG 05:22:21.024] problem! But I can't figure out where those errors are coming from, because none of that stuff is even in the AmpYear source code. While the idea of this addon is super-rad, I despise the idea of having to bolt on a dedicated part just for it … and I don't use ASAS on my ships, so having that part subclass AdvSASModule makes things even less appealing. If it were just a PartModule I could put on any part, that would be different, but as it is, I can't see the virtue in making this addon work for me. Really fantastic idea, though. I just wish the implementation were different, is all.

So … wait. One liter of your rocket propellant masses 200 kilograms? That's nearly twenty times denser than lead! Does each of your booster segments contain a piece of the core of a sun? Don't get me wrong. It's a super-rad idea. That just stuck out at me, is all.

The ÃŽâ€v numbers are correct; ÃŽâ€v doesn't depend on thrust at all, but comes straight from Isp and your mass ratio via Tsiolkovsky's equation. Only the TWR number is wrong, because those plugins expect (quite reasonably) that the game is still making engines develop way too much thrust in atmosphere. It is. That's discussed in the top post, I think. It's bound to the abort action group by default; you can remove it from that group in the VAB if you want to. Also, remember that the included Module Manager config file only puts a range-safety device on the stock probe cores. If your rocket only has a manned capsule on it, you won't get a range-safety device by default at all.

Fair question, but I doubt it. Engines cannot, in the game, have different max thrusts at sea level and in vacuum. They have specific impulse curves, but no thrust curve; the rated thrust is just a number that isn't a function of anything. I imagine MechJeb and Engineer compute TWR by taking the rated thrust from the engine(s) in each stage and dividing it by the mass of that stage and all the stages above. I guess I could try changing the plugin such that it runs in the editor and downrates the engine to its maximum sea-level thrust, so other plugins can get the right number out. But off the top of my head, I'm not sure what implications that'd have for save files and stuff. So while I might look at it in a little while, I can't promise I'll actually end up doing anything about it.