TaggedYa

@BlackHat In my book it's greatest use is for the iterative process to design MechJeb assent profiles for PEG. By the time you get that right you will have found all of your staging issues. :-) You increase part reliability when just starting with a new part by research. Right click the part and find the research button on the info window, usually toward the bottom. It will open a window where you can hire research teams to do daily increases. I tend to only use the cheapest teams. All you get for more money is time savings. I usually am not in all that great a hurry. TaggedYa

@linuxgurugamer @pap1723 Why not just push a config for RP-1 into the regular data folder with the rest of the standard configs. Then we could just click the appropriate button and are good to go. If the basic code is reading the configs and making buttons for each it shouldn't require any work on lgg's part at all. Nor should it require a bunch of jumping through ckan hoops. On a different subject: I am looking at trying to make a cost function that charges by real time expended not game time so that time warp doesn't result in exponential cost explosion and we can actually simulate long missions. Is that something you would be amenable to? TaggedYa

Go ahead and reinstall US Rockets then use the dependancys I linked above (provided by RaiderNick) to overwrite the ones that CKAN put in. Everything will then work fine.

Try removing RN_US_Rockets with CKAN and reload. I was having this issue and removing it let my game load. I am still trying to figure out the problem but I can run with it uninstalled. TaggedYa Ok: CKAN is updating a US Rockets dependancy to a non 1.2.2 compatable version. get the current dependancy versions here: https://www.dropbox.com/s/paqjbizbmxfhdqc/RN_Dependencies_KSP_v1.2.x.zip?dl=0 Overwrite the existing with these.

Thanks for the quick fix. As to misconceptions: Relying on 2 variables to stay equal when 2000 coders have access to them is just begging for trouble. And it is the worst sort of trouble as it will come and go depending on the whim of the unknown coder who changed it.

I think I found it. It seems to be a convergence of 2 bugs. One in your size check and one in B9 proc wings fork by Crzyrndm. I found yours but haven't isolated his yet. In LaunchGUI.cs In line 1121 you are adding the width and depth of the rocket and comparing it to the width limit. 1118 1119 Vector3 s = EditorLogic.fetch.ship.shipSize; 1120 Vector3 sizeLimit = getSizeLimit (); 1121 if (s.x + s.z > sizeLimit.x) { 1122 startSim += "\nShip too wide"; 1123 flyable = false; 1124 } 1125 if (s.y > sizeLimit.y) { 1126 startSim += "\nShip too tall"; 1127 flyable = false; 1128 } 1129 I'm pretty sure this should be: 1121 if (s.x > sizeLimit.x) | (s.z > sizeLimit.z){ I can't test this as I lack a c# compiler. Can you believe codeblocks doesn't support c#. Yea, Yea I know, It's because I haven't written it yet. :-( At least so I'm told.

Having updated through ckan at about 8 am UTC I am unable to use this. All rockets are reported as to wide no matter how thin. Full RSS/RO/RP-0 on 1.1.2. If the problem is not immediately obvious let me know and I will do the start clean thing to nail it down. Mean time I am rolling back to 0.5.9.

What is happening is when the first stage falls out of range and is removed the sym treats it as the destruction of your main ship and ends the sym. I am using the dev build .1183 without stagerecovery. I would bet that when stagerecovery removes the launch clamps it does the same thing. I can reproduce it at will as it happens every time. Tag

In Plugin/Trajectory.cs on line 683 there is a call to: FARAeroUtil.GetCurrentDensity(body, altitudeAboveSea) In "Ferram-Aerospace-Research-0.15.5.5_Hugoniot" this method was changed to: public static double GetCurrentDensity(Vessel v) In Plugin/VesselAerodynamicModel.cs on line 153 is: FARAeroUtil_GetCurrentDensity = loadedAssembly.assembly.GetType(namespaceName + ".FARAeroUtil").GetMethodEx("GetCurrentDensity", new Type[] { typeof(CelestialBody), typeof(double), typeof(bool) }); I am not familiar with C# but this looks like a typecast to an even older version. Then on line 245 we have: rho = useNEAR ? stockRho : (double)FARAeroUtil_GetCurrentDensity.Invoke(null, new object[] { body_, currentAltitude, false }); Then again in 343, and 541. I would fix this and test the result but I have neither a C# compiler (I could get one I guess) nor Unity which is a bigger problem. If someone would be kind enough to make the appropriate changes and post the recompile I will test it and see if I can find the more subtle problems. Tag