bac9

Great idea!

Version 3.2 is up on kerbalspaceprogram.com. Contains new version of ExsurgentEngineering.dll, now compatible with ModuleManager. Thanks to careo & ialdabaoth for investigation and the fix!

CF34 won't give you any thrust beyond 300m/s, which makes them pretty unsuitable for SSTO. You generally never want to start rockets before going at least 1200m/s. Not to mention they aren't particularly efficient at air intake at high altitudes.

You have R3.1, not R3.1c and that message shows up because the part failed to load properly. It's a KSP placeholder description. Download the fixed version. Honestly, I don't understand how it's possible to install this thing wrong. You already have GameData folder in KSP root, you have GameData in the archive, just move all the content from one to another. These engines can't go faster than 300m/s and aren't really the best choice for SSTO.

Check example crafts and learn from them. That's pretty weird, BRV-4 Heinlein is extremely overpowered (five engines, large fuel reserve, little mass, no payload), so it can go into orbit using less than half of the fuel reserves and is forgiving to absolutely ridiculous mistakes. It's pretty hard to waste all the fuel on it and just get into orbit. Flying it is very simple, just climb fast to 10-15km then level out, kill most of your vertical speed and gain velocity as high as possible. Climb slowly from 15k, preferrably within 10 degrees over the horizon, so that you can push the plane to the fastest possible speed without losing air. As you go faster, you get more air intake, allowing yourself to climb even higher without flameouts, allowing yourself to speed up more due to lesser drag. When air intake gets into 15-10% area, cut the throttle of the engine to 75% and continue to climb, that will cut air intake requirements significantly and will delay the flameout further. Cut the throttle further just before the switch if you can sustain the vertical speed with it. Also, don't forget to watch your prograde vector on the navball and pitch upwards: at high altitudes, nothing ever flies horizontally oriented as there is too little air to hold you. If you want to fly horizontally, find an angle of attack that will keep you there, which will be noticeably higher than horizon. When I'm saying "climb within 10 degrees" , that's your prograde marker, not your spaceplane orientation, which could be 30 degrees up even. Ideally you should be going no slower than 1200-1500m/s and no lower than 25km at the point of switching to oxidizer. Return to full throttle upon switching to it, keep going almost horizontally while stabilizing yourself with RCS. It's best not to burn upwards, keep burning almost horizontally, maybe 20 degrees upwards if you insist on reducing little drag that is left at this point even faster. Getting extremely long trajectory to AP is better than getting up there with a steep trajectory as it will be a lot easier to circularize when you already have most of the orbital velocity needed. Ideally, you will only need a quite short push at AP to raise your PE over the surface and into low orbit.

Nope, nothing like that planned.

There is no sweet spot, the further behind the center of mass your center of lift is, the more stable and less prone to flipping your aircraft would be. You just won't be able to take off after a certain point if you have CoL too far in the back, that's all. Other reason for flipping would be thrust vectors or center of lift situated on a different axis than center of mass (e.g. if you are overly enthusiastic with offset wing positions), but that can be solved too, most of example crafts are vertically asymmetrical and are still flying well.

No, they should only work when intake air is present.

Very nice looking parts. I'd recommend to use more optimized texturing though, these parts could have been done with just one texture. Using up to nine per part is not good for performance and memory.

The plugin should revert the engines automatically. Are you completely sure you have plugins installed correctly? Is all other VTOL functionality, like rotation action groups on VX-1 example craft, working properly?

XeroXion, thanks, fixed. That's sleep deprivation for you, people. Version R3.1c is up, structural panel configs are fixed there: http://www./download/w2tl2cwxx60tr5n/B9_Aerospace_Pack_R3-1c.zip

It looks as intended, current aerobrake module is not supporting animation so piston part was removed as it can not be moved properly with simple rotation.

Version R3.1 released. Download: http://kerbalspaceprogram.com/0-20-2-b9-aerospace-pack-r3-1 (woah, editable urls on spaceport!) http://www./?uz3sx8631qebreu Changelog:

F119 engines aren't using stock gimbal module, hence the ability to move differently. I'll ask about the rotation bug.

No. For n-th time, find GameData and Ships folders that are already existing in your root KSP folder and overwrite them with Gamedata and Ships folders from the archive. I don't understand how it's possible to do something wrong there.

Various animation-related modules, in particular airspeed-dependent interpolation similar to stock heat that is used for variable geometry intakes. Created by Kine by our request. These are two different objects. S3 centerpiece is one.

Yes, change the name of thrust vectoring module to one used in F119 engine and configure it.

No, not anytime soon. Reading info popup on example VTOL that was included with the pack might help. Action groups. No, it will never be split into several mods since that would be a support and maintenance nightmare. Also, amount of parts has no relation to performance effect, amount of textures and meshes does, and it's quite low here. This mod won't push your memory usage higher by any significant margin. Pocket change in comparison with 400mb KW Rocketry. You will lose all SABRE features and all thrust vectoring functionality. Not recommended at all. None that I know of. Look at the animation of the doors and look where you have placed RCS tanks. You are ramming the doors right into them.

Why would you want to resize the textures when texture quality slider in the graphics options does the same thing by telling the game to use lower mip levels?

There are no duplicates or atlas textures in stock, nothing to share.

Yes, Winston will be able to slash KW Rocketry size at the very least twice with this method. You only have to add thrust vectors and rcs module, it has nothing to do with animation.

For n-th time, KSP is a 32-bit executable and whether you have 8 or 128 Gb RAM makes zero difference. It can't use more than 4gb. You also won't free much memory by getting rid of B9. Try removing KW Rocketry instead, which is five times bigger (400mb vs 73mb).

Just check the name of the archive.

You are using old version of the mod, download R3.0c from spaceport. )

That's why there are lots of example crafts with descriptions and whatnot. Load them, fly them, figure what works.