totm nov 2017 [1.3.0] Community Database of Module Manager Patches for Stock KSP

[theshepherd]

On 1/9/2018 at 4:06 PM, Stratickus said:

I really like the idea of this patch. I did notice that this skill is not reflected in KER or the part action window. Is this skill referenced anywhere that is visible to the player? Is there a fundamental difference between fuel usage and Isp? I ask because Stragegia uses a similar mechanic that I think does the same thing that this patch trying to do, though the effects are visible in KER. It also manipulates Isp instead of fuel usage. Since there is no way to see the effects (that I have found) of this patch, do you know if it either stacks or interferes with the Strategia mechanic?

Cheers,

Honestly I don't know enough about the mechanics of the game to make the real dV show based on the pilot skill or whether it stacks.  I believe it doesn't because it is a modification of a built-in stat that I statically overwrite.  If I was to venture an uneducated guess, things like Strategia must delve deeper into all the readouts.  I wasn't really troubled to find a way, because I move kerbals around a lot and role played that the efficiency was more like "making the Kessel run" than actually adding dV to the craft.  Hope that makes sense @Stratickus.

Edited February 22, 2018 by theshepherd

[fourfa]

I was a little annoyed that the center of mass of the new Making History M.E.M. Lander command pod is defined at the very bottom edge of the pod.  The donut tank texture at the bottom is texture only - no collider.  The entire point of the weird bulges on the sides of the real-life Lunar Module is to mount fuel tanks near the center of mass, so the CoM wouldn't shift much through the ascent, rendezvous, and docking process.   Likewise, the RCS quads are mounted mid-ships so they're near the average CoM (as copied on the new M.E.M).

Since we face all the same issues they did, and the stock CoM is nonsensically at the edge of the actual structure, I worked out a fix:

// Adjust center of mass of the MEM Command Pod new in KSP Making History for 1.4.1
// Author: Fourfa
// x, z, y relative to VAB door?

@PART[MEMLander]:FINAL
{
	CoMOffset = 0, 0.675, 0
}

It might not be dead center depending what else you strap onto it (docking port, engine, batteries, more fuel/monoprop, etc) but it's pretty close.  Make small changes in the range of 0.6-0.75.

Original:

Adjusted:

Edited March 14, 2018 by fourfa
added screenshots

[Tabris]

19 hours ago, fourfa said:

I was a little annoyed that the center of mass of the new Making History M.E.M. Lander command pod is defined at the very bottom edge of the pod.  The donut tank texture at the bottom is texture only - no collider.  The entire point of the weird bulges on the sides of the real-life Lunar Module is to mount fuel tanks near the center of mass, so the CoM wouldn't shift much through the ascent, rendezvous, and docking process.   Likewise, the RCS quads are mounted mid-ships so they're near the average CoM (as copied on the new M.E.M).

Since we face all the same issues they did, and the stock CoM is nonsensically at the edge of the actual structure, I worked out a fix:

// Adjust center of mass of the MEM Command Pod new in KSP Making History for 1.4.1
// Author: Fourfa
// x, z, y relative to VAB door?

@PART[MEMLander]:FINAL
{
	CoMOffset = 0, 0.675, 0
}

It might not be dead center depending what else you strap onto it (docking port, engine, batteries, more fuel/monoprop, etc) but it's pretty close.  Make small changes in the range of 0.6-0.75.

 

Add that to the official Bug tracker.

[flart]

@Snark, your Adjust the Attachment Nodes for Heat Shields makes all already saved vessels used Direct node unloadable. 

  Hide contents

// Tweak the stock heat shields to do two things:
// - Shroud is disabled by default
// - "Direct" attachment node (intended for attaching without shroud) is removed.
// - "Bottom" attachment node (intended for use with shroud) is moved to former location of "direct" node.
// Author: Snark

@PART[HeatShield1] {
    @node_stack_bottom = 0.0, -0.00, 0.0, 0.0, -1.0, 0.0, 1
    -node_stack_direct = nil
    @MODULE[ModuleJettison] {
        %shroudHideOverride = True
    }
}

@PART[HeatShield2] {
    @node_stack_bottom = 0.0, -0.00, 0.0, 0.0, -1.0, 0.0, 2	
    -node_stack_direct = nil
    @MODULE[ModuleJettison] {
        %shroudHideOverride = True
    }
}

@PART[HeatShield3] {
    @node_stack_bottom = 0.0, -0.00, 0.0, 0.0, -1.0, 0.0, 3
    -node_stack_direct = nil
    @MODULE[ModuleJettison] {
        %shroudHideOverride = True
    }
}

 

 

Why you make bottom node — direct node, and remove direct node, and not just remove bottom node ?

[Snark]

1 hour ago, flart said:

Why you make bottom node — direct node, and remove direct node, and not just remove bottom node ?

Short answer is "because it works for me, and removing the bottom node would break my ships." 

Note that your proposed solution isn't any better, in general.  If the config removed the "bottom" node instead of the "direct" one... then all the people (such as me) who have ships that are using the bottom node would be the ones who have ships that won't load.

Basically, there's no way for everyone to win.  The fundamental problem is that the stock heat shields have 2 nodes, whereas there really needs to be one.  The only way to make that happen is to kill one of the nodes, which means whoever's in the habit of using the killed one will have problems.

The only real solution is to just make the config do whatever works for you, personally.  This config works for me, because I've always been in the habit of using the "bottom" node and so losing the "direct" one makes sense.  If you're the other way around and are a habitual "direct" node user, just tweak the MM config to suit your case instead. 

[Skystorm]

KSP 1.4.1 Build 2089 / Making History Expansion

The 5m fairing is incorrectly using the 3.75m autotruss scaling and node positions.  The following patch will correct the scaling and node positions so that the truss is the correct size and the node positions correctly match.

Spoiler

@PART[fairingSize4]
{
    @MODEL,1
    {
        @scale = 4,4,4
    }

    @node_stack_interstage01a = 0.0, 2.17, 0.0, 0.0, -1.0, 0.0, 2
    @node_stack_interstage01b = 0.0, 2.27, 0.0, 0.0, 1.0, 0.0, 2 

    @node_stack_interstage02a = 0.0, 4.17, 0.0, 0.0, -1.0, 0.0, 2 
    @node_stack_interstage02b = 0.0, 4.27, 0.0, 0.0, 1.0, 0.0, 2 

    @node_stack_interstage03a = 0.0, 6.17, 0.0, 0.0, -1.0, 0.0, 2 
    @node_stack_interstage03b = 0.0, 6.27, 0.0, 0.0, 1.0, 0.0, 2 

    @node_stack_interstage04a = 0.0, 8.17, 0.0, 0.0, -1.0, 0.0, 2 
    @node_stack_interstage04b = 0.0, 8.27, 0.0, 0.0, 1.0, 0.0, 2 

    @node_stack_interstage05a = 0.0, 10.17, 0.0, 0.0, -1.0, 0.0, 2 
    @node_stack_interstage05b = 0.0, 10.27, 0.0, 0.0, 1.0, 0.0, 2 

    @node_stack_interstage06a = 0.0, 12.17, 0.0, 0.0, -1.0, 0.0, 2 
    @node_stack_interstage06b = 0.0, 12.27, 0.0, 0.0, 1.0, 0.0, 2 
}

https://bugs.kerbalspaceprogram.com/issues/18071

Edited March 16, 2018 by Skystorm
Added bug tracker link.

[Foxster]

Make Inflatable Airlock mannable in the VAB and SPH:

// Make Inflatable Airlock mannable in VAB & SPH
// Author: Foxster
@PART[InflatableAirlock]
{
		@CrewCapacity = 1
}

If you do add a crewman to an airlock then you'll need to open/extend the airlock before launching the craft or things will get screwy (for hopefully obvious reasons).

I use this to create a small capsule from an airlock and to be able to have a crewman on board at launch. 

[MaximumThrust]

A small patch to increase the EC usage of the Reaction Wheels. An alternative to add some drawback to them, without removing their ability. Also an incentive to add more batteries and power generation to vessels (something I miss).

Edit: after some testing I think 30 is better. I would use even more if weren't for the rovers (using MechJeb's Autopilot).

Spoiler

// Greatly increases the EC usage by Reaction Wheels
// Author: MaximumThrust

@PART[*]:HAS[@MODULE[ModuleReactionWheel]]:FINAL {
    @MODULE[ModuleReactionWheel] {
    @RESOURCE[ElectricCharge]
    {
        @rate *= 15.0 // Change by how much you want the EC usage multiplied 
    }
    }
}

 

Edited March 22, 2018 by MaximumThrust

[leatherneck6017]

An update to the patch that @maculator posted for 100% science data transmit. Reason being, some mods use custom names for their science parts (i.e. Dmagic Orbital Science). This patch will apply itself to any part that has a category of "Science."

// Set data transmit value to 100% on any science part.
// Author: leatherneck6017
@PART[*]:HAS[#category[Science]]:FINAL
{
	@MODULE,*
		{
		@xmitDataScalar = 1.0
		}
}

 

[klesh]

On 3/18/2018 at 2:50 PM, MaximumThrust said:

A small patch to increase the EC usage of the Reaction Wheels. An alternative to add some drawback to them, without removing their ability. Also an incentive to add more batteries and power generation to vessels (something I miss).

 

Right now there is a bug with the Mk2 Command Pod's original EC consumption rate (it is 1.2ec/min instead of ec/sec).  With your MM patch, the Mk2 Pod comes out to using 0.3ec/sec, which is certainly 15x more than its normal rate, but still woefully behind the others and not at an unusually high rate like you're trying to accomplish.  I don't know if you want to make a special consideration for the Mk2 Pod with a higher multiple, as you'll just have to change it again when the rate gets patched by Squad, presuming they patch it. 

[MaximumThrust]

1 hour ago, klesh said:

Right now there is a bug with the Mk2 Command Pod's original EC consumption rate (it is 1.2ec/min instead of ec/sec).  With your MM patch, the Mk2 Pod comes out to using 0.3ec/sec, which is certainly 15x more than its normal rate, but still woefully behind the others and not at an unusually high rate like you're trying to accomplish.  I don't know if you want to make a special consideration for the Mk2 Pod with a higher multiple, as you'll just have to change it again when the rate gets patched by Squad, presuming they patch it. 

Thanks. I think this could easily be done with some more lines. The problem is in the 1.4.1 version, or in the 1.3.1 too? I can't open the game right now.

[klesh]

13 minutes ago, MaximumThrust said:

Thanks. I think this could easily be done with some more lines. The problem is in the 1.4.1 version, or in the 1.3.1 too? I can't open the game right now.

 

Mk2 Pod is the Gemini pod from Making History, so only 1.4.1. 

 

[MaximumThrust]

19 minutes ago, klesh said:

 

Mk2 Pod is the Gemini pod from Making History, so only 1.4.1. 

 

I was confusing it with the Mk1-2. I'll stay in the 1.3.1 and didn't bought the DLC, feel free to add a solution if you want 

Edited March 22, 2018 by MaximumThrust

[Psycho_zs]

An update for angled docking patch: instead of targeting specific parts, target ModuleDockingNode's nodeType (by stock values):

// Add angle snapping to Docking ports with stock nodeType values (12 increments as on textures)
// Author: Psycho_zs
@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
	@MODULE[ModuleDockingNode]:HAS[#nodeType[size0]],*
	{
		// If you want X degrees wide margin, use cos(0.5*X) as captureMinRollDot
		// 0.5 degrees = 0.99999048
		// 1 degree    = 0.99996192
		// 2 degrees   = 0.9998477
		// 3 degrees   = 0.99965732
		// 5 degrees   = 0.99904822

		%captureMinRollDot:NEEDS[!DockRotate] = 0.99996192

		// more relaxed version to use with DockRotate
		%captureMinRollDot:NEEDS[DockRotate] = 0.99904822

		%snapRotation = true
		%snapOffset = 30
	}
	@MODULE[ModuleDockingNode]:HAS[#nodeType[size1]],*
	{
		%captureMinRollDot:NEEDS[!DockRotate] = 0.99996192
		%captureMinRollDot:NEEDS[DockRotate] = 0.99904822
		%snapRotation = true
		%snapOffset = 30
	}
	@MODULE[ModuleDockingNode]:HAS[#nodeType[size2]],*
	{
		%captureMinRollDot:NEEDS[!DockRotate] = 0.99996192
		%captureMinRollDot:NEEDS[DockRotate] = 0.99904822
		%snapRotation = true
		%snapOffset = 30
	}
}

First, It is logical to target nodeType since it kinda represents a mechanical standard . Second, this patch will also affect any mod stock-compatible docking port, so compatibility is preserved.

Also added a version to go with the great DockRotate mod (It adds ability to rotate docking ports in-flight and auto-straightens angle-locked ports):

Edit: There seems to be a problem with selector "size0|size1|size2" inside HAS, so I've expanded it into multiple node statements.
",*"  should help with "universal" docking ports that have multiple nodes of different types.

Edited March 26, 2018 by Psycho_zs

[Sunesha]

Simple adjustments of maximum available contracts found it some years ago, so have no idea who the author is.

 

// Adjust the number of maximum available contracts 

@Contracts:Final

{

# Default: 10

@AverageAvailableContracts = 20

}

 

[Tyko]

Has anyone found a way to reduce the lateral thrust on the LES? instead of just tipping the capsule sideways it send the capsule cartwheeling away. There's only one ModuleEnginesFX, so I can't figure out how to lower the lateral without reducing power on the entire LES.

Ideas?

[fourfa]

Stick a single separatron opposite the lateral nozzle, reduce it to a single tick of fuel, and give it 45-90 degrees of angle relative to the long axis.  Takes some trial and error to tune it, but you can get the capsule to just peel away smoothly

[luizopiloto]

MM patch to remove attachment nodes from the corners of the MH structural panels:
WARNING: Any craft that have any part attached to the nodes removed by this patch will not load correctly or not load at all, edit those crafts before applying this patch.

Spoiler

Sorry Dude... Those nodes are really annoying...

@PART[Triangle*]:HAS[#author[RoverDude]]:FINAL
{
	!node_stack_topleft = 0
	!node_stack_lefttop = 0
	!node_stack_topright = 0
	!node_stack_righttop = 0
	!node_stack_bottomleft = 0
	!node_stack_leftbottom = 0
}

@PART[Panel*]:HAS[#author[RoverDude]]:FINAL
{
	!node_stack_topleft = 0
	!node_stack_lefttop = 0
	!node_stack_topright = 0
	!node_stack_righttop = 0
	!node_stack_bottomleft = 0
	!node_stack_leftbottom = 0
	!node_stack_bottomright = 0
	!node_stack_rightbottom = 0
}

[Alshain]

Regarding the state of this thread, I simply don't have time to fight with the awful forum software in order to continue to add new patches to the original post.  If someone out there has the time on their hands and wants to continue in a new thread (or better, find a good platform to host it rather than here) you have my blessings to do so.  I'm afraid it just became too successful for it's own good and without any kind of markup editing like BBCode, it's become un-maintainable.

Edited April 12, 2018 by Alshain

[BlkBltChemie]

@Alshain , I know you just said that you would not continue adding new patches but I wanted to say thanks for this incredible thread.  It has a lot of great patches that are useful in game but also serves as a great tutorial for beginners interested in writing their own patches.  It gave me the tools and examples I needed for my first foray into KSP modding which follows below:

I've always felt the Mk1 pod need a Launch Escape System so that was the first thing I tried.  It is simply a rescale of the standard LES by 0.5x with fuel, thrust, and cost also divided in half.  Because this would occupy the top node of the pod blocking the attachment point for a parachute (and because the Mk2 radial parachute looks way too big on a Mk1 pod), I also patched a 0.5x Mk1 radial parachute to go with the LES.  Finally, I added a decoupler to both the stock and rescaled LES so they can be automatically jettisoned without needing another docking port/decoupler.  (Every once in a while, the LES tower will collide with the pod when it is jettisoned after an abort, particularly if the capsule is tumbling quickly - I tried adjusting the ejection force but to no avail.  Also, I was not successful in getting the decoupler added to staging.)  I picked Engineering 101 because the Start node lacks a stack decoupler and 45 science points for Survivability seemed too high.

Spoiler

// I'd particularly like to acknowledge @maculator for his/her heatshield decoupler code which I used as the starting place for the LES decoupler.

// Add Mk1 LES at Engineering 101 with built-in decoupler
// Works with Mk1 Pod, Mk2 Pod (Making History), and Mk1-3 Pod when using SM-6A Service Module (Making History), but TWR is low for the latter
+PART[LaunchEscapeSystem]
{
    @name = LaunchEscapeSystemMk1
    @rescaleFactor = 0.50
    @TechRequired = engineering101
    @entryCost = 2250
    @cost = 500
    @title = Mk1 Launch Escape System
    @mass = 0.45
    @bulkheadProfiles = size0
    
    @MODULE[ModuleEnginesFX]
    {
        @maxThrust = 375
    }

    @RESOURCE[SolidFuel]
    {
        @amount = 15
        @maxAmount = 15
    }

    sound_decoupler_fire = decouple    

    MODULE
    {
        name = ModuleDecouple
        ejectionForce = 100
        explosiveNodeID = bottom
    }
}

// Add new Mk1 radial parachute chute at Engineering 101 since LES blocks command pod top node
// Chute resized to match radial drogue chute so it looks better with Mk1 Pod
+PART[parachuteRadial]
{
    @name = SmallRadialChute
    @rescaleFactor = 0.50
    @TechRequired = engineering101
    @entryCost = 1400
    @cost = 200
    @title = Mk1-R Radial-Mount Parachute
    @mass = 0.05
}

// Add decoupler to Stock LES
@PART[LaunchEscapeSystem]
{
    sound_decoupler_fire = decouple    

    MODULE
    {
        name = ModuleDecouple
        ejectionForce = 100
        explosiveNodeID = bottom
    }
}

To wrap things up, I also patched a 1.875m service bay for the Making History Mk2 pod using both the 1.25m (grey) model and 2.50m (yellow) model which unlocks with the Mk2 pod in Advanced Flight Control as an alternative to the new service module.  A Science Jr. is a little too tall, but the science container is just the right height.

Spoiler

// Add 1.875m service bay based on 1.25m service bay (grey)
+PART[ServiceBay_125]
{
    @name = ServiceBay1p5a
    @rescaleFactor = 1.50
    @TechRequired = advFlightControl
    @entryCost = 1000
    @cost = 500
    @title = Service Bay (1.875m)
    @mass = 0.2
    @bulkheadProfiles = size1p5
}

// Add 1.875m service bay based on 2.50m service bay (yellow)
+PART[ServiceBay_250]
{
    @name = ServiceBay1p5b
    @rescaleFactor = 0.75
    @TechRequired = advFlightControl
    @entryCost = 1000
    @cost = 500
    @title = Service Bay (1.875m)
    @mass = 0.2
    @bulkheadProfiles = size1p5
}

Any feedback in more than welcome and would be appreciated!  Thanks again for the great examples presented in this thread!

[klesh]

On 5/17/2016 at 1:34 PM, Alshain said:

Stop Solar Panels from Sun Tracking
Contributor: @tg626, @Alshain

  Hide contents

// Stop solar panel from sun tracking
// Author: tg626, Alshain
@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL
{
	@MODULE[ModuleDeployableSolarPanel]
	{
		//%sunTracking = false //v1.1 and earlier
		%isTracking = false // v1.2+
	}
}

 

 

Hi.  I am wondering if it is possible via MM magic to add a button to the PAW of deployable solar panels, that allows the player to select, in flight, whether the panels track the sun or not?  A button such that the sun tracking ability could be turned on or off at will by the player.

I know just enough about making MM patches to almost be dangerous.  I have no problems coming up with it myself, but perhaps if you know whether it is even possible or not, or could point me in a reasonable direction so I might give it a try myself.

Perhaps an advanced tweakables slider that allows the tracking rate to be set, or perhaps making it so pressing the PAW button once sets the tracking rate to 0, and pressing it again sets the rate to 1 with a corresponding flavor text.

[cyberKerb]

Can I suggest adding this patch posted by @OHara in the suggestion section for adding aero/drag shielding to parts that appear hollow? Seems like a good fit to be added to the patch list.

 

Edited May 23, 2018 by wile1411

[ringerc]

On 3/6/2017 at 12:48 AM, OHara said:

1) Make the rate of pyrolysis of ablator depend more strongly on temperature.  Then it will not evaporate during normal operation, but will carry away significant heat on reentry.

2) Reduce the default amount of ablator on a heat shield, as it is not necessary for entry from Kerbin orbit (so its extra mass does less harm for new players)

Wow, I wish I'd known of this before writing https://github.com/ringerc/ksp-minimods/blob/master/HeatShields/HeatShieldsArentMagic.cfg . Though my goals were a bit different - I want to make heat shield failure an issue too, and stop depleted-ablator shields from being magical heat guards.

[ringerc]

On 4/13/2018 at 7:01 AM, Alshain said:

Regarding the state of this thread, I simply don't have time to fight with the awful forum software

No kidding! I'm used to mailing lists, threaded forum-like environments like Reddit, etc, and this is ... stone age. Thanks for doing as much as you did.

[Ooop]

on the first page there is a really useful patch that add a fuel resource to the staging tree if the engine you are using doesn't.

my question is

1. can you change the color of the fuel resource. as in Xenon gas showing up as blue instead of the usual green?

and 2. is there a way to apply the config to all engines that use Xenon gas?