The Lone Wolfling

Hmm... It should be possible to add a fake moduleengines to the nozzle and remove it on flight start.

Agreed. Currently it's far too easy to accidentally destroy a plane by staging.

See here. It seems to have been fixed on his end. That being said, I haven't had time to check yet.

Oh. I was under the impression that something like that would reduce the dimensionality of the design space, not just the feasible chunk of the design space. In this case reducing the problem from 8 dimensions to 4. (time + magnitude of burn in axises for both initial and flyby burns to just initial burn). If it's just adding constraints to the design space then of course it's going to be difficult to get a result.

Can you? I'd just use dropbox myself. Or, considering craft files are plain text, use pastebin.

...sometimes? I'll give two examples: I hit import from SFS on a vessel in orbit around Kerbin. It sets departure body to Kerbin. I hit import from SFS on a vessel in orbit around the Sun. It sets departure body to the vessel itself. Drat. Also, that's odd. I would have thought that restricting the solution space would improve the solver. Powered flybys are good, but mean that you have to be in control of the spacecraft while whipping relatively close to a planet. With RemoteTech, that's non-trivial.

Possible? Yes. Easy? Not really. I'll take a stab at it.

Can you post the actual craft file? Also, sorry about lack of updates. I'm working on awsomeness but I'm running into issues with vector math.

RCS in real life is used to desaturate reaction wheels / CMGs. In KSP, gyro saturation isn't modeled, so they aren't as needed. That being said, RCS is invaluable for docking.

Try procedural wings, procedural fairings, and b9. Between the three you are pretty much set. (If I were to install one - b9. 2 - pfairings + b9.) As for loss of control, make sure you aren't stalling. I agree that it would be nice to have a mod that only removed the infiniglide glitches without changing aerodynamics otherwise though. If nothing else, it would make some challenges a lot easier to judge. (For example: I've been wanting to do a glider challenge - mod the craft file to change launch clamps to 1km high, how far can you get, but with stock it's "trivial" to just keep going forever.) And something vaguely related. Is it just me who is bugged by the fact that the internal gyros of command pods / SAS units seemingly have no saturation point? Real CMGs cannot simply keep trying to rotate a vessel in one direction forever.

Exactly. I wish that people wouldn't remove features from things. Adding the 3d map is all well and good (well, except for increased system resource use), but I don't see why the 2d map was removed. Hidden unless you right click on the detector and show it is one thing, but simply removed is frustrating. There are (many) times where I want to see an overview of the map while being able to look at other things.

Hmm... Could you add a way to import the departure / arrival body from a vessel (from sfs)? Also, a suggestion for an alternative porkchop plot mode - have the y axis be days after departure not the absolute time. (Effectively tilts the graph 45 degrees, assuming a square grid). And perhaps an option to only allow flybys that don't have any burn? And perhaps aerobraking on flybys? Or an aerobraking calculator in general? Finally, a way to import / export a specific transfer.

If I do that, is there a 2d map available as an alternative?

Did you add it to a resource cfg file?

Generally CPU bound. Not always, though.

Agreed. I'm actually running a custom version that removes it entirely. Perhaps an option in the DR config to set a G-force scaling factor? Also, ripping joints apart instead seems like a good idea. We have fighters that can take more than that - the limitation is the human not the machine. What about an intermediate level where controls lock? Say 9-16G? Also, what's the license of DR?

Agreed. The overlay is useful sometimes, but not all the time. (Take a look at ISA MapSat. If the "overlay" (planet surface) was good enough, ISA MapSat wouldn't exist.)

Example craft?

See below.

On some mods (EPL, MMM, etc.), KSPMM freezes on "scanning virtual KSP folder".

I know exactly what's going on. The way that the SABRE engine works is that it swaps moduleengines on-the-fly. Thrust corrector currently assumes the the moduleengines in a part doesn't change. The way the thrust corrector works is that on flight start it records the true maximum thrust of the engine into a variable, and then adjusts the maximum thrust every frame to get the mass flow right. As such, what happens is that on flight start, it records the maximum thrust in a vacuum of the moduleengines in the SABRE. Then, when you switch to the rocket, the engine is switched, but the thrust corrector doesn't know that and keeps changing the maximum thrust based on the original maximum thrust (of the other engine module) It should be relatively simple to check if the Isp curve has changed, and if so recalculate everything. It's not perfect (it would fail if both engines have the same Isp curve but different maximum thrusts), but it should work for the SABRE at least.

AHA! Found the error. In ModuleManager_Squad.cfg, in the launchClamp1 section, it should be "CarbonDioxide, not "CarbinDioxide". Also, it doesn't add O2 and CO2 to the launch clamp, it makes the generator in the launch clamp also produce O2 and scrub CO2.

That it would help to prevent issues if it automatically updated the departure body with the orbited body of the selected vessel. (Import vessel, do burn. Whoops, the departure body was still set at Duna instead of Kerbin. F9.)

Does it also pull the orbited body?

Yeah, that's about what I imagine what's happening. Hence the "additional mass required for switching modes in-flight" thing. Hmm... Too bad Kethane-based resources cannot be distributed by latitude. 225.7 seconds... Hmm... ~3km/s delta-v required... That's a mass ratio of under 4, which is actually doable. What about using gas giant atmosphere as propellant? That's mainly hydrogen and helium, is it not? As a first approximation just set utilization in the MFS config to a relatively low value. Beyond that, something that started inducing random control jitter? What about running the water through an electrolytic cracker before entering the rocket?