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

[Foxster]

On 17/05/2016 at 6:34 PM, Alshain said:

[1.1] RCS to Translate Only
Contributor: @Snark

  Hide contents

// Configure RCS to Translate Only by Default
// Author: Snark
@PART[*]:HAS[@MODULE[ModuleRCS]]
{
	@MODULE[ModuleRCS]
	{
		%enableYaw = false
		%enablePitch = false
		%enableRoll = false
	}
}

Is this still good for 1.2? Has "ModuleRCS" changed?

[Alshain]

5 minutes ago, Foxster said:

Is this still good for 1.2? Has "ModuleRCS" changed?

Theoretically it should still work, ModuleRCSFX is used now but is impemented from ModuleRCS (just like the engines).  If it isn't working try adding FX to the end of both ModuleRCS lines.  Let me know how it goes.

[Tarheel1999]

1 minute ago, Alshain said:

Theoretically it should still work, ModuleRCSFX is used now but is impemented from ModuleRCS (just like the engines).  If it isn't working try adding FX to the end of both ModuleRCS lines.  Let me know how it goes.

Works for me and caught me by surprise the one time I tried to use RCS for rotation.

[Foxster]

22 minutes ago, Alshain said:

Theoretically it should still work, ModuleRCSFX is used now but is impemented from ModuleRCS (just like the engines).  If it isn't working try adding FX to the end of both ModuleRCS lines.  Let me know how it goes.

Thanks. Yes, needed the FX. 

Edited October 20, 2016 by Foxster

[monstah]

You know, I was thinking of making such a thread the other day. I didn't know it already existed

How about a section for mod patches? I got one in my signature.

[Alshain]

3 minutes ago, monstah said:

You know, I was thinking of making such a thread the other day. I didn't know it already existed

How about a section for mod patches? I got one in my signature.

If you want to create and manage a second thread for individual mod patches, you are more than welcome (I'll even link to it in the main post here).  But with the new forums maintaining this thread is pretty difficult as it is, so I'm not going to do mods (that includes Squad's official mods and the Porkjet parts).  Personally I think mod makers should host a list of patches like that in the thread for the mod.

Edited October 20, 2016 by Alshain

[monstah]

Fair enough. There are a ton of them, anyway

[Enceos]

@Alshain Half a year ago I made a little patch which adds attachment nodes to all solar panels. Great for KIS users and symmetry lovers.

Spoiler

@PART[*]:HAS[#node_attach[*],@MODULE[ModuleDeployableSolarPanel]]
{
    %node_stack_root = #$node_attach$
    @attachRules = 1,1,0,0,1
    @bulkheadProfiles = size1, srf
}

Can be reconfigured to add nodes to any part with surface attachment.

Edited October 20, 2016 by Enceos

[monstah]

I didn't see this one in the OP

[Vegetal]

2 hours ago, Enceos said:

@Alshain Half a year ago I made a little patch which adds attachment nodes to all solar panels. Great for KIS users and symmetry lovers.

  Hide contents

@PART[*]:HAS[#node_attach[*],@MODULE[ModuleDeployableSolarPanel]]
{
    %node_stack_root = #$node_attach$
    @attachRules = 1,1,0,0,1
    @bulkheadProfiles = size1, srf
}

Can be reconfigured to add nodes to any part with surface attachment.

As a KIS user myself, this seems very useful indeed! Can it be applied like this to rover wheels too?

Also, no one answered me on the jettisoning. Can it be done? I suck with code...

[Enceos]

14 hours ago, Vegetal said:

As a KIS user myself, this seems very useful indeed! Can it be applied like this to rover wheels too?

Absolutely, just changing the module name will do the trick.

@PART[*]:HAS[#node_attach[*],@MODULE[ModuleWheelBase]]

Didn't try it with the " | " (or) syntax

Maybe you can have one config for both types of parts.

@PART[*]:HAS[#node_attach[*],@MODULE[ModuleDeployableSolarPanel|ModuleWheelBase]]

 

Edited October 21, 2016 by Enceos

[Enceos]

I also have a config for a delayed retro booster:

Spoiler

+PART[sepMotor1]:Final
{
    @name = delayedRetro    
    @title = Sepratron I-D
    @description = Same as the Sepratron I but with a delayed fuse.
    !MODULE[ModuleSRBThrust] {}
    MODULE
    {
        name = ModuleSRBThrust
        resourceName = SolidFuel
        useTimeCurve = false
        thrustCurve
        {
            key = 0.00 0.01
            key = 0.05 1.00 0 0
            key = 0.93 1.00 0 0
            key = 0.98 0.10 0 0
            key = 1.00 0.10
        }
    }
}

And adding thrust curves to the solid boosters (the curves feature became stock in 1.1 afaik). The one below is a Shuttle type SRB curve, good for scaled "Kickback":

Simple linear curve will look like this:

key = 0 0

key = 1 1

Spoiler

@PART[*]:HAS[@RESOURCE[SolidFuel]]
{
    @MODULE[ModuleEngine*]
    {
        %useThrustCurve = true
        
        %thrustCurve
        {
key = 0 0.01 8.032298 1.11047
key = 0.01342202 0.07843862 1.11047 0.2269303
key = 0.01526241 0.7107602 1.799464 1.591762
key = 0.2355173 0.8904908 0.1987092 0.1987092
key = 0.3413242 0.7365882 -2.900315 -2.900315
key = 0.4019614 0.7171836 0.4377778 0.5915467
key = 0.7633486 0.9773242 0.407829 0.407829
key = 1 1
        }
    }
}

A config for 5m fairings:

Spoiler

+PART[fairingSize3]
{
    %name = fairingSize4

    @MODEL
    {
    %scale = 1.33,1,1.33
    }

%title = AE-FF4 Airstream Protective Shell (5m)
%description = While the Kerbals at Mission Control were still figuring out how to get their rockets back down to Kerbin safely, the research engineers at FLOOYD were quickly realising that protecting parts on ascent was just as important. Heavy research into two-dimensional-input driven procedural construction was then funded with the hopes of making protective shells for important payloads and interstage areas of the crafts. The protective shells also have the benefit of making the craft more aerodynamic, hopefully saving on precious rocket fuel! The AE-FF4 is the experimental prototype from FLOOYD. It is designed for the largest rockets which come from private companies from various parts of Kerbin.
%mass = 0.64
%bulkheadProfiles = size4

    @MODULE[ModuleProceduralFairing]
    {    

        %baseRadius = 2.5
        %maxRadius = 8
        %xSectionHeightMax = 7
    }

}

And a 7m fairing for those mammoth boosters by @NecroBones (provided by @Stone Blue in my thread)

Spoiler

+PART[fairingSize3]
{
    %name = fairingSize5

    @MODEL
    {
    %scale = 2,1,2
    }

%title = AE-FF5 Airstream Protective Shell (7.5m)
%description = While the Kerbals at Mission Control were still figuring out how to get their rockets back down to Kerbin safely, the research engineers at FLOOYD were quickly realising that protecting parts on ascent was just as important. Heavy research into two-dimensional-input driven procedural construction was then funded with the hopes of making protective shells for important payloads and interstage areas of the crafts. The protective shells also have the benefit of making the craft more aerodynamic, hopefully saving on precious rocket fuel! The AE-FF5 is the experimental prototype from FLOOYD. It is designed for the largest rockets which come from private companies from various parts of Kerbin.
%mass = 1.1
%bulkheadProfiles = size5

    @MODULE[ModuleProceduralFairing]
    {    

        %baseRadius = 3.75
        %maxRadius = 10.5
        %xSectionHeightMax = 7
    }

}

 

Edited October 21, 2016 by Enceos

[Alshain]

Ok, I think I have the list updated up to this point.

[Wolf Baginski]

On the sequencing of Module Manager patches

On 19/07/2016 at 9:48 PM, Foxster said:

Adds Mechjeb to all command modules and makes all its functions available from start

Ah, just realised this thread is for stock KSP. Ignore this then. 

Might suggest something of wider interest, though. Current beta versions of MechJeb are applying the most restrictive set of rules they find, so if one mod applies a different version of the settings, unexpected things can happen.

I don't know which way round two different patches, both set to ":Final" would be applied, though the "%" looks to cover many situations. But if you have two subfolders of GameData you can set the patches in one folder to run after those in the other. If there isn't a .dll to take the Mod name from, you can use the folder-name. Something like GameData/MMPatch1 and GameData/MMPatch2 so you could use something such as :After[MMPatch1]

Then you could do something general in MMPatch1, amend specific items in MMPatch2, and not have to worry about using :Final  And you would also be able to use :Before :For and :Needs

I am not sure how Module Manager sets the order of these named groups, but it wouldn't surprise me "U2" was ordered before "ZZTop". Maybe having a "ZZTop" folder with a dummy patch, not doing anything important, would give you an :After[ZZTop] pass that would be executed before :Final and after everything else.

And then there is the possibility of re-naming some utility .dll to do the same. But I don't know how the module-name and filename intereract. Does it matter if you change the filename for calling a module? It doesn't sound like a good idea.

[samamstar]

So I tried making a patch to make the atmospheric sensor smaller(Because its HUGE) but its not applying on load, any ideas why?

//this patch makes the atmopheric sensor smaller
@PART[sensorAtmosphere]:FINAL
{
	//set this factor bigger to make the part bigger, smaller to shrink it
	@rescaleFactor = 0.3
	//I suggest 0.3, that puts it right around the scale of the thermometer & accelerometer
}

and yes, I double checked its a .cfg file in my gamedata folder.

 

edit: OH YEAH 1.2.1! I guess it broke MM

edit2: nvm, sarbian said it works

Edited November 4, 2016 by samamstar
TYPO, then realizing 1.2.1 is a thing

[samamstar]

On 11/3/2016 at 1:48 PM, samamstar said:

So I tried making a patch to make the atmospheric sensor smaller(Because its HUGE) but its not applying on load, any ideas why?

//this patch makes the atmopheric sensor smaller
@PART[sensorAtmosphere]:FINAL
{
	//set this factor bigger to make the part bigger, smaller to shrink it
	@rescaleFactor = 0.3
	//I suggest 0.3, that puts it right around the scale of the thermometer & accelerometer
}

and yes, I double checked its a .cfg file in my gamedata folder.

 

edit: OH YEAH 1.2.1! I guess it broke MM

edit2: nvm, sarbian said it works

Actually, it does work, I just wasn't making the cfg correctly

[fourfa]

A couple of small tweaks I've been thinking about; I assume these are fairly simple since they both have advanced tweakable buttons?

1. Make crossfeed enabled by default in radial decouplers

2. Make fairing truss and additional nodes default to off

 

A possibly more complex one - I've been using a patch to give kerbals a simple low-power EVA transmitter that can relay through a nearby ship:

Which necessarily adds a battery to the EVA suit.  Combined with EVAFuel, it's a little more challenge and realism.  I'd like to add electric power draw for the EVA helmet lights too.  Could this be as simple as the electric power draw cfg for command pods, once the suit is modded to have electricity?

[samamstar]

Came up with another patch, this one adds new adapters filled with fuel:

//this adds new fuel filled adapters for ksp. should be decently balanced

//new 1.25 to 0.625 fueled adapter
+PART[adapterSmallMiniTall]:FINAL
{
	@name = adapterSmallMiniTallFueled
	@TechRequired = advFuelSystems
	@entryCost = 3000
	@cost = 200
	@category = FuelTank
	@title = FL-A10 Fuel Tank
	@description = We had some engineers installing a FL-A10 adapter when they came to the sudden realization that we were packing all that extra empty space for no reason!
	@mass = 0.70
	RESOURCE
	{
		name = LiquidFuel
		amount = 45
		maxAmount = 45
	}
	RESOURCE
	{
		name = Oxidizer
		amount = 55
		maxAmount = 55
	}
}

//2.5 meter adapter fuel tank
+PART[largeAdapter]:FINAL
{
	@name = largeAdapterFueled
	@TechRequired = advFuelSystems
	@entryCost = 7000
	@cost = 3500
	@category = FuelTank
	@title = Rockomax Brand Adapter
	@manufacturer = Rockomax Conglomerate
	@description =  When C7 designed an adapter for rockomax rocketry parts we immediately took legal action against them, but it is aparently perfectly legal to design periferals for someone else's product. So we beat them at their own game.
	@mass = 0.5
	RESOURCE
	{
		name = LiquidFuel
		amount = 360
		maxAmount = 360
	}
	RESOURCE
	{
		name = Oxidizer
		amount = 440
		maxAmount = 440
	}
}

//3.75 meter adapter fuel tank
+PART[Size3to2Adapter]:FINAL
{
	@name = Size3to2AdapterFueled
	@TechRequired = highPerformanceFuelSystems
	@entryCost = 10000
	@cost = 2750
	@category = FuelTank
	@title = Kerbodyne ADTP-2-3 Fuel Tank
	@manufacturer = Kerbodyne
	@description =  After Jeb's junkyard filled the FL-A10 adapter with fuel, some eggheads at kerbodyne came up with a great idea! Fill our adapter with fuel!
	@mass = 1.75
	RESOURCE
	{
		name = LiquidFuel
		amount = 1296
		maxAmount = 1296
	}
	RESOURCE
	{
		name = Oxidizer
		amount = 1584
		maxAmount = 1584
	}
}

the highlighting makes it look like there is a giant string, but module manager doesn't recognize that in  it's syntax

Edited November 13, 2016 by samamstar

[Red Shirt]

deleted

Edited December 4, 2016 by Red Shirt

[Jarin]

Is it possible to patch in a staging toggle for launch clamps? I'm using them for support legs on bases built with Extraplanetary Launchpads, and would like to avoid fumblefinger staging my bases into the ground.

Even better would be if this could be toggled post-launch in the flight scene.

Edited December 15, 2016 by Jarin

[TranceaddicT]

On 10/21/2016 at 4:45 AM, Enceos said:

I also have a config for a delayed retro booster:

I'm having a problem with this config.  I keep getting the log error:

[ERR 04:34:16.345] Cannot find a PartModule of typename 'ModuleSRBThrust'

Cannot find any reference or documentation to ModuleSRBThrust.

Ideas?

 

[Enceos]

@TranceaddicT I see the problem, I accidentally pasted an old patch for the SRB Thrust Control mod.

Here's the stock patch:

+PART[sepMotor1]:Final
{
	@name = delayedRetro    
	@title = Sepratron I-D
	@description = Same as the Sepratron I but with a delayed fuse.
	@MODULE[ModuleEngine*]
	{
		%useThrustCurve = true
		%thrustCurve
		{
			key = 0.00 0.01
			key = 0.05 1.00 0 0
			key = 0.93 1.00 0 0
			key = 0.98 0.10 0 0
			key = 1.00 0.10
		}
	}
}

@Alshain would you please update it in the OP.

[TranceaddicT]

@Enceos

Thanks for that.  That's what I was thinking; went nuts trying to find something about ModuleSRBthrust.  

I even installed Unity and downloaded the FloatCurve editor 1.0 by @r4m0n

At least after all that, I've learned more than enough about all the various floatCurves.  

[Enceos]

@TranceaddicT There's actually an ingame curve editor made by sarbian https://ksp.sarbian.com/jenkins/job/AmazingCurveEditor/10/artifact/AmazingCurveEditor-1.1.1.0.zip

Curves are awesome, my shuttle ascends on SRBs just the right way and the Soyuz rocket has differently timed sepratrons just like the real one (except the upper sepratron is not a sepratron IRL).

Edited December 20, 2016 by Enceos

[TranceaddicT]

ACE:  The only draw back to this is that it does not modify the floatCurve of a part.  I've confirmed with @sarbian that is is meant as an in-game version of FloatCurve editor 1.0.  It doesn't actually implement any changes to a part.

delayedSepratron:  I was really looking for a possible solution to an 'real' delay.  Unfortunately, thrustCurve does not allow for this possibility.  Fortunately, I found [1.0.4] Smart Parts v1.6.6 for exactly what I want ... a true firing delay of 1s.