hazens1

The best way to avoid duplicate modules when using MM is to add the !MODULE parameter like so. @PART [*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore } } Or if you want to preserve tech tree progress when adding MechJeb to all command modules. @PART [*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } }

Feature request. After seeing someone make a MM config to adjust chute deployment speeds I thought maybe that would make a great parameter to be added to Tweakable Everything. This way one could have a quick deploying emergency chute and a slow deploying landing chute without having to make multiple copies of the same parts to accomplish 2 deployment speeds for the same chute.

Stock install as it says in the OP. No mods, same settings. Specs should not matter. I am comparing performance between 2 version of KSP, not 2 different hardware configurations, but here they are. - Operating System: Windows 7 Home Premium 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.140706-1506) - Processor: Intel Core i7-2720m CPU @ 2.70GHz (4 CPUs), ~2.7GHz - Memory: 16 GB RAM - Graphics: NVidia GTX 555m - 3 GB RAM (Drivers: Latest 344.75 Nothing unusual in the logs. I run multiple copies of KSP for access to various mods. To rule out any issue with my final comparison, I did a fresh install of 0.25 and 0.90 in different folders with zero mods and let each generate default config files. Opened config files and aside from a few new keybinds and 1 new graphic setting everything is identical by default. I tried running in OpenGL, DX9 and DX11 and all have the same results. Tried 32bit and 64bit. Conclusion: KSP 0.90 runs ~25% slower than 0.25 in all scenes.

My only complaint is now as you add complexity to the buildings, the FPS drops when within view of KSC or while you are viewing your craft at an angle in the hangars that show outdoors. FPS drops 50% when looking out the door compared to looking at the back wall when all buildings are fully upgraded. Does not matter how many parts the craft has. Does not make any sense to render buildings that you cannot actually see while inside the VAB or SPH.

I was hoping for an increase in performance with the new version. Or at least the same performance. I was totally wrong. I am seeing an average drop of 25% in FPS across all scenes with a stock 0.90 install compared to 0.25 using identical craft. Frames are worse within viewing distance of KSC or when looking at an angle towards outside from withing the hangars. What is everyone else's FPS experience with the new version?

Not only this, but I was expecting at least a slight performance improvement for 0.90. Boy I was sorely wrong. In fact, I am seeing an average decrease of 25% in FPS on all scenes. Going in the wrong direction here...

I have got to say those launch clamps look so smexxy it hurts Nice job!

How did I miss that? I did read the OP, I will admit very quickly . I must have hit the scroll wheel when I hit that element moving the part about skybox out of view. Was not that hard to figure out since I am familiar with XYZ positioning, I just thought I did something wrong. Should have did a "Find" on skybox instead of space scape, would have taken me right there... Thanks!

Anyone familiar with using Space Scape to make sky boxes? Space Scape saves textures as Back, Front, Right, Left, Up and Down. Fiddling around I am able to get 5 out of the 6 textures to line up in KSP, but I have to rotate the last one 180° to get it to line up. Is this normal or does someone have a better way? I have been using the following as my key. Back = Negative Z Front = Positive Z Right = Negative X Left = Positive X Up = Negative Y Down = Positive Y (I have to rotate 180° to line up)

What skybox are you using for your Youtube series? I love the bluish gas cloud filaments but I cannot figure out where that comes from. Thanks!

That is one heavy 0.625m part Is the new 0.625m engine supposed to weigh the same (8.5t) as the 2.5m one?

BF4 although it has 60 Gig of assets, will only need to load the assets for a given map or level. KSP on the other hand has to load all of the assets into memory because the entire game is 1 huge map/level. KSP has to have all of the assets ready to go in case they are needed.

Any plans to add vessel Pitch, Roll and Heading in a future release?

Ya, I am already using the Compact GUI option. Other than scale, these look to be the only 2 options. Guess I will just make some custom windows in Engineer to replace the Orbital, Surface and Vessel windows from MechJeb since that mod has tighter spacing between lines.

Is there any way to reduce the space between info lines in any given window? I find the amount of "white space" between lines to be too large for my taste and would like to reduce it. Thanks!

It is Tweak Scale. I suggest going back to 1.44 or 1.45 until the next update comes out.

I said limited experience. I've never tried to take a ship striaght to Jool from Kerbin using the warp drive. I just rechecked my "rough" math and I had 1 extra zero Still my numbers hold for a real life stellar and galactic journeys.. Although if one was to have another star system in a game they would probably put it a lot closer than 4 light years distance for balance reasons unless there was tech capable of higher speeds

Not sure 1.6x light speed would be sufficient to even visit the nearest star system for this warp drive. Considering "Our" nearest star is a little over 4 light years away and since this warp drive works on translation instead of velocity you have to have it powered up for the entire journey. So simulating that journey even at 4x physical time acceleration and at 1.6x light speed you would have to leave the game running for at least 6 months before you arrived at the nearest star system if there was one to visit Now traveling to another galaxy you would need an engine that could achieve 2.5 million times light speed just to reach our nearest galaxy Andromeda in 12 months time. Heck I have very little experience using this mod, but even using it as primary engine to travel from Kerbin to Jool would take at least 4 hours nearest approach at 4x physical time warp according to my rough calculations.

You have probably hit the ram limit. Try using Active Texture Management mod or remove some mods then load up KSP and lower your Texture Quality in the video configs then re-add the mods you removed. Changing the texture quality in the configs from Full to Half generally lowers ram usage by 40%. If you want to keep high(Full) quality textures then use the ATM mod.

There is an option in the MechJeb settings for this to remove the standard toolbar button.

Does scaling a part also affect the Crash Tolerance? Decreasing a part seams to make it as brittle as egg shells an increasing the size makes it indestructible in most cases. If this is so maybe the formula used for the crash tolerance should be adjusted?

Anyone ever try making a mod/parts for electric motors for propulsion in atmosphere? I think the addition of 0.625m and 1.25m prop driven and/or ducted fan brushless motors that the only resource drain was electricity would be pretty cool.

This. Make it an option to auto scale. I want to turn it off, I find it so annoying even when it is right... Also, the bug where the mass and other numbers are getting inflated or deflated to incorrect numbers for the appropriate scale can be re-created with nothing but Tweak Scale and MechJeb installed. Start with a MK1 Command Pod. The one with a 1.25m bottom and a 0.625m top. Place a Small Inline Reaction Wheel on top of the command pod. Resize it up from 1.25m to 2.5m and the mass will go up. Resize it back to 1.25m and the mass will stay at what it was when it was at 2.5m. This can be repeated with pretty much all of the parts when connecting a part that is classified as a "stack" to another "stack" part. This bug can also be reversed by resizing from 1.25m to 0.625m then back again and the part will have an unusually small mass. I was only able to cause the bug to happen when attaching a "stack" part to another "stack" part. Seems to work correctly when attaching a "stack" part to a "surface" part such as an Octo2 probe core which probably should be classified as stack anyways... Also, the Small Inline Reaction Wheel was changed from a 1.25m part to a 0.625m part in version 0.25 so the config should maybe be changed to reflect that? Some of the smaller probe cores are classified as surface and maybe should instead be stack or maybe not be configurable at all since there are probe cores for most sizes? Here are some screen shots showing the bug with a different command pod and fuel tanks. Before any changes are made the total mass is 3.28t Sizing up make the mass go up to 19.03t which appears to be correct. Changing the fuel tank back down to the normal size of 1.25m causes the extra dry mass to be retained from the previous 2.5m size. Again this time going from 1.25m to 0.625m sizes.