NathanKell

Nope, transition from white to orange is purely mach-based. llanthas: that may keep your rocket controllable, but sadly it's horribly inefficient. Unless you're seeing temp gauges, you're losing more to gravity than you gain through lowered drag. Even then the reason to slow down is so you don't blow up, not because you're being inefficient.

Whoops, confusing Unity (which enforces power-of-two) and DDS (which is div-by-4, quite right). However, the stock DDS loader only supports DXT1/5, it doesn't support uncompressed, and it doesn't support keeping the images readable (i.e. for use by GUI).

Nope, it's not. Don't worry, I'll update the release thread (and it'll be on CKAN) when it is.

The ratio of propellant burn in airbreathing vs propellant burnt by rockets went up, but so did payload fraction (since you can airbreathe to a much higher velocity now, and/or use fewer engines).

SolverEngines derives from ModuleEnginesFX; it would be rather hard to make it work with non-ModuleEnginesFX effects. Sounds like you're doing some awesome stuff! In fact, I suggest you just fork RealFuels and go from there, since that's what RF's solver aspires to do (actually calculate real liquid and solid engine performance, rather than use curves); we just haven't written that yet. And interesting you mention ullage; I just added that to RF. Check the repo. (Sorry we duplicated effort, since it sounds like we did the same thing). Excellent point about GetInfo, I'll fix that.

Are you using the latest MechJeb dev version? If not, try that. If so...sarbiannnnn! :]

I can add that to ModuleRCSFX, thus saving you headache m4v. (and toadicus can add it to TweakableEverything for the stock-RCS-module users). Consider this closed, assuming RCS Build Aid does check if the RCS is enabled before gettings its thrust transforms/thrust.

The reason is "Chris wants to take advantage of career unlocks", IIRC. It's perfectly _possible_ to spawn that window via right-click (though it is a bit of coding).

Red: Actually, stock does account for stalling, it's just pretty minor. What stock doesn't account for is wing sweep and aspect ratio. That said, prior to nuFAR, even FAR didn't account for clipping; regex (and I do too, actually) find 1.0.4's aero to be rather like FAR-on-.90 in terms of "feel"*, minus wing aspect/sweep accounting. *when used within expected parameters, i.e. flying a craft the way it looks like it should fly. Also, I should point out I'm a proud user of FAR since .20 and will always be so.

Beluwel, welcome to the forums! I think you intended to post that in the main Addon Dev forum; this thread is for asking about plugin development questions.

Define "not moddable"

1. The Mk1-2 pod is 2.5m in diameter. 2. The Apollo pod was 3.9m in diameter (not 3.05, that's 10 feet and the diameter of the Atlas and Titan boosters, not any pods--Mercury was 1.9m in diameter and Gemini's service module ended at 3.05m but the pod itself was only about 2.3m in diameter). 3. I have not noticed the IVA being that out of scale for a 2.5m pod, considering how near the nose everyone sits.

Where "deliberately suicidal" == "entering nose first" probably Fly it like a real spaceplane, i.e. high AoA.

DDS has a hard requirement: both x and y must be a power of two. Flags are not that size. So no DDS.

I recall bac9 mentioning this at some point; apparently the buildings were scaled (uniformly, so everything including doors scaled) after creation, rather than being recreated at the new desired size.

RuBisCO: I said persistent. Those aren't persistent. They get updated just fine.

Four things here: 1. If your orbit has no or almost no eccentricity, Ap and Pe will jitter around the circle. 2. If your orbit has no or almost no inclination, ascending/descending nodes will jitter. 3. Float imprecision: Orbital math is doubles, but Unity physics is floats. Floats aren't very precise, so just going from frame to frame when not in warp may be enough to subtly change orbit as the rounding changes 4. CoM/rotation issues as described above, although 1.0.3 switched to calculating vessel CoM correct rather than via the root. Note that 1 and 2 apply always; 3 and 4 only apply when not in warp (i..e off rails).

Correct.

Yes, that is a safe assumption, I'd say.

A part that changes persistent settings (for example, change in resource amount, or parachute opening height) will not be changed in existing saves and .craft files. For the chutes, just change the opening height to whatever you want in your craft file (new default for non-drogues is 1000m not 500m). For the Mk1 tank, either text-edit the .craft file, or remove and readd the part in the editor.

If you don't have a heatshield, >3km/sec is not terribly survivable.

Well, I'd wait until PP is actually released for 1.0.4 before reporting 1.0.4 bugs then

Glorious Dear Leader: you _are_ using the current versions of PP and FAR, yes? On what version of KSP?

Playing with CoPOffset should fix reentry stability.

Some pods do have built-in RCS. Perhaps the specific question is "could there be a way to exclude certain ModuleRCS-containing parts from the build aid's calculation of RCS torque"