hazens1

These have not been updated in a long time, but since they are purely part based they don't need to be updated very often. I use them for 1.0.2 with no problems. http://forum.kerbalspaceprogram.com/threads/57778

You say that the download contains Module Manager, but it is not there.. Slight oversight?

Very nice man!

I say go for it because... Why not? I made 2 large sizes and tested them out. They might be over powered as heck, but I used the same scale math for their increased size. The first one has a scale factor of 1.5 (150%) with a 2.25x stat increase. The second one has a scale factor of 2.0 (200%) with a 4x stat increase. Here are some screen shots. The first image shows the 2 new airbrakes with the original. The original is center bottom, large is bottom sides and mega is top sides. There is a before and after of an in flight test with 1 original, 2 large and 2 mega on a MK3 Jet Plane. Here is the code I used for MM. Includes the Mini version and 2 larger versions. +PART[airbrake1] { @name = miniairbrake1 @rescaleFactor = 0.5 @TechRequired = aerodynamicSystems @entryCost = 5000 @cost = 250 @title = A.I.R.B.R.A.K.E.S (M.I.N.I) @description = After several complaints from our brave pilots that the standard A.I.R.B.R.A.K.E.S were too powerful for smaller craft, the engineers at C7 Aerospace came up with a simple solution. A smaller airbrake. @mass = 0.0125 @MODULE[ModuleAeroSurface] { @deflectionLiftCoeff = 0.1 @ctrlSurfaceArea = 0.25 } } +PART[airbrake1] { @name = largeairbrake1 @rescaleFactor = 1.5 @TechRequired = heavyAerodynamics @entryCost = 15000 @cost = 1000 @title = A.I.R.B.R.A.K.E.S (L.A.R.G.E) @description = After several complaints from our brave pilots that the standard A.I.R.B.R.A.K.E.S were too wimpy for larger craft, the engineers at C7 Aerospace came up with a simple solution. A larger airbrake. @mass = 0.1 @MODULE[ModuleAeroSurface] { @deflectionLiftCoeff = 0.85 @ctrlSurfaceArea = 2.25 } } +PART[airbrake1] { @name = largeairbrake2 @rescaleFactor = 2.0 @TechRequired = heavyAerodynamics @entryCost = 25000 @cost = 2500 @title = A.I.R.B.R.A.K.E.S (M.E.G.A) @description = After several complaints from our brave pilots that the standard A.I.R.B.R.A.K.E.S were too wimpy for mega sized craft, the engineers at C7 Aerospace came up with a simple solution. Make them HUGE!. @mass = 0.2 @MODULE[ModuleAeroSurface] { @deflectionLiftCoeff = 1.5 @ctrlSurfaceArea = 4 } } Here is a download copy of the config I am using. Open source, feel free to use them in your project FishInferno. I am going to do some additional tests by dropping loads from orbit, but I think the numbers as is should be fine. I put them in the Heavy Aerodynamics science research node. Of course, feel free to make any changes you think are necessary :-D http://www./download/ycwalaawv26m01v/NewAirBrakes.cfg Cheers! UPDATE: I did some drop tests with a 28 ton empty rocket stage. With 4 of the original airbrakes, the velocity at sea level from a 100k, 45° arc was ~150m/s and minimal heating and re-entry effects. With the Large airbrakes it was ~100 m/s and with the Mega it was ~50 m/s both basically eliminated re-entry heating. The Mega version seems OP as heck until you compare them to the original which are OP to start with. So using the same math for the stats you end up with crazy slow down :-D I do not see any problems with them as they are. Future re-balancing by Squad may make things more realistic. I guess we can re-visit things in the next update :-P Try them out and let me know what you guys think of the numbers I came up with..

I seems each jet engine has a hard altitude cutoff and having "just enough" intake air will get you there. I have not tested the basic engine and my numbers may be off, but the turbo-jet has a 25.5k ceiling and the rapier has a 29.5k ceiling and no matter how much intake air you have they will "fail combustion" at these altitudes.

0.25 to 0.90 - Memory same usage on average - CPU/GPU average FPS loss of 25% (Had to reduce terrain and graphics quality to maintain the same FPS as 0.25 when I upgraded to 0.90) 0.90 to 1.0 - Memory less usage on average (Never really had memory issues before so moot point) - CPU/GPU average FPS loss of 33% (Had to reduce terrain and graphics quality to maintain the same FPS as 0.25 when I upgraded to 1.0 from 0.90) Conclusion: While I use less memory than 0.25 or 0.90, which didn't really matter much to me, the load times have been better so I guess that is a bonus. Although the FPS issues having 50% less graphics and physics quality over the last few versions have made me sad. I guess I have to upgrade my pc to get back to where I was with the game performance wise around 0.24-0.25 God forbid if Squad ever introduces clouds, dust storms and precipitation on planets. I have tried mods for these features and while I could run them 0.24-0.25 by dropping the graphics quality of the game a little, since 0.90 and 1.0 I cannot use these features even on the lowest game settings unless I want to play with only 15 fps with rockets that only have 50 parts... Squad would probably have slightly better environmental effect code, but not much. I am hoping If/When KSP moves to Unity 5, I can get some of my performance back that I enjoyed before the last few versions of the game. I think most of my issues are CPU related as my video card never gets maxed out running KSP so I am hoping multi-threaded physics would give me that crisp performance from before.

Setup a Stargate on Gilly and Eve, dial the address to Gilly from Eve and just rover the resources through... Oh sorry, wrong game

Did you ensure the config file extension was ".cfg"? When pasting into a text editor sometimes depending on the editor when you save the file is saves as ".cfg.txt". MM scans for .cfg files that contain the keywords. Here is the actual file that I have been using in my game play. I also removed the changes to drag. I've got the config down to just what I think really matters http://www./download/5tblzfpbv6libv7/MiniAirBrake.cfg

Here is a good place to look for part documentation :-D http://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation

You should check the thread and documentation for MM. There is a lot of modding you can do that does not permanently change existing game data as well as adding modified parts without duplicating game assets. While you can use MM to temporarily alter existing parts. The "+PART" (plus) command makes a copy of the part data in the game's part database leaving the original unchanged. The new part of course as you stated uses the same texture, model and sound assets of the original saving memory. The end result is the same except using MM of course saves memory and if a value you are not changing gets modified in a future version of the game or textures/models/sound, your copied part stays up to date except for the values you are modifying of course :-D

Grappling Claw?

Very nice! I felt they were a little OP for their size. So I made my own adjustments after some of my own testing. Still a little OP, but with these values I feel they are more in line with the original. Four of these mini airbrakes equals the effectiveness of 1 regular airbrake. Here is my adjusted Module Manager script that I am happy with. I also moved them 1 tech node earlier :-D Put the code in a text editor and save it as miniairbrake.cfg and place it in the GameData folder along with Module Manager. +PART[airbrake1] { @name = miniairbrake1 @rescaleFactor = 0.5 @TechRequired = aerodynamicSystems @entryCost = 5000 @cost = 250 @title = A.I.R.B.R.A.K.E.S (M.I.N.I) @description = After several complaints from our brave pilots that the standard A.I.R.B.R.A.K.E.S were too powerful for smaller craft, the engineers at C7 Aerospace came up with a simple solution. A smaller airbrake. @mass = 0.0125 @maximum_drag = 0.01 @minimum_drag = 0.01 @angularDrag = 1 @MODULE[ModuleAeroSurface] { @deflectionLiftCoeff = 0.1 @ctrlSurfaceArea = 0.25 } } Cheers!

Found another aberrant behavior or bug possibly related to use with Editor Extensions. When I move the camera to collide with the floor of the VAB or SPH instead of stopping like it normally does, the camera resets to the position when you first load those scenes. Very annoying when you are trying to get a good look underneath your craft

Personally I do not see why a properly designed core could not transfer sufficient heat out of the core and into an area of the engine to heat the propellant without also exposing radiation anywhere but the core. I think you could theoretically have a material that is a good radiation shield and good conductor of heat that can also withstand very high temperatures. Maybe some kind of thermal ceramic that is doped with metals that have high radiation blocking or absorption properties. Of course for safety reasons you would still want a secondary buffer just in case of containment failure or leakage :-D

My only complaint about 1.0.2 is that they nerfed the atmosphere but didn't un-nerf engines to compensate... If you are going back to the "soup-sphere" you better give engines back their lower atmosphere grunt that they had before.