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

[toric5]

4 minutes ago, JAFO said:

Ahh.. ok.

So far as I'm aware, no stock parts (which is what this thread is limited to) have snap rotation applied.

i know, but i use some mods, some of whitch have angle snap.

[JAFO]

2 minutes ago, toric5 said:

i know, but i use some mods, some of whitch have angle snap.

Fair enough.. then, per Rule 1 in the OP of this thread, the proper place to discuss such patches would be in the relevant thread for that mod.

[OHara]

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).

Spoiler

// Author: OHara
@PART[*]:HAS[@MODULE[ModuleAblator]] {
	// Make the ablation rate depend more strongly on temperature
	@MODULE[ModuleAblator] {
		%lossExp = -25000 // was -7500
		%lossConst = 100  // was 0.1;
		%ablationTempThresh = 1200 // was 500K (redunant to the change above)
	}
	// Reduce the default amount of ablator
	@RESOURCE[Ablator] {
		%amount = #$maxAmount$
		@amount *= 0.2
	}
}

 

 

Edited March 12, 2017 by OHara
match the pyrolysis rate at 2500K, not 2000K

[a__gun]

On 20/02/2017 at 1:53 AM, toric5 said:

i know, but i use some mods, some of whitch have angle snap.

If you are talking about the ports from Konstruction, this will do it:

 

@PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[ModuleWeldablePort]]

[toric5]

Just now, a__gun said:

If you are talking about the ports from Konstruction, this will do it:

 

@PART[*]:HAS[@MODULE[ModuleDockingNode],!MODULE[ModuleWeldablePort]]

there are also docking ports that angle snap in near future construction.

[fourfa]

Is there a way to have Alt-F12 -> Physics -> Aero -> "Display Aero Data in Action Menus" turned on by MM patch?

[Iamsodarncool]

On 11/12/2016 at 6:10 PM, fourfa said:

 

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?

I'm getting "Sorry, we can't show this content because you do not have permission to see it." Can you repost the content? I'd really love to have short range antennas on EVA kerbals.

[Alshain]

I finally found some time to go through this thread and update.  Unless I missed something, everything should be updated to this point.

[QiJian]

Another trque added patch for probes(also command pods) which don't have reactionwheel module.

Difference between this one and @Alshain‘s Add Limited Torque to All Probes :

This patch supports all mods and SAS module is also added.

 

@PART[*]:HAS[@MODULE[ModuleCommand],@MODULE[ModuleSAS],!MODULE[ModuleReactionWheel]]:FINAL
{
	
	MODULE
	{
		name = ModuleReactionWheel
		PitchTorque = 3
		YawTorque = 3
		RollTorque = 3
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.01
		}
	}
}

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[ModuleSAS],!MODULE[ModuleReactionWheel]]:FINAL
{
	MODULE
	{
		 name = ModuleSAS
		SASServiceLevel = 1
	}
	
	MODULE
	{
		name = ModuleReactionWheel
		PitchTorque = 3
		YawTorque = 3
		RollTorque = 3
		RESOURCE
		{
			name = ElectricCharge
			rate = 0.01
		}
	}
}

 

 Ispired by @Alshain‘s Add Limited Torque to All Probes.

[StahnAileron]

I wish I knew about this beforehand (like 12-16 hours ago from this posting...) It would've made my efforts SO much easier.

@Alshain If you interested, you can look at my MM cfg:

It's fairing-related stuff I made independently of your CFGs. Same things, but with annotations and 2 extra features: Max Section Lengths and making sure all nodes are technically hidden (though perhaps unneeded?). Explanations are in the cfg if you care to take a look.

Edited April 6, 2017 by StahnAileron

[slubman]

I want my crewed part to have the lights on by default, and unbound from the light control group. That way, toggling light only work with actual light beams.

Below are the MM cfg I created to achieve this:

// Command pods have lights on by default, and not bound to ActionGroup
// Author: slubman
@PART[*]:HAS[@MODULE[ModuleColorChanger]]:FINAL
{
	@MODULE[ModuleColorChanger]
	{
		%animState = true
		%defaultActionGroup = None
	}
}

// Cockpits and cabins have lights on by default, and not bound to ActionGroup
// Author: slubman
@PART[*Cabin*|*Cockpit*]:HAS[@MODULE[ModuleAnimateGeneric]]:FINAL
{
	@MODULE[ModuleAnimateGeneric]
	{
		%animSwitch = false
		%animTime = 1
		%animSpeed = 1
		%defaultActionGroup = None
	}
}

I also like to have my kerbals have the EVA lights on by default, below is the MM cfg for this:

// Kerbal have lights on when starting EVA
// Author: slubman
@PART[*]:HAS[@MODULE[KerbalEVA]]:FINAL
{
	@MODULE[KerbalEVA]
	{
		%lampOn = true
	}
}

 

Edited April 9, 2017 by slubman
Changed the defaultActionGroup value to remove PartLoader errors

[Psycho_zs]

// More sane weight for structural parts
// Author: Psycho_zs

@PART[structuralIBeam2|structuralIBeam3]
{
    @mass *= 0.5
}

@PART[trussAdapter|trussPiece1x|trussPiece3x]
{
    @mass *= 0.2
}

 

[Drew Kerman]

I'd like some rationale for that patch @Psycho_zs - is this based on your own use of these parts or in comparison to parts of other mods out there?

[Psycho_zs]

Just now, Drew Kerman said:

I'd like some rationale for that patch @Psycho_zs - is this based on your own use of these parts or in comparison to parts of other mods out there?

It is a by eye median between 3 points of reference: actually imagining what those parts would be like IRL, overall weird high density of KSP parts, and weight of Near Future Construction trusses. Those stock trusses are way, way overweight. Just compare them to structural fuselage for example.

[Nicias]

First of all thanks for collecting/creating all of these! Would it be possible to modify the "allow deflating inflatable heatshield" patch to allow deflation by action group?

[Iamsodarncool]

I made a patch that allows you to dim the lights in spaceplane cockpits and cabins.

Spoiler

// Allows setting a maximum brightness value for cabin lights
// Author: Iamsodarncool

@PART[Mark1Cockpit] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[Mark2Cockpit] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[MK1CrewCabin] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[mk2Cockpit_Standard] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[mk2Cockpit_Inline] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[mk2CrewCabin] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[mk3Cockpit_Shuttle] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

@PART[mk3CrewCabin] 
{
    @MODULE[ModuleAnimateGeneric]
    {
        allowDeployLimit = true
        revClampDirection = true
    }
}

Unfortunately, allowDeployLimit is valid only for ModuleAnimateGeneric. ModuleAnimateGeneric is used on the spaceplane parts, but for some reason the rocket parts use ModuleColorChanger. So you can't dim the lights on command pods or the hitchhiker can. Does anyone know a workaround for this? Would it be possible to patch ModuleAnimateGeneric into those parts?

Additionally, does anyone know how to change the name of the tweakable? I'd just rather it say "Light Brightness Limit" rather than "Deploy Limit".

Edited April 12, 2017 by Iamsodarncool

[Alshain]

@Iamsodarncool The reason for the disparity in modules is because the Porkjet models were made with built in animations for turning on and off the cabin lights.  The older command pods have no such animations in the model itself so instead they changed the color of a specific region of the model, otherwise they would have had to re-make the model.  The color changer is much easier for the developer but sadly it is much more limited in capability because AnimateGeneric does so many things.  I had the exact same issues making them consume electricity.

As far as a work around, the only way you could do it is with a dll mod.  The same is true for the name of the Deploy Limiter.

Edited April 11, 2017 by Alshain

[Sonny_Jim]

Is there a patch available that sets the 'Anomaly detection rate' of the advanced probe cores to 100%?

[slubman]

13 hours ago, Sonny_Jim said:

Is there a patch available that sets the 'Anomaly detection rate' of the advanced probe cores to 100%?

Here it is

// Set anomaly detection rate to 100% for high tech probes
// Author: slubman
@PART[probeStackLarge|probeStackSmall]:HAS[@MODULE[ModuleKerbNetAccess]]:FINAL
{
	@MODULE[ModuleKerbNetAccess]
	{
		%AnomalyDetection = 1
	}
}

 

[Sonny_Jim]

Perfect, works like a charm.  Thanks!

[Jarin]

Can you add @TechRequired to module tweaks? I.e. adding "collect science" feature to all command pods, but only once you unlock the tech with the science container.

[Alshain]

17 minutes ago, Jarin said:

Can you add @TechRequired to module tweaks? I.e. adding "collect science" feature to all command pods, but only once you unlock the tech with the science container.

Not exactly that but yes.  From the 1.2 Patch notes

Quote

PartModules now support upgrades. In a MODULE node, add an UPGRADE node. Inside that add one node per techID you wish to provide upgrades, in ascending order. Inside that place keys and nodes you wish to upgrade. e.g. `UPGRADES { basicRocketry { maxThrust = 250 } }` will change maxThrust to 250 once basicRocketry unlocks. Upgrades will never override persistent data. Further, by default they overwrite each other; to make a node apply on a clean slate (so you can, say, add two PROPELLANT nodes and not have them conflict due to the overwrite logic) set `IsExclusiveUpgrade__ = True` in the upgrade's node. That will clear the upgrade state and apply that upgrade fresh. Upgrades are applied only when you add a part to a craft in the VAB/SPH, they don't magically apply in flight. When a part on a craft is upgraded, a new option will appear in the PAW (when in VAB/SPH) where you can view the current stats of all those modules with upgrades.

So to use that in an example

//Add Science Transfer to the Science Lab and Command Pods only after basicRocketry is unlocked
//Author: Alshain01 modified from steve_v
@PART[*]:HAS[@MODULE[ModuleScienceContainer]]:HAS[@MODULE[ModuleScienceLab|ModuleCommand]]
{
	@MODULE[ModuleScienceContainer]
	{
		%UPGRADES{
			basicRocketry{
	      			%canBeTransferredToInVessel = True
	      			%canTransferInVessel = True
	      			%showStatus = True
			}
		}
	}
}

This in theory should do the trick, you didn't say what tech node so I just left it at basicRocketry.  I haven't tested this.

Edited April 15, 2017 by Alshain

[Jarin]

8 minutes ago, Alshain said:

Not exactly that but yes.

Okay, so let me try my hand at this...

Spoiler

//Add Science Transfer to the Science Lab and Command Pods
//Author: steve_v
@PART[*]:HAS[@MODULE[ModuleScienceContainer]]:HAS[@MODULE[ModuleScienceLab|ModuleCommand]]
{
    @MODULE[ModuleScienceContainer]
    {
        @UPGRADES{scienceTech{
            %canBeTransferredToInVessel = True
            %canTransferInVessel = True
            %showStatus = True
        }}
    }
}

Would that do the trick?

 

Edit: Okay, I see. Thanks!

Edited April 15, 2017 by Jarin

[Alshain]

7 minutes ago, Jarin said:

Okay, so let me try my hand at this...

Would that do the trick?

Almost, while you were typing, I made an edit.  But you need to use %UPGRADES which tells MM to edit or create if it does not exist.  In your case you will attempt to edit always, which may fail if it doesn't exist.

 

EDIT: Actually I may be wrong on that, your script may be fine.  It may always exist.  I'm not sure.

Edited April 15, 2017 by Alshain

[Jarin]

So I, uh, borked something (and I didn't even add that new script yet), and now I'm getting over a hundred MM errors on load; looks like a lot of it is in tweakscale, but all I get from the loading screen is error totals. Is there a log to get details of MM load errors somewhere?