Jump to content

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

Alshain

By Alshain
in KSP1 Mod Releases

 Share

Recommended Posts

Alshain

Alshain

Posted
  • Author
Posted (edited)

I agree with @Deddly and prefer it that way, and in fact I wish they would remove a few (for example CKAN, which doesn't even belong in this forum, as it's a Tool or Application but it certainly doesn't need to be stickied)  It just creates a bunch of clutter at the top.  The database of mods is important and should stay, and of course threads from squad and moderators (though logical consolidation of information in some cases might be useful), other than that, the TOTM and that's it.

 

By the way, I'm not ignoring people.  I've been a bit busy but if your patch is posted here, it will make it to the front page eventually.  Fear not!

Edited by Alshain
Link to comment
Share on other sites
  • 4 weeks later...
Murdabenne

Murdabenne

Posted
Posted (edited)
On ‎10‎/‎10‎/‎2017 at 5:36 PM, Alshain said:

I agree with @Deddly and prefer it that way, and in fact I wish they would remove a few (for example CKAN, which doesn't even belong in this forum, as it's a Tool or Application but it certainly doesn't need to be stickied)  It just creates a bunch of clutter at the top.  The database of mods is important and should stay, and of course threads from squad and moderators (though logical consolidation of information in some cases might be useful), other than that, the TOTM and that's it.

 

By the way, I'm not ignoring people.  I've been a bit busy but if your patch is posted here, it will make it to the front page eventually.  Fear not!

I completely disagree with you on that.  A large number of users use CKAN as a primary interface to apps, and its significant enough to where this needs to be stickied.  And it affects so many apps that it needs to be here in the APP RELASE forum so that it can be easily referred to, if for no other reason than to help people stop posting in app threads and instead go to the CKAN thread which is very visible on the front page here.  YMMV. ¯\_(ツ)_/¯

As of now there are approximately 5 stickies, 3 of them locked. that's manageable, unlike the wall of stickies on the development forum. :o

 

By the way, I love this combined with LGG's managemnt mod - there has been a screaming need for something to manage MM scripts now that you have them organized. Thanks for taking the time, thought and effort to give us a database, so that someone could come up with tool to do so. 
 

 

Edited by Murdabenne
typos as usual, accidental CAPS LOCK
Link to comment
Share on other sites
fourfa

fourfa

Posted
Posted

Question, re something that's been in the back of my head for a while.  I'm interested in making command module life support a bit more complex and quasi-real, but without creating new resources to micromanage all the time.  For instance, I found Kerbalism too fussy and frustrating (I use USI-LS sometimes too, but not always).  I'm looking for something so simple it can be done with just a MM patch; not Realism Overhaul, more like a head-fake in the right direction with minimal changes to balance and gameplay.  Just spitballing so far, interested in people's thoughts.

Thing one: heat.  Command modules should generate heat at a certain rate, multiplied by the number of seats.  Perhaps such that let's say a simple early Mk1 pod orbiter will equilibriate at a safe temp in LKO, but a MK1-2 CSM will get dangerously hot without a radiator.

Thing two: power.  Tied to above, command pods should draw power at all times.  Not sure it has to be completely adiabatically balanced with the heat output, but just a nominal draw so mission planning takes a bit more care.

I figure this will take a bunch of tweaking to get right, which I'm looking forward to playing with if someone is interested in pointing the way forward with the necessary code.  And I know this might be a lot more complex than I think it is - having just looked through the stock RTG .cfg there are a lot of tweakables available.

Link to comment
Share on other sites
MatterBeam

MatterBeam

Posted
Posted
19 hours ago, fourfa said:

Question, re something that's been in the back of my head for a while.  I'm interested in making command module life support a bit more complex and quasi-real, but without creating new resources to micromanage all the time.  For instance, I found Kerbalism too fussy and frustrating (I use USI-LS sometimes too, but not always).  I'm looking for something so simple it can be done with just a MM patch; not Realism Overhaul, more like a head-fake in the right direction with minimal changes to balance and gameplay.  Just spitballing so far, interested in people's thoughts.

Thing one: heat.  Command modules should generate heat at a certain rate, multiplied by the number of seats.  Perhaps such that let's say a simple early Mk1 pod orbiter will equilibriate at a safe temp in LKO, but a MK1-2 CSM will get dangerously hot without a radiator.

Thing two: power.  Tied to above, command pods should draw power at all times.  Not sure it has to be completely adiabatically balanced with the heat output, but just a nominal draw so mission planning takes a bit more care.

I figure this will take a bunch of tweaking to get right, which I'm looking forward to playing with if someone is interested in pointing the way forward with the necessary code.  And I know this might be a lot more complex than I think it is - having just looked through the stock RTG .cfg there are a lot of tweakables available.

This should be in Mod development, but here's my suggestion:

Use the USI-LS mod files. Go to the converter that consumes Supplies and produces Mulch, and add heat generation to it, just like the ISRU part does. 

Then, add to all command pods a generator that consumes electricity, produces heat but has no 'output'.

If you want to use your own heating system instead of the stock heat generation mechanics, add a weightless resource called HEAT and create generators that produce it as an output resource. 

Link to comment
Share on other sites
  • 2 weeks later...
  • 1 month later...
canisin

canisin

Posted
Posted

Hello there, I dont know what has changed but it seems that the module manager syntax for experiment definitions has changed. The patch presented here to swap the biome maks for eva and crew reports no longer work. Currently the working syntax seems to be as follows: 

@EXPERIMENT_DEFINITION:HAS[#id[crewReport]]:FINAL
{
    @situationMask = 63 //stock: 63
    @biomeMask = 23 //stock: 7, space near is now biome specific
}

@EXPERIMENT_DEFINITION:HAS[#id[evaReport]]:FINAL
{
    @situationMask = 51 //stock: 63, removed flight
    @biomeMask = 3 //stock: 23, space near is now global
}

This one is slightly different than the one in the OP, as explained in the comments this also removes in flight eva reports as I find hanging to an airplane in an atmosphere does not make much sense :)
 

Link to comment
Share on other sites
Stratickus

Stratickus

Posted
Posted
On 7/31/2017 at 9:04 PM, theshepherd said:

Here's my go at adding some additional love for Pilots.  This will decrease fuel usage with more experience.  I have tested that the extra delta-V does not show up on KER or MJ, so you will have to do the maths in your head, etc....  So without affecting Thrust or Specific Impulse, this reduces the fuel flow and increases delta-v by up to 15% for fully experienced pilots. 


// Give pilots fuel efficency as a skill
// Author: theshepherd
@EXPERIENCE_TRAIT[Pilot]:Needs[SQUAD]:Final
{
	%EFFECT[FuelUsage]
	{
		%modifiers = 0.99, 0.97, 0.94, 0.90, 0.85
	}	
}

It seems balanced but if you think it is OP, adjust the numbers accordingly.

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,

Link to comment
Share on other sites
  • 2 weeks later...
Errol

Errol

Posted
Posted (edited)
On 17/05/2016 at 1:34 PM, Alshain said:

 

Add Engine Spool Delay
Contributor:  @Aelfhe1m, @aquilux

  Hide contents 


//Add engine response time to engines that pump fluids but have no engine spooling.
//Author: Aelfhe1m & Aquilux
////////////////////////////////////////////////////////////////////
//This script adds engine spooling delay to engines that pump at least one liquid for a chemical reaction.
//Engine spooling delay is dependent on the momentum of the turbines in the engine.
//This script assumes that turbine mass is an average fraction of engine mass, thus delay is derived from engine mass.
//
//equations for accel/decel/mass relationships loosely derived from KW rocketry values:
//
//engineAccelerationSpeed = -1.16878m + 0.0875252m^2 + -0.00253789m^3 + 0.0000260111m^4 + 5.74868
//
//engineDecelerationSpeed = 1.14632m + 0.0856818m^2 + -0.00246803m^3 + 0.0000251029m^4 +  5.82994
//
//values and derived trend lines can be found here: https://goo.gl/733mKw (published google sheets chart)
//////////////////////////////////////////////////////////////////


//Spooling for engines with oxidiser (to account for hybrid and other exotic chemical engines using oxidiser)
@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],~useEngineResponseTime[True]]]
//find parts containing ModuleEngines* that uses Oxidiser, but does not have useEngineResponseTime
{
	@MODULE[ModuleEngines*]
	{
		useEngineResponseTime = True 			//create useEngineResponseTime

//////////////////////////////////////////////////begin polynomial math for engineAccelerationSpeed
		MATHa = #$/mass$ 						//start first component temp variable
		@MATHa *= -1.16878		 				//complete first component
												//
		MATHb = #$/mass$						//start second component temp variable
		@MATHb != 2								//incorporate exponent
		@MATHb *= 0.0875252						//complete second component
												//
		MATHc = #$/mass$						//start third component temp variable
		@MATHc != 3								//incorporate exponent
		@MATHc *= -0.00253789					//complete third component
												//
		MATHd = #$/mass$						//start fourth component
		@MATHd != 4								//incorporate exponent
		@MATHd *= 0.0000260111					//complete fourth component
												//
		engineAccelerationSpeed = #$MATHa$		//combine first component
		@engineAccelerationSpeed += #$MATHb$	//combine second component
		@engineAccelerationSpeed += #$MATHc$	//combine third component
		@engineAccelerationSpeed += #$MATHd$	//combine fourth component
		@engineAccelerationSpeed += 5.74868		//combine fifth component 
												//keep variables initialised
//////////////////////////////////////////////////begin polynomial math for engineDecelerationSpeed
		@MATHa = #$/mass$ 						//start first component temp variable
		@MATHa *= 1.14632		 				//complete first component
												//
		@MATHb = #$/mass$						//start second component temp variable
		@MATHb != 2								//incorporate exponent
		@MATHb *= 0.0856818						//complete second component
												//
		@MATHc = #$/mass$						//start third component temp variable
		@MATHc != 3								//incorporate exponent
		@MATHc *= -0.00246803					//complete third component
												//
		@MATHd = #$/mass$						//start fourth component
		@MATHd != 4								//incorporate exponent
		@MATHd *= 0.0000251029					//complete fourth component
												//
		engineDecelerationSpeed = #$MATHa$		//combine first component
		@engineDecelerationSpeed += #$MATHb$	//combine second component
		@engineDecelerationSpeed += #$MATHc$	//combine third component
		@engineDecelerationSpeed += #$MATHd$	//combine fourth component
		@engineDecelerationSpeed += 5.82994		//combine fifth component
												//
		!MATHa = clear							//clear temp variable
		!MATHb = clear							//clear temp variable
		!MATHc = clear							//clear temp variable
		!MATHd = clear							//clear temp variable
//////////////////////////////////////////////////end polynomial math
	}
}

//Spooling for engines with MonoPropellant
@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[MonoPropellant],~useEngineResponseTime[True]]]
//find parts containing ModuleEngines* that uses MonoPropellant, but does not have useEngineResponseTime
{
	@MODULE[ModuleEngines*]
	{
		useEngineResponseTime = True 			//create useEngineResponseTime
		
//////////////////////////////////////////////////begin polynomial math for engineAccelerationSpeed
		MATHa = #$/mass$ 						//start first component temp variable
		@MATHa *= -1.16878		 				//complete first component
												//
		MATHb = #$/mass$						//start second component temp variable
		@MATHb != 2								//incorporate exponent
		@MATHb *= 0.0875252						//complete second component
												//
		MATHc = #$/mass$						//start third component temp variable
		@MATHc != 3								//incorporate exponent
		@MATHc *= -0.00253789					//complete third component
												//
		MATHd = #$/mass$						//start fourth component
		@MATHd != 4								//incorporate exponent
		@MATHd *= 0.0000260111					//complete fourth component
												//
		engineAccelerationSpeed = #$MATHa$		//combine first component
		@engineAccelerationSpeed += #$MATHb$	//combine second component
		@engineAccelerationSpeed += #$MATHc$	//combine third component
		@engineAccelerationSpeed += #$MATHd$	//combine fourth component
		@engineAccelerationSpeed += 5.74868		//combine fifth component 
												//keep variables initialised
//////////////////////////////////////////////////begin polynomial math for engineDecelerationSpeed
		@MATHa = #$/mass$ 						//start first component temp variable
		@MATHa *= 1.14632		 				//complete first component
												//
		@MATHb = #$/mass$						//start second component temp variable
		@MATHb != 2								//incorporate exponent
		@MATHb *= 0.0856818						//complete second component
												//
		@MATHc = #$/mass$						//start third component temp variable
		@MATHc != 3								//incorporate exponent
		@MATHc *= -0.00246803					//complete third component
												//
		@MATHd = #$/mass$						//start fourth component
		@MATHd != 4								//incorporate exponent
		@MATHd *= 0.0000251029					//complete fourth component
												//
		engineDecelerationSpeed = #$MATHa$		//combine first component
		@engineDecelerationSpeed += #$MATHb$	//combine second component
		@engineDecelerationSpeed += #$MATHc$	//combine third component
		@engineDecelerationSpeed += #$MATHd$	//combine fourth component
		@engineDecelerationSpeed += 5.82994		//combine fifth component
												//
		!MATHa = clear							//clear temp variable
		!MATHb = clear							//clear temp variable
		!MATHc = clear							//clear temp variable
		!MATHd = clear							//clear temp variable
//////////////////////////////////////////////////end polynomial math
	}
}

 

 

I have found a bug with this code and the RAPIER engine. It seems that this code stops the air-breathing mode from spooling up at all (engine will be "running" but producing no thrust, and 0% propellant requirement). I am not black belt with mm-fu by any means, but after a full day of tracking this bug down (I have many other mods that tweak the RAPIERS, so finding it was a needle in a haystack of mod compatibility  questions) I have hacked a simple solution together:

Change the first actual line of code after the comments from this: 

@PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],~useEngineResponseTime[True]]]

into this:

Spoiler 

@PART[*]:HAS[!MODULE[MultiModeEngine]],:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],~useEngineResponseTime[True]]]

 

Now, the closed cycle mode on the RAPIER engine looses spooling, but I don't know a better way to do this, and in the long run, that is a rather small price to pay, since some of the time that you are using closed cycle mode is when you are just switching from one mode to the other while the engine is running, in which case, I imagine there wouldn't be much spooling so much as a sudden boost in thrust. At least this way most of the engines that should have spooling do.

If anyone else is better with MM and knows how to have the above tweak not apply itself to only the air breathing mode of the RAPIER, that would be better. If not, feel free to use this work-around in your game. 

!!!ATTENTION>> EDIT: I just noticed the first version of my correction broke other air breathing engines (syntax error). Fixed it; use this instead: 

@PART[*]:HAS[!MODULE[MultiModeEngine],@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],~useEngineResponseTime[True]]]

(Ping: @Alshain)

Edited by Errol
fix syntax bug
Link to comment
Share on other sites
fourfa

fourfa

Posted
Posted (edited)

Looking for a little MM syntax help?  I'm using FAR, whose various changes mean I need to override the default parachute settings.  The following had no effect though:

Quote

// Change the default parachute settings for RealChute-Lite included with FAR

@PART[parachuteSingle|parachuteRadial|parachuteLarge]:FINAL
{
    @MODULE[ModuleParachute]
    {
        @minAirPressureToOpen = 0.5
        @deployAltitude = 800
    }
}
@PART[radialDrogue|parachuteDrogue]:FINAL
{
    @MODULE[ModuleParachute]
    {
        @minAirPressureToOpen = 0.25
        @deployAltitude = 2000
    }
}

Any advice?  Thank you

Edited by fourfa
Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted
7 hours ago, fourfa said:

Looking for a little MM syntax help?  I'm using FAR, whose various changes mean I need to override the default parachute settings.  The following had no effect though:

Any advice?  Thank you

First thing is that ModuleParachute is StockKSP.  That module gets deleted by RealChute and replaced by it's own RealChuteModule.  Next, you need to target the actual variables; these too are changed by the mod.  For many mods you need to find the .cfg file that creates the part and dig deeper into the file to find the correct names for the modules and variables.   The file you would need to view is: /../GameData/RealChute/ModuleManager/Stock_RealChute_MM.cfg

That said, try this:

 

// Change the default parachute settings for RealChute-Lite included with FAR

@PART[parachuteSingle|parachuteRadial|parachuteLarge]:FINAL
{
    @MODULE[RealChuteModule]
    {
        @minPressure = 0.5
        @deploymentAlt = 800
    }
}
@PART[radialDrogue|parachuteDrogue]:FINAL
{
    @MODULE[RealChuteModule]
    {
        @minPressure = 0.25
        @deploymentAlt = 2000
    }
}

Link to comment
Share on other sites
fourfa

fourfa

Posted
Posted
On 1/27/2018 at 9:58 PM, TranceaddicT said:

First thing is that ModuleParachute is StockKSP.  That module gets deleted by RealChute and replaced by it's own RealChuteModule.  Next, you need to target the actual variables; these too are changed by the mod.  For many mods you need to find the .cfg file that creates the part and dig deeper into the file to find the correct names for the modules and variables.   The file you would need to view is: /../GameData/RealChute/ModuleManager/Stock_RealChute_MM.cfg

That said, try this:

Thanks, that did the trick.  Actually it's called RealChuteFAR, as it seems to be a special version of RealChute-Lite written just for FAR.  As such, I assume the following works only for FAR without the full RealChute:

Quote

// Change the default parachute settings for RealChute-Lite included with FAR

@PART[parachuteSingle|parachuteRadial|parachuteLarge]:FINAL
{
    @MODULE[RealChuteFAR]
    {
        @minPressure = 0.5
        @deploymentAlt = 800
    }
}
@PART[radialDrogue|parachuteDrogue]:FINAL
{
    @MODULE[RealChuteFAR]
    {
        @minPressure = 0.25
        @deploymentAlt = 2000
    }
}

 

Link to comment
Share on other sites
canisin

canisin

Posted
Posted

Hi All,

I propose the following change to the Add Angled Docking Ability to Docking Ports patch by  @Psycho_zs:

Instead of  

@PART[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]:FINAL

I suggest 

@PART[*]:HAS[MODULE[ModuleDockingNode]:HAS[#nodeType[size0|size1|size2|size3|size4]]]:FINAL

This filter can handle modded docking ports as long as they are intended to be used as standard/typical docking ports.

Link to comment
Share on other sites
maculator

maculator

Posted
Posted
On 5.2.2018 at 8:36 PM, canisin said:

Hi All,

I propose the following change to the Add Angled Docking Ability to Docking Ports patch by  @Psycho_zs:

Instead of  


@PART[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]:FINAL

I suggest 


@PART[*]:HAS[MODULE[ModuleDockingNode]:HAS[#nodeType[size0|size1|size2|size3|size4]]]:FINAL

This filter can handle modded docking ports as long as they are intended to be used as standard/typical docking ports.

I wouldn't say "instead of".

The second one, after all, is the "dirty" version of doing it. If you want to have support for mods it's the only one of course, but if you know all the parts simply listing them is the nicer solution.

Link to comment
Share on other sites
canisin

canisin

Posted
Posted
17 minutes ago, maculator said:

I wouldn't say "instead of".

The second one, after all, is the "dirty" version of doing it. If you want to have support for mods it's the only one of course, but if you know all the parts simply listing them is the nicer solution.

I think this way it is sort of maintenance free. Usually I prefer dynamic solutions such as these. :)

Link to comment
Share on other sites
Tarheel1999

Tarheel1999

Posted
Posted

 

On 2/5/2018 at 2:36 PM, canisin said:

Hi All,

I propose the following change to the Add Angled Docking Ability to Docking Ports patch by  @Psycho_zs:

Instead of  


@PART[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]:FINAL

I suggest 


@PART[*]:HAS[MODULE[ModuleDockingNode]:HAS[#nodeType[size0|size1|size2|size3|size4]]]:FINAL

This filter can handle modded docking ports as long as they are intended to be used as standard/typical docking ports.

So two things about this. One, your syntax is bad.  You forgot an "@" sign before the MODULE in the HAS block.  Two, you can't use "OR" operators in HAS blocks.  See the post from blowfish below. This means you would need to create a separate patch for each docking port size. I know this because I tried your proposed patch and it didn't work.

 

On 12/31/2017 at 12:55 AM, blowfish said:

@PART[foo|bar] works (and will look for a PART  node with name = foo or name = bar).  | does not work in a :HAS block (only , or & which represent AND will work, and then only separating different conditions, e.g. :HAS[#foo1[bar1],#foo2[bar2]]).  However, you can use any of | & , in a NEEDS block (first is OR, second two are AND, OR binds tighter than AND)

E: clarified about and in a :HAS block

Link to comment
Share on other sites
canisin

canisin

Posted
Posted
19 hours ago, Tarheel1999 said:

 

So two things about this. One, your syntax is bad.  You forgot an "@" sign before the MODULE in the HAS block.  Two, you can't use "OR" operators in HAS blocks.  See the post from blowfish below. This means you would need to create a separate patch for each docking port size. I know this because I tried your proposed patch and it didn't work.

 

Thanks a lot for both corrections! Although, I had included this patch in my current install and it had "seemed" to work. I'll test when I get home and report back as necessary.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...