New Engine Variants Causing Massive Increases in Drag

[IronMaiden]

Terrier Comparison

At subsonic speeds the "bare" variant (far right) has drag penalty vs old (mid right), "shroud" variant (mid left) and "truss" variant (far left). All the new variants do not completely occlude the 1.25m parent part, so the fuel tanks have additional drag. In the bare variant this can be overcome by node duplication and attaching a part that does completely occlude the tank (e.g. nose cone), but this does not help the truss or shroud variants. It really sucks losing a true 1.25m engine, I don't understand the purpose of the different variants. They look great but that should come second to gameplay. Intuitively, a 1.25m part should completely occlude the flat portion its attached to and why would we use the bare variant when the drag is so high?

Edited February 8, 2019 by IronMaiden

[OHara]

You can still find the old Terrier using the 'Advanced Search' and/or see other workarounds in this thread

 

[IronMaiden]

Ah cool, thanks for the tips!

[The Aziz]

You don't use the terrier that low in the atmo, do you? It's purely vacuum engine, for me it's under a shroud until I'm way too high to worry about drag it causes.

[OHara]

12 hours ago, The Aziz said:

it's under a shroud

Please post a craft file.  Shrouds don't help in my craft.

[IronMaiden]

13 hours ago, The Aziz said:

You don't use the terrier that low in the atmo, do you? It's purely vacuum engine, for me it's under a shroud until I'm way too high to worry about drag it causes.

Shrouds don't prevent drag on the part inside. AFAIK they do act to occlude the entire flat surface of their equally sized child part, but that's not the problem here. The drag caused by the new variants is applied to the engine itself and the parent part. It is a vacuum optimized engine, however, once you get above 12km it has a very respectable Isp and by 20km it's practically at peak efficiency. I enjoy using them in ultra-low tech SSTOs in the early game and the new variants make this virtually impossible due to the massive increase in drag. Unless you have the new terrier in a fairing or service bay you're losing significant thrust overcoming the new drag, the old terrier model (and I suspect poodle, aside from the newfound roll authority, and spark as well) is superior in every way, which is pretty disappointing 

Edited February 9, 2019 by IronMaiden

[DMagic]

While looking at this same issue for some other parts I came to the conclusion that using the part variants to generate drag cubes doesn't make as much sense for vacuum engines like these.

You can either have drag cubes based on the different variant sizes, or have drag cubes based on the shrouded vs unshrouded version of the engine, but not both.

For vacuum engines it almost always makes more sense to use drag cubes based on the engine shroud. That way, when the engine is in the middle of a stack its drag cube makes sense and matches that of similarly sized engines and other parts.

When using drag cubes based on the part variants you get penalized for using anything except the biggest variant.

When the engine is used in the middle of a stack and its shroud is turned on, then it behaves as you would expect it to. Turning off the shroud would cause a interruption in the drag, as you would expect. And when the engine is placed on the end of a stack then it should still, in most cases, work out okay.

You can do this by setting "useMultipleDragCubes" false in ModulePartVariants and set it to true in ModuleJettison (you can't set them both to true, if you do it just reverts to using procedural drag cubes and the result is more less the same as setting it true in only ModulePartVaraints). There is also some benefit to manually adjusting the drag cube from there, but that would be different for each engine.

[OHara]

2 hours ago, DMagic said:

For vacuum engines it almost always makes more sense to use drag cubes based on the engine shroud. [...]
You can do this by [...]

That is the resolution suggested in the bug-report 20683 (which is still awaiting confirmation by some other user) but I didn't see a way to implement it as a Module Manager patch.  I'll steal your idea and if it works as expected put it on the tracker as an improved workaround.

Edit: Having drag configurations that depend only on whether the shroud is present works great for the engines in the base game.
But, several Making-History engines have different mount- and shroud-sizes depending on the variant.  (The Cheetah can have either a 1.25-meter or 1.875-meter shroud.)  I'll leave the more complicated Module-Manager patch on the bug-tracker because that hack resolves the problem in Foxster's thread as well.

Edited February 10, 2019 by OHara

[DMagic]

8 minutes ago, OHara said:

but I didn't see a way to implement it as a Module Manager patch.

You just have to tell KSP which module is going to be varying the drag, otherwise it will just get confused about which drag cubes to use. Anything that implements IMultipleDragCube (ModuleJettison, or ModulePartVariant) can do that. But only one can be active. So you have to set useMultipleDragCubes to false for any module that you don't want controlling it, as it seems to always be set to true by default.