Manul

I found what's wrong. Setting LegacyArmor to true summons the Curse Of The Wooden Leg and everything becomes wooden (while the craft save files say that it's aluminum). But flags aren't the victim of the wooden curse since their MaxTemp is -1K not 700

MAS already has some instruments to work with kOS. There is a MAS-powered kOS monitor aboard Buffalo 2 you can give it a try and see what it is capable of.

Mating Buffalo with Bison in the most unnatural way to make an airship bridge.

Finally got all Unity stuff working on my new PC so it's time to go back to the drawing board. I love the new Touchscreen MFD This is the result of my attempts to make a Science page. Can't make it respect situation restrictions for running experiments. Both fc.RunExperiment() and fc.RunAvailableExperiment() allow me to run seismic scan in flight or magnetometer report landed. Is it a bug or I have something important missing?

But it was fixed so AI pilots can fly SSTOs now (at least in lower atmosphere). I wonder what would happen if I put a wingman into the spaceplane and order him to follow me on the ascent into space.

Not for targeting because it depends on actual heat generation of the engine. But pilot AI can count Wet mode as afterburner and try to use it in the atmosphere loosing thrust on takeoff and crashing.

The BDArmory AI counts Wet mode as afterburner I guess Engaging a low thrust atmosphere-inefficient mode on a carrier takeoff might be confusing. I wouldn't call it "incompatible" but some ai controlled vessels might meet a horrible fate. But there is no dedicated aerospace fighter AI anyways so we can assume that BDArmory is incompatible with SSTOs in general (or SSTOs are incompatible with active combat at the edge of space because air to air combat at mach 6+ is physically impossible)

Is there a method that enables the RadarWarningReceiver and can be called from external code? I looked through this https://github.com/BrettRyland/BDArmory/blob/master/BDArmory/Radar/RadarWarningReceiver.cs but didn't find the answer. Using RadarWarningReceiver.EnableRWR() doesn't do anytning. I managed to turn the radar on and off by calling the method ModuleRadar.EnableRadar with MAS custom actions but it didn't work with RWR. The green stuff works just fine, when I hit MAS switch the radar window pops up. The red stuff doesn't have any effect.

See this https://github.com/BrettRyland/BDArmory/blob/master/BDArmory/Radar/RadarWarningReceiver.cs But there is no answer how to enable the RWR. Using RadarWarningReceiver.EnableRWR() doesn't do anytning. I managed to turn the radar on and off by calling the method ModuleRadar.EnableRadar with MAS custom actions but it didn't work with RWR. The green stuff works just fine, when I hit MAS switch the radar window pops up. The red stuff doesn't have any effect.

Yes. Having the same problem. But the engine doesn't consume graviolium itself, the gravitic generator does. And the generator starts automatically when the engine is on since Blueshift v1.6.1: The possible solution is to make this thing optional since usually there is more than one generator and automatic switching of one of them creates a mess: when using the Action Group to toggle generators some generators switch on when the ones that were already toggled automatically, shut down.

Nope. Radar Warning Receiver is not about transforms. It's requires getting data from BDArmory about radar threats, distance and bearing of these threats and displaying all this stuff at the MFD. Possibly some new classes and PartModules inherited from MASFlightComputer and BDA RWR will be required to do this.

No. Not in the editor, in flight. With BDA+ 1.5.6.0 all parts explode after heating to 700K with a message "Part X exploded due to heating 700+/700K". Heatseeking missiles get a lock as usually, but I couldn't get a radar lock.

What about other parts? In my case all parts got a MaxTemp of 700K and they all explode, especially radiators and SSTOs.

Looks like all parts got their MaxTemp set to 700K and they spontaneously explode not only flags

Yeah' it's pain, can't understand why everyone abandoned the good old InterstellarFuelSwitch (Okay, B9PS can switch not only resources and it's awesome) I had an idea to make B9PS configs for Unobtainium or Gold Ore/Gold for B2 storage tanks but finally gave up and switched to OmniStorage

Speaking of spaghetti, it gave me an idea of using a brand new gravity gun to spaghettify Kerbals, teleport them outside the solar system and possibly crash the game. In 1.4 it was enough for a Kerbal just to fall from the stairs at the VAB to get a good spaghettification glitch and break space-time but nowadays spaghettification is more complicated so the Universe Destruction Research Institute should look for new tools.

Yesss! But with stock landing gear

I have reasons to do this due to my HOTAS setup: 1. LMB fires missiles too and I want to be selective as I have 2 triggers on my stick: the outer one is used to fire guns until I hear a sidewinder lock sound and then I pull the trigger till the very end and launch a missile withe the inner trigger. 2. I don't have a spare hand to have hands on throttle, stick and mouse. Having only 2 hands might be quiet annoying both for virtual pilots and real ones but let's deal with it.

I use 4 WeaponManager actions : WM.nextWeapon, WM.nextTarget, WM.FireGuns, WM.FireMissile, and lots of part-related actions, such as Fire countermeasure X, activate weapon Y, toggle radar Z, toggle targeting camera Z1.

Yessssss! That's a good idea because with BD Armory you run out of ActionGroups pretty quick.

I guess no one would love to see their precious spaceplanes decapitated after the heatshield explodes. And there is another reason besides aero: maintenance. As far as ablator can not be reablated, Bill Kerman would definitely want to inspect and replace the heatshield of his Eve SSTO after the atmospheric entry before he allows Jeb to fly this thing back into orbit at Mach 5

That would be awesome but I'm not sure that it's even possible with stock ModuleWheelDeployment and ModuleWheelBase. I mean when the retracted landing gear still has it's wheel colliders acting like wheel colliders not like brick colliders. Wheels are pain. Buffalo wheels used to work both in retracted and extended state but they stopped doing it a few KSP and Unity updates ago.

Unfortunately MAS MFDs and HUD don't indicate the radar altitude correctly when underwater. I'll make a PR to MAS repo to fix this. There is an easy fix for props that use fc.AltitudeTerrain(bool ignoreOcean) just need to make it's argument true when underwater like this fc.AltitudeTerrain(fc.Altitude() < 0) but there is nothing I can do with fc.AltitudeBottom() that is used for more precise indications (it calculates altitude from the lowest part of a vehicle, not from a root part). This function always counts sea level as a terrain and turns negative when underwater

For a stationary turret it can be done with already existing tools by using 2 KAL controllers and a mod Mouse Aim Flight to convert mouse movement into pitch and yaw input. Not sure about mouse aim flight but KALs and joystick work just fine for me.

Of course it wouldn't. A powerplant with an output of hundreds megawatts of electrical power required for a microwave plasma jet definitely will not fit. A reactor providing only thermal power to heat the air is much more simple, compact and lightweight it can be just a huge RTG on steroids. Thrust to power consumption ratio of a microwave plasma jet is pretty linear so it will require megawatts of electrical power to generate kiloNewtons of thrust. And it's the best case scenario assuming that this tech scales up without major penalties and the magnetron is 100% efficient. https://newatlas.com/aircraft/microwave-air-plasma-thruster/#gallery:2