Kaa253

Unfortunately, I have discovered that the Porkjet styled 1.25 m tanks have broken drag configuration. I have tried to fix it but the solution seems to be beyond my skill level.

The first 4 lines of MKS_EL_Resources.cfg file included in MKS download. If you have EL and Module Manager installed it will all happen for you. EL_DefaultStructureRecipe:NEEDS[Launchpad] { MaterialKits = 0.8 SpecializedParts = 0.2 } Just as taniwha said.

@voicey99 More than happy for you to submit them as a PR. Go for it.

I am getting this again with 1.4.2. I still have no idea which mod is causing it but since it seems to be happening more frequently it may be easier to find.

I bodged together a rough edit of the existing EL MM patches for MKS to suit the just released version 6.0.0 of EL. It seems to be working as far as I have tested just quickly. Probably someone with greater scripting skills can do better/cleaner but its a start I guess. Thanks again to RoverDude/MKS community/whoever actually wrote these scripts in the first place. MKS_EL_Classes.cfg MKS_EL_Integration.cfg The others (MKS_EL_Resources.cfg & MKS_EL_Parts.cfg) seem to be still OK. @korniton Try this maybe?

I have just now discovered that the KSP 1.3 version of pWings is also doing unacceptable things to the drag of the parent part in KSP 1.4.2. Guess we will both have to wait for proper updates!

My tests appear to confirm - a lack of ability to adjust control authority and also to inactivate specific rotation axes. Saved craft seem to load just "fine" for me? True

I realise this is highly not recommended. However as a status report... Testing using KSP v1.4.2 and the just now released Kopernicus v1.4.2-1, OPM_Galileo v1.2.5 seems to be working fine. Pood's OPM-VO v0.3.5 also works as long as scatterer is not installed. Installing scatterer kills off the outer planets clouds. I think this may have been already known in KSP 1.3.1.

I realise this is highly not recommended. However as a status report... Testing using KSP v1.4.2 and the just now released Kopernicus v1.4.2-1, OPM_Galileo v1.2.5 and Pood's OPM-VO v0.3.5 all might be working fine as long as scatterer is not installed. Installing scatterer kills off the outer planets clouds.

Very enjoyable missions thank you! I have played through 1 & 2 and everything went well except a bit of bother with detecting the end screen conditions. Mission 1 I eventually got it but I don't think I actually ended mission 2. Looking forwards to the continuing story

Simply upgrade your mini-AVC to the full KSP-AVC

Absolutely spot on! Unless you are working with ion drives then do this every time. Work out your ejection angle well before the transfer window opens and set up your Pe for the elliptical orbit in advance. Half the benefit of building stuff out on the moons comes from taking advantage of your starting position in the gravity well and the Oberth effect. My impression is that KSP works all the physics correctly for this. First you gain in kinetic energy from the fall through Kerbin's gravity well from an Ap near the moon's orbit down to the low Kerbin orbit Pe and then you gain yet again from the greater kinetic energy imparted for a given amount of thrust when applied at the point/moment of highest velocity (i.e. the Oberth effect). In fact, done right, you can eject a big mass on a Hohmann transfer orbit to Duna with relatively little fuel. Actually, on second thoughts I am wrong in what I say above because you will slow down again (i.e. lose kinetic energy) as you climb back up out of Kerbin's gravity well so the only real benefit comes from the maximisation of the use of the Oberth effect. Nevertheless, the roller coaster ride is a lot of fun to execute and must be done!

I installed RealChute into a stock un-modded copy of KSP 1.4.1 that I keep for testing mod bugs. To my surprise I could not reproduce the problem to begin with. Then I discovered the specific conditions required to reproduce the bug are a little, but significantly, different from what I understood yesterday. The new "service module" has a shroud on/off button in the VAB to allow installing parts inside. Also in the VAB in the actions for that part there is "Jettison Shroud" two of them, one for the each of the shrouds pair. These can be bound to an action key. In flight there is an "Enable cutaway" on/off button. This in-flight view does not actually jettison the shroud it only enables visibility of what is inside (something like the IVA view toggle perhaps). So it could cause confusion as it looks like the shroud is gone but it is still there just rendered invisible. Now the final and important part of the puzzle. It is definitely a stock bug. If you use the action key to jettison the shrouds then the game shows the animation of the shrouds being jettisoned but the jettisoned state is apparently not being set as the chutes (both stock and/or RealChutes) will complain of still being stowed! However if you jettison the shrouds through staging (i.e. spacebar) then the chutes will deploy just fine! I have created a report on the Squad bug tracker https://bugs.kerbalspaceprogram.com/issues/18202. Hopefully I have got the steps to reproduce precisely defined now. Sorry to have effectively accused RealChutes of a bug when the problem is really with Squad and my insufficiently careful bug testing. Yesterday I didn't recognise that I had not reproduced the conditions exactly the same to see that it affects stock chutes just the same.

I just hope it doesn't cause you too much grief from every second person reporting it as this is the new DLC "stock" part with the bad shielding descriptor and my guess is it is a generally attractive place to go stick parachutes inside. If the code works the way you say and I am absolutely sure it does then it would presumably count as a stock bug.

The problem is that the "mod" in this case is Squad's Making History DLC. I just stick the chute on the outside of SM-6A Service Module part and its fine. Actually I tuck it in under the docking port.

If you place these chutes inside the new MH SM-6A Service Module part then even after you set that part's Enable Cutaway to ON or alternatively bind jettison shrouds to an action key or even do both these things then the chutes will not deploy due to still being seen as "parachute is inside fairings".

Thanks @IgorZ While I don't know why something changed at the latest version update the Menu key will be just fine to use. It is wonderful that you have given this excellent mod the ability to switch keys around to accommodate different desktops and possible clashes with other mods use of the keys. I incorrectly assumed that if the key I had used before has stopped working then all key switching function must be broken. Clearly this was not actually the case, so my message to anyone else having issues is to persevere and keep trying different key options. Likely you will find some keys combination which will work just fine.

Binding LeftWindows instead of F7 for camera stabilization does not work. I left Menu as vessel switch and that function continued to work correctly. In case of confusion, the settings config is in the spoiler.

Linux Kubuntu. After a lot of fiddling around with an unmodded (EVS excepting) install of KSP v1.4.1 I have found that a lot of keys don't work but some do. When it doesn't work the mod mostly stops reacting but the F7 camera mode still functions (i.e. the mod is clearly loaded alright). I used LeftWindows before and it was great but it really doesn't work any more! RightWindows doesn't work. LeftCommand doesn't work but it maybe in conflict with the KDE window manager. KeypadDivide works but is not a great choice. CapsLock works but hAS ANNOYINg side effects. I settled on the Menu key as it seems to work fine and doesn't do anything else for me. RightWindows is keycode 134 and Menu is 135 so why the latter works but not the former is really weird. It maybe a bug in the new version of unity? vesselSwitchKey { keyCode = Menu } // works fine vesselSwitchKey { keyCode = LeftWindows } // no dice A simple online search does not find any unity bug reports for KeyCode. I have changed nothing else on my PC besides upgrading KSP and mods for 1.4.1.

I have a *nix version. I re-assigned the key the same as in 1.3.1 but it doesn't seem to be working. I tried a different key. I double checked for errors in the settings.cfg file. Nothing unexpected seems to be showing up in the log. Can anyone else confirm they are able to or unable to re-assign the key?

It is worth a check. Bottom left corner of the first loaded menu screen in yellow text it should say like 1.4.1.XXXX (OS) language-pack. It also appears in the bottom left corner of the game pause dialog box and the settings dialog box in game.

You have got my full respect there @stupid_chris! Twenty years on and people look at me weird when they discover I have a fork lift operator's license and a Doctorate. Why? they want to know. Not all of us are handed the soft path through our education. When it comes to paying your own way through University "There is nothing like a Crown for pickin' it up and puttin' it down".

I think you have got the correct GUI component now, yes I agree. RHS window edge. Good job!

I have been playing KSP a long time and it gives a new challenging aspect to the game. That's probably the main reason. Sure it costs in dV a bit but that also forces me to redesign my craft somewhat and tinkering away in the VAB is probably where I spend most of my game time anyway If I am heading out to the Mun or Minmus I don't bother to change inclination to 0 degrees as it is too dV costly. I just aim for the Mun from the inclined orbit and then equatorialize economically as possible mid transit or upon SOI entry and only if it is required. For any high angle orbit activity then I will likely also use Woomerang. If I am launching something high mass (I started a new 1.4.1 career so it hasn't happened yet) such as station parts I will probably go back to KSC. Indeed it "might be cool to have a station on an inclined orbit though" as you say. Add in some realism; ISS inclination = 51.6 degrees so Woomerang at 45.3 degrees is actually slightly easier. I once (KSP v1.2.2?) did a polar orbit Mun station in support of a South Pole located MKS Mun base exploiting water there. That worked out really well. It is really quite good to have Woomerang help nudge me out of my boring addiction to Kerbin's equatorial plane.