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

[Alewx]

Why is this topic not sticky?

Here are some really great simple improvements.

[redmonddkgamer]

Dear gods, that is a lot of patches.

[KerbMav]

1 hour ago, redmonddkgamer said:

Dear gods, that is a lot of patches.

Hah! Cute ...

[redmonddkgamer]

29 minutes ago, KerbMav said:

Hah! Cute ...

How many mods? Like a hundred?

[KerbMav]

15 minutes ago, redmonddkgamer said:

How many mods? Like a hundred?

About 90 and a folder with my own patches.

[redmonddkgamer]

26 minutes ago, KerbMav said:

About 90 and a folder with my own patches.

Try to get that to a hundred and tank your PC.

[Gordon Dry]

4 hours ago, redmonddkgamer said:

Dear gods, that is a lot of patches.

? It already reached the letter P and still below 10000

[monstah]

(Actually, I've tested and it doesn't work as advertised. Let me rethink this and I might come back)

New one inspired by this exchange (thanks @liquidhype):

@PART[*]:HAS[@MODULE[ModuleEngineFX]]{
    @MODULE[ModuleEngineFX]{
        useEngineResponseTime = True
        engineAccelerationSpeed = 1.65
        engineDecelerationSpeed = 1.90
    }
}

(BTW, Ruby and CSS make good highlighters for CFG syntax!)

Makes rocket engines take time spooling.

 

Edited August 12, 2017 by monstah

[liquidhype]

Just now, monstah said:

New one inspired by this exchange (thanks @liquidhype):

@PART[*]:HAS[@MODULE[ModuleEngineFX]]{
    @MODULE[ModuleEngineFX]{
        useEngineResponseTime = True
        engineAccelerationSpeed = 1.65
        engineDecelerationSpeed = 1.90
    }
}

(BTW, Ruby and CSS make good highlighters for CFG syntax!)

Makes rocket engines take time spooling.

For anyone wanting to use  this, I recommend messing around with "engineAccelerationSpeed" and "engineDecelerationSpeed" values. Obviously the lower the number the more time it takes for the engine to spool up/down and vice versa. 1.65 for AccelerationSpeed and 1.90 for DecelerationSpeed might not give you exactly what you want. Realisticly some engines would have a much, much lower number than 1.65 for AccelereationSpeed. Real-world examples for low to semi-low AccelerationSpeed would be RD-107A/108A, RS-68A, RS-25, RD-170/171 etc.

[Drew Kerman]

On 8/4/2017 at 9:53 AM, redmonddkgamer said:

Dear gods, that is a lot of patches.

22 hours ago, KerbMav said:

Hah! Cute ...

Sorry, but you're all waaay behind. My record stands at 98,373. I haven't done a Full Load with v1.2.2 but I will do one eventually with v1.3 when I get there in a few weeks and I'm hoping to finally break 100k

[KerbMav]

It always bugged me that rover wheels were so high up (right) in the tech tree.

For Kerbin surface exploration around the KSC there should be a good old combustion engine, so I kind of made one.

The LqFuel+Air(Oxygen) powered wheel becomes available with aviation, just in time for the needed air intakes - as well as in the same tech node most players will start building jet cars on landing gears, so quite fitting I think.

+PART[wheelMed]
{
	@name = wheelMedFuel
	@TechRequired = aviation
	@entryCost = 2000
	@cost = 200
	@title = Combustion Ruggedized Wheel
	@description = An extremely tough wheel made for mobilizing medium sized vehicles across a large variety of terrain. Will need air intakes to feed the motor oxygen for fuel combustion.
	@mass = 0.3
	@maxTemp = 800
	
	@MODULE[ModuleWheelMotor]
	{
		@wheelSpeedMax = 59 // kph
		@driveResponse = 2
				
		RESOURCE
		{
			name = LiquidFuel
			rate = 0.01
		}
		
		RESOURCE
		{
			name = IntakeAir
			rate = 0.1
		}
		
		@idleDrain = 0.0
		
		-RESOURCE[ElectricCharge] {}
		
	}
	
	-MODULE[ModuleTestSubject]{}

}

@PART[wheelMedFuel]:NEEDS[WheelSounds]
{
	MODULE
	{
		name = WheelSounds
		wheelSoundVolume = 1.5
		wheelSoundPitch = 0.5
		wheelSoundFile = WheelSounds/Sounds/RoveMaxXL3
		skidSoundVolume = 0.2
		skidSoundPitch = 1
		skidSoundFile = WheelSounds/Sounds/gravelSkid
		damageSoundVolume = 1
		damageSoundFile = WheelSounds/Sounds/wheelDamage
		soundInVacuum = false
	}
}

@PART[*]:HAS[@MODULE[WheelSounds],!@MODULE[ModuleWheelMotorSteering]]:NEEDS[WheelSounds]:FINAL
{
    @MODULE[WheelSounds]
    {
        skidSoundVolume = 0.3
		soundInVacuum = true
    }
}

Comes with a paragraph to integrate WheelSounds, not really part of a stock patch, feel free to just toss it out.

[Tyko]

I've written a set of PartUpgrades for all stock engines and those that come with Vens Stock Revamp. I was looking for something that wasn't OP, but reflected reasonable improvements in engine technology. Here's how it works...each engine will get several upgrades to Thrust and to ISP in several steps after the engine is first unlocked.

• Thrust goes up to 110% and then to 120%.
• ISP goes up to 105% and then to 110%. Vacuum specialized engines actually have minor drops in ASL ISP to reflect the increased specialization.

Vacuum ISPs will max out in the 385 range...I'm not sure if this is "realistic", but since Kerbals never invented HydroLox engines, I figured they worked extra hard on improving their LFO technology.

Sharing this in case anyone else wants to use or create their own upgrades and needs a starting place. 

https://www.dropbox.com/sh/jybl08q8o8eymrs/AADWurnw-GWKCWyg1dbc7_RGa?dl=0

As an added bonus for Ven's users I've included a config for the Thunder engine making it vacuum specialized and a new larger version called Lightning. Use if you'd like or leave out. Just keep in mind that the upgrade values for the Thunder are tied to the Thrust and ISP numbers i built into my Thunder mod, so you'll have to tweak the upgrade numbers if you use Ven's standard Thunder stats. I did this because I love Ven's model, but thought it needed a better niche to serve and they fill in the gaps nicely amongst the stock vacuum engines.

 

[Snark]

So, the extremely overweight mass for the Mk1-2 command pod and the Mk2 lander can has long bugged me (along with a lot of other folks).

For a long time, I was just using a ModuleManager patch to simply lower their masses outright-- pretty much along the lines of the patch to that effect that's already there in the OP of this thread.  Recently, however, I've tried getting a little fancier with it:

https://github.com/KSPSnark/SnarkTweaks/blob/master/stock/UpgradeHeavyCrewPods.cfg

This is a MM patch that leaves their mass alone, at the default (overweight) stock value... until you unlock the Composites node on the tech tree, and then there's an upgrade available that lowers their mass to pretty close to the values already proposed in the OP of this thread.

Seems to work pretty well (this is the first time I've tried tinkering with the "upgrade" mechanic in KSP).  One annoyance I note is that when you look at the part in the parts tab of the vehicle editor, it does say "upgrades applied!" ... but it's still showing the original, unmodified mass in the description.  Just a minor wart, though-- the actual part has the correct (upgraded) mass, once the upgrade is applied.

Anyway, there it is, for anyone who might enjoy. 

[Wyzard]

Here's a slight adjustment to my earlier patch for allowing science transfers on all parts:

// Add in-vessel transfer support to all parts that can hold science, unless
// explicitly disabled by the part.  This is the same ability that the stock
// Experiment Storage Unit has; it doesn't really make sense for it to be
// limited to just the that part.
// Author: Wyzard
@PART[*]:HAS[@MODULE[ModuleScienceContainer],!MODULE[KerbalEVA]]
{
	// Allow "Container: Collect All" and "Container: Transfer Data" by
	// default.
	@MODULE[ModuleScienceContainer]:HAS[~canTransferInVessel[]]
	{
		canTransferInVessel = True
	}

	// Allow targeting by "Container: Transfer Data" on other parts by
	// default.
	@MODULE[ModuleScienceContainer]:HAS[~canBeTransferredToInVessel[]]
	{
		canBeTransferredToInVessel = True
	}
}

The only difference is that KerbalEVA is excluded from the patch, because kerbal spacesuits are never connected to other parts so it's useless to have science transfer buttons on a kerbal.

Edited September 9, 2017 by Wyzard
Corrected to ACTUALLY exclude EVA kerbals, because apparently I fail at basic testing.

[aquilux]

Is there a way to do math to a value for one line, using input from another? I was wondering if it was possible to enable engine spooling for all engines that do not have it, and set the spool time according to each engine's mass.

[Aelfhe1m]

9 hours ago, aquilux said:

Is there a way to do math to a value for one line, using input from another? I was wondering if it was possible to enable engine spooling for all engines that do not have it, and set the spool time according to each engine's mass.

Yes, MM has a variables syntax and can do simple arithmetic on values. For your example (you'll need to experiment to find the right multipliers):

Spoiler

@PART[*]:HAS[@MODULE[ModuleEnginesFX]:HAS[~useEngineResponseTime[True]]]
{
	@MODULE[ModuleEnginesFX]
	{
		engineAccelerationSpeed = #$/mass$ // initially set it equal to mass$
		@engineAccelerationSpeed *= 1.5 // modify by multiplying value by 1.5
		
		engineDecelerationSpeed = #$/mass$
		@engineDecelerationSpeed /= 2 // divide by two (you could also just multiply by 0.5)
        
        // other operators are += for add -= for subtract and |= for raise to the power of (e.g. square)
		
		useEngineResponseTime = True
	}
}

@PART[Size2LFB] // twin boar should be handled as a separate case since its mass includes a fuel tank
{
	// ???
}

After loading the game you can look in GameData/ModuleManager.ConfigCache to see what values were assigned. Any syntax errors will be written to the log.

Edited September 18, 2017 by Aelfhe1m

[aquilux]

17 hours ago, Aelfhe1m said:

Yes, MM has a variables syntax and can do simple arithmetic on values. For your example (you'll need to experiment to find the right multipliers):

  Hide contents

@PART[*]:HAS[@MODULE[ModuleEnginesFX]:HAS[~useEngineResponseTime[True]]]
{
	@MODULE[ModuleEnginesFX]
	{
		engineAccelerationSpeed = #$/mass$ // initially set it equal to mass$
		@engineAccelerationSpeed *= 1.5 // modify by multiplying value by 1.5
		
		engineDecelerationSpeed = #$/mass$
		@engineDecelerationSpeed /= 2 // divide by two (you could also just multiply by 0.5)
        
        // other operators are += for add -= for subtract and |= for raise to the power of (e.g. square)
		
		useEngineResponseTime = True
	}
}

@PART[Size2LFB] // twin boar should be handled as a separate case since its mass includes a fuel tank
{
	// ???
}

After loading the game you can look in GameData/ModuleManager.ConfigCache to see what values were assigned. Any syntax errors will be written to the log.

This looks great, I'll start playing around with it. Just two quick things. First, the engine masses listed appear to be the dry mass, so that simplifies things. Second, the tilde in:

HAS[~useEngineResponseTime[True]]

Is it to get the inverse result (returning true if following argument returns as anything other than true)? I can't seem to find the tilde in the syntax documentation.

 

Edit: upon further thought... If we REALLY want to take into account tankage on engines we could find the dry mass to liquid volume ratio commonly used, derive the tankage weight based off of contained liquid, and subtract that from the part's dry mass before doing the engine spooling calculations, but I imagine that might be a bit much.

Edited September 19, 2017 by aquilux

[Aelfhe1m]

35 minutes ago, aquilux said:

Second, the tilde in:

HAS[~useEngineResponseTime[True]]

Is it to get the inverse result (returning true if following argument returns as anything other than true)? I can't seem to find the tilde in the syntax documentation.

Yes, it's documented on the MM wiki at: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Handbook

Quote

• # for including keys in filter
• ~ for excluding keys from filter

 

As for tankage, most engines do not include any integrated tankage and you can't write a MM patch that will get a part to change it's behaviour depending on what it's attached to. So to be consistent you would probably want any calculated value to try to be based on just the mass of the engine not any other "frills" that might be included in the same part model - but it's your patch so whatever feels best/most balanced to you. 

[aquilux]

I've been reading through the documentation, and I had another question. Is there an OR operator for the search, or do we have to make a second copy of the patch?

[aquilux]

So, I seem to have it working, though it appears as though it's adding response time to solid fuel engines despite the addition of the requirement for oxidiser as a propellant. I'm trying to figure out what I did wrong, and if I can get it to check for oxidiser OR monopropellant. I know OR involves the | symbol, I just don't know how to incorporate it into the search. Here is what I have (ps: notepad++ is boss for catching nesting errors before you get syntax exceptions).

//Add engine response time to all instant response engines based on part mass.
//Author: Aelfhe1m, Aquilux
@PART[*]:HAS[@MODULE[ModuleEnginesFX]]:HAS[PROPELLANT[Oxidizer]]:HAS[~useEngineResponseTime[True]]
//find parts containing ModuleEnginesFX that uses Oxidiser, but does not have useEngineResponseTime
{
	@MODULE[ModuleEnginesFX]
	{
		engineAccelerationSpeed = #$/mass$ //edit or create engineAccelerationSpeed, initially set it equal to mass$
		@engineAccelerationSpeed *= 1.3333 // modify by multiplying value using KW values for ratio
		
		engineDecelerationSpeed = #$/mass$
		@engineDecelerationSpeed *= 1.4333 // modify by KW ratio
        
        // other operators are += for add -= for subtract and |= for raise to the power of (e.g. square)
		
		useEngineResponseTime = True //edit or create useEngineResponseTime, may exist set to false, set true
	}
}

 

[Aelfhe1m]

@aquilux Most of the Squad SRBs already have a built in (fast) response time so make sure you're not seeing their default values.

Second to test for PROPELLANT you need to use @ because it's a node (or use ! for not and test against solid fuel).

Third - nesting of has clauses is significant - you want the 2nd and third clauses to apply to the module so they need to be inside the first has clause's closing brackets.

Fourth - I just realised that not all the Squad engines use ModuleEnginesFX (e.g. LV-T45) so the module name will need to be wildcarded.

Spoiler

//Add engine response time to all instant response engines based on part mass.
//Author: Aelfhe1m, Aquilux
@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[SolidFuel],~useEngineResponseTime[True]]]
//find parts containing ModuleEnginesFX that does not use solidfuel and does not have useEngineResponseTime
{
	@MODULE[ModuleEngines*]
	{
		engineAccelerationSpeed = #$/mass$ //edit or create engineAccelerationSpeed, initially set it equal to mass$
		@engineAccelerationSpeed *= 1.3333 // modify by multiplying value using KW values for ratio
		
		engineDecelerationSpeed = #$/mass$
		@engineDecelerationSpeed *= 1.4333 // modify by KW ratio
        
        // other operators are += for add -= for subtract and |= for raise to the power of (e.g. square)
		
		%useEngineResponseTime = True //edit or create useEngineResponseTime, may exist set to false, set true
	}
}
 

 

Oh and finally note that higher values of acceleration/deceleration speed make the engines spool faster (they go from no thrust to full thrust quicker). Not sure if this is your intent but it means heavier engines will respond quicker using the current values.

Edited September 19, 2017 by Aelfhe1m

[aquilux]

6 minutes ago, Aelfhe1m said:

@aquilux Most of the Squad SRBs already have a built in (fast) response time so make sure you're not seeing their default values.

Second to test for PROPELLANT you need to use @ because it's a node (or use ! for not and test against solid fuel).

Third - nesting of has clauses is significant - you want the 2nd and third clauses to apply to the module so they need to be inside the first has clause's closing brackets.

And finally I just realised that not all the Squad engines use ModuleEnginesFX (e.g. LV-T45) so the module name will need to be wildcarded.

  Hide contents

//Add engine response time to all instant response engines based on part mass.
//Author: Aelfhe1m, Aquilux
@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[!PROPELLANT[SolidFuel],~useEngineResponseTime[True]]]
//find parts containing ModuleEnginesFX that uses Oxidiser, but does not have useEngineResponseTime
{
	@MODULE[ModuleEngines*]
	{
		engineAccelerationSpeed = #$/mass$ //edit or create engineAccelerationSpeed, initially set it equal to mass$
		@engineAccelerationSpeed *= 1.3333 // modify by multiplying value using KW values for ratio
		
		engineDecelerationSpeed = #$/mass$
		@engineDecelerationSpeed *= 1.4333 // modify by KW ratio
        
        // other operators are += for add -= for subtract and |= for raise to the power of (e.g. square)
		
		%useEngineResponseTime = True //edit or create useEngineResponseTime, may exist set to false, set true
	}
}
 

 

 

The ModuleEnginesFX issue occured to me as well, but if we also test for ModuleEngines wouldn't we need to detect which one is being used, and change our package accordingly? I was just going to perfect the FX version, then copy it for the sans-FX version.

Edit: I'm testing the code now with an absurd delay, I'll see if this patch is catching the solids, though I do have hybrid engines (Solid Fuel+Oxidiser), and figured they'd need spool up times as well.

Edited September 19, 2017 by aquilux

[Aelfhe1m]

1 minute ago, aquilux said:

The ModuleEnginesFX issue occured to me as well, but if we also test for ModuleEngines wouldn't we need to detect which one is being used, and change our package accordingly? I was just going to perfect the FX version, then copy it for the sans-FX version.

I think both ModuleEngines and ModuleEnginesFX behave the same for engine spooling so it shouldn't matter.

[aquilux]

1 minute ago, Aelfhe1m said:

I think both ModuleEngines and ModuleEnginesFX behave the same for engine spooling so it shouldn't matter.

But once we find the .cfg we want to edit with the search section, aren't we then telling it which module to modify? What happens if it finds a part without the *FX module, then tries to modify the nonexistant module?

[Aelfhe1m]

8 minutes ago, aquilux said:

But once we find the .cfg we want to edit with the search section, aren't we then telling it which module to modify? What happens if it finds a part without the *FX module, then tries to modify the nonexistant module?

That's why I put a wild card in the edit part as well.