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

[eddiew]

Hey peeps,

I have an annoyance that I suspect can be MM'd away very quickly but thus far it has eluded me... wondering if anyone can help?

Basically...

...is clanging my OCD something fierce. I would like the HECS side to line up with the OKTO side. (Obviously turning it in the editor also rotates the control axes, thus not having any use.)

Based on my minuscule understanding of configs, I believe this needs a 0.166666 rotation around the z axis, so I tried this...

@PART[probeCoreHex]
{
	-mesh
	%MODEL
	{
	  %model = Squad/Parts/Command/probeCoreHex/model
	  %position = 0.0, 0.0, 0.0
	  %scale = 1.0, 1.0, 1.0
	  %rotation = 0.0, 0.0, 0.1666666666666666
	}
}

...but it literally does nothing. Not even the wrong thing 

Advice appreciated!

[canisin]

9 hours ago, Tyko said:

I've been trying to add an integral decoupler to the top node of stock fairings so I can use them as interstage fairings without stacking an additional decoupler on top of each. I tried adding the code below to the stock fairings. It kind of works, but the decoupler symbol doesn't show up in my staging diagram, so something is still wrong.

Any advice?

 

MODULE
    {
        name = ModuleDecouple
        ejectionForce = 250
        explosiveNodeID = top
    }

Maybe you need to add something like 'enableStaging = true', but I am really not sure, just guessing.

[Nightside]

12 hours ago, Tyko said:

I've been trying to add an integral decoupler to the top node of stock fairings so I can use them as interstage fairings without stacking an additional decoupler on top of each. I tried adding the code below to the stock fairings. It kind of works, but the decoupler symbol doesn't show up in my staging diagram, so something is still wrong.

Any advice?

 

MODULE
    {
        name = ModuleDecouple
        ejectionForce = 250
        explosiveNodeID = top
    }

I don't think you can have more than one symbol per part. 

You can have more than one stagable action. If you don't want both actions to stage simultaneously, you must deactivate one, stage, activate the remaining action, move the icon back up the staging list, then stage as usual. 

Kind of a pain really, since you probably don't want to separate fairings and eject your payload at the same time.

Check out pods in SSTU mod for example. Many have decouples and chutes in the same part. 

[Aelfhe1m]

11 hours ago, eddiew said:

[snip]

Based on my minuscule understanding of configs, I believe this needs a 0.166666 rotation around the z axis, so I tried this...

...but it literally does nothing. Not even the wrong thing 

Advice appreciated!

The rotation is specified in degrees and you want to rotate around the Y axis in this instance. Try this:

@PART[probeCoreHex]
{
	-mesh
	%MODEL
	{
	  %model = Squad/Parts/Command/probeCoreHex/model
	  %position = 0.0, 0.0, 0.0
	  %scale = 1.0, 1.0, 1.0
	  %rotation = 0, 30, 0
	}
}

 

Edited June 29, 2017 by Aelfhe1m
missing comma

[eddiew]

Nice, thanks @Aelfhe1m   Now I can have 3x rotation symmetry AND bilateral symmetry in the same probe!

[Tyko]

6 hours ago, Aelfhe1m said:

The rotation is specified in degrees and you want to rotate around the Y axis in this instance. Try this:

@PART[probeCoreHex]
{
	-mesh
	%MODEL
	{
	  %model = Squad/Parts/Command/probeCoreHex/model
	  %position = 0.0, 0.0, 0.0
	  %scale = 1.0, 1.0, 1.0
	  %rotation = 0, 30, 0
	}
}

 

When do you use % and when do you use @? They seem partially interchangeable. 

Thx

[Alshain]

Just now, Tyko said:

When do you use % and when do you use @? They seem partially interchangeable. 

Thx

@ replaces the value, but will error out if it does not exists.

% creates or replaces the value.

[Tyko]

Just now, Alshain said:

@ replaces the value, but will error out if it does not exists.

% creates or replaces the value.

Got it. So why ever use @ then?

[Alshain]

Just now, Tyko said:

Got it. So why ever use @ then?

If you are depending on something to be installed (like another mod) which created the value, then @ might be beneficial.

[Snark]

A couple of patches I've recently added to my game:

First, unshrouded heat shields.  I've gradually become more and more disappointed with the shrouds.  I dislike them for several reasons:

• The appearance.  The texture just seems awful to me.  I'm not any sort of texture purist, I usually don't care much about the finer details of textures, and I'm not one of these people who opposes the fairly "junkyard" appearance of the stock parts.  I'm fine with it.  However, the heatshield shrouds are the one exception-- they're so "unfinished" looking that (to me at least) they don't even look like physical objects; they look like a placeholder texture in Blender, or something.  It breaks immersion for me.
• Bugs.  I occasionally get weird effects in game when switching back to a previously saved craft, such that the shroud is either missing, or weirdly displaced radially by a meter or two.  Incredibly off-putting and immersion breaking.
• Bulky and awkward.  They stick out too far, radially.  I just don't like 'em.

I've found myself increasingly taking the trouble to turn them off manually, and then using the translate widget with snap turned off so I can scoot the stuff attached below up just enough to fit snugly on the unshrouded heat shield.  This is incredibly tedious to do every time, so I finally sat down to make a ModuleManager patch to do it for me, by default.  It just turns off the shroud, and then moves the bottom attachment node up by a bit removes the old "direct" node, and moves the "bottom" node to where the "direct" node was located.  Here's what it looks like in the VAB (note that this ship was created without any manual tinkering-- just "add part 1, add part 2, add part 3".

EDIT:  It turns out that the heat shields actually already have a node present to allow this kind of attachment.  There are just two problems.  The first problem is that the "direct" node, intended for attaching without a shroud, is the wrong size:  it's one size too small (at all heatshield sizes), meaning that (I think) it'll be less stiff.  The second is that the darn bottom "shroud" node, which I neither need nor want, keeps getting in the way-- and since it's bigger, it completely visually obscures the "direct" node, making the "direct" node completely undiscoverable (at least by me-- I've been playing KSP since before heat shields were a thing, and had no idea that the "direct" node even existed until @canisin points it out, below.  So I've tweaked the config I originally posted here to do as described above.  Works like a charm!  Thanks, canisin. 

Here's the ModuleManager config to do it.  I've tinkered with the 1.25m, 2.5m, and 3.75m heatshields.  (The 0.625m one doesn't need it, since it doesn't have the shroud to begin with.)

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

@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
    }
}

Note:  One unfortunate playability side effect is that the 2.5m heat shield now has the top and bottom nodes so close together that it's easy to attach things below to the top node, by accident.  I don't like that, but having fiddled with it, I couldn't come up with any placement that both looked good and didn't have this problem.  I haven't found it to be a gameplay problem, but I did have to train myself to be careful when placing a decoupler below it.  For me, it's worth the hassle-- I really can't stand the shroud behavior anymore.  (Caveat no longer relevant, due to tweak as described above.)

 

Anyway, on to the second tweak, which repurposes the Stratus-V Cylindrified Monopropellant Tank as an LFO tank.  A couple of things prompted this.  The first was the realization that I never, ever, under any circumstances, have any use whatsoever for the original monoprop tank.  I've never once used it, in three years of gameplay.  The little spherical tank is overkill in most situations, frankly; if I need more than a pair of the spheres, I just use the 1.25m inline tank, which is plenty for me.  The second factor was my desire to have a reasonably sized and shaped radially attached LFO tank.

So this does that.  It keeps the same mass and cost for the part, it just replaces its 0.6 tons of monoprop with 0.6 tons of LFO.  It seems to fit nicely, and I like the gameplay options it opens for me, and in any case it means I now have a use for a part that was previously completely useless to me.  The config is embarrassingly simple (this isn't, ahem, rocket science), but anyway, here it is for anyone who may find it useful:

// Repurposes the Stratus-V Cylindrified Monopropellant Tank as an LFO tank.

@PART[rcsTankRadialLong] {
	@title = Stratus-LFO Cylindrified Fuel Tank
	@description = After years of disappointing sales, the hard-working engineers of Stratus Corporation finally realized that nobody has any use for a medium-large radial monopropellant tank. So they boldly ventured into new markets with this line of conveniently attachable, moderately-sized LFO tanks.
    -RESOURCE[MonoPropellant] {}
	RESOURCE {
		name = LiquidFuel
		amount = 54
		maxAmount = 54
	}
	RESOURCE {
		name = Oxidizer
		amount = 66
		maxAmount = 66
	}
}

 

Edited July 3, 2017 by Snark
Made heatshield config better, thanks to feedback from canisin

[eddiew]

Nice one @Snark, those are good  

Like you, I'm forever turning off the heatshield shrouds and then snuggling up the parts below. If they had a built-in decoupler on the bottom I'd understand, but as just a sheet of cork and asbestos it seems odd to shroud them, and they get so much wider when you do. I hadn't really thought about the large MP tank, but you're basically bang on. The last time I used it was back in 0.90 before I understood how to dock efficiently! 

[canisin]

Hey @Snark, I didn't quite understand the purpose of your heat shield patch. The heat shields have two bottom nodes. One that fits snugly and has no shroud, and a second lower one, which has an unreasonable gap and the shroud. Afaik, the former node was maybe added in a later version. This is what I mean.

Come to think of it, I would suggest a patch that would simply remove the lower shrouded nodes, and while at it, remove the jettison module, too. I think I can contribute this later, when I have time to play again this week.

[Aelfhe1m]

Hey @Snark good point about the Stratus tank although I do very rarely use it in the cargo bays of really big spaceplanes.

For those that want to keep it but still have a LFO variant then this slightly modified version of your patch will clone it:

Spoiler

// Repurposes the Stratus-V Cylindrified Monopropellant Tank as an LFO tank.

+PART[rcsTankRadialLong] {
	@name = squadLFOTankRadialLong
	@title = Stratus-LFO Cylindrified Fuel Tank
	@description = After years of disappointing sales, the hard-working engineers of Stratus Corporation finally realized that nobody has any use for a medium-large radial monopropellant tank. So they boldly ventured into new markets with this line of conveniently attachable, moderately-sized LFO tanks.
    -RESOURCE[MonoPropellant] {}
	RESOURCE {
		name = LiquidFuel
		amount = 54
		maxAmount = 54
	}
	RESOURCE {
		name = Oxidizer
		amount = 66
		maxAmount = 66
	}
}

 

 

[canisin]

@Snark, glad I could be of help!

[Snark]

1 hour ago, canisin said:

Hey @Snark, I didn't quite understand the purpose of your heat shield patch. The heat shields have two bottom nodes. One that fits snugly and has no shroud, and a second lower one, which has an unreasonable gap and the shroud. Afaik, the former node was maybe added in a later version. This is what I mean.

Thanks!  Had no idea it was even there.  <rant>grumble snarl stupid undiscoverable feature, how are players supposed to know this, grumble grrrr...</rant>

Anyway, I've updated my config above.  Here's what it does now:

• Still turns off the shroud by default, same as it did before
• Deletes the "direct" node (the one that's intended for working without the shroud)
• Moves the "bottom" node (intended for the shroud) to the location formerly occupied by the "direct" node.

Works like a charm! 

1 hour ago, canisin said:

Come to think of it, I would suggest a patch that would simply remove the lower shrouded nodes, and while at it, remove the jettison module, too.

Except that I like having heat shields be jettisonable.  I like ditching them sometimes to save weight, so the parachute descent is slower.So for my own gameplay, at least, I don't want to remove the jettison module.

I tried removing the "bottom" node, as you describe... except that ModuleJettison wants it to be there, and simply removing the bottom node causes KSP to start spamming NullReferenceExceptions all over the place.  Plus, the "direct" node is the wrong size-- it's one size down for all heat shields.

So what I've done (see my revised patch, in my post above) is to delete the "direct" node, and move the "bottom" node to the location formerly occupied by the "direct" node.  Works exactly the way I like.

If somebody didn't need the heat shield to be jettisonable at all, then the solution would be:  delete ModuleJettison; delete the bottom node; and resize the "direct" node to be the right size, while keeping it in the same place.

[canisin]

3 minutes ago, Snark said:

Except that I like having heat shields be jettisonable.  I like ditching them sometimes to save weight, so the parachute descent is slower.So for my own gameplay, at least, I don't want to remove the jettison module.

I tried removing the "bottom" node, as you describe... except that ModuleJettison wants it to be there, and simply removing the bottom node causes KSP to start spamming NullReferenceExceptions all over the place.  Plus, the "direct" node is the wrong size-- it's one size down for all heat shields.

As far as I can tell from reading the config file, it appears to me that jettisonning the heat shield is enabled by the decoupling module (ModuleDecouple) rather than the jetisson module (ModuleJettison), which is quite a bit funny . So I suppose, it should still be alright to remove the ModuleJettison. In this case, maybe you would also like to update the patch to remove the bottom node, keep the direct node, but only correct its size.

[Alshain]

@canisin I think ModuleJettison is for removing resources from containers, such as Fuel or Ore. I'm not sure why it would be on a heat shield, I don't think you can jettison ablator.

EDIT: Nope, that's ModuleFuelJettison.  I'm not really sure what ModuleJettison does.

 

Also, database is updated to this point.

Edited July 3, 2017 by Alshain

[Aelfhe1m]

A small patch to allow command pods to be flown unmanned (testing new rockets without crew, rescue missions etc.). Also adds EC consumption and basic SAS to all manned pods. If you are using a life-support mod you may want to remove the RESOURCE{} section since they add EC consumption per Kerbal and you may end up with too high a power drain with both.

Spoiler

// unmanned command pods
// by Aelfhe1m
@PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[>0]]:FINAL
{
	@MODULE[ModuleCommand]
	{
		@minimumCrew = 0
		RESOURCE // remove resource section if using a life-support mod.
		{
			name = ElectricCharge
			rate = 0.020
		}
		hasHibernation = True
	}
	%MODULE[ModuleSAS] {}
}

 

 

[canisin]

11 hours ago, Alshain said:

@canisin I think ModuleJettison is for removing resources from containers, such as Fuel or Ore. I'm not sure why it would be on a heat shield, I don't think you can jettison ablator.

EDIT: Nope, that's ModuleFuelJettison.  I'm not really sure what ModuleJettison does.

 

Also, database is updated to this point.

ModuleJettions seems to constrol shrouds. Like engine shrouds and heat shield shrouds. It seems it may or may not have an in flight button for jettisoning said shroud, but I have never tinkered much with it.

Here is a discussion about it. And here is its documentation page, but its attributes are not explained.

[Krakatoa]

I've been working on getting a couple of my favorite mods to play nicely with the stock contracts.  Most things seem to work, but my current struggle is that the two different ISRUs that come with the mods aren't being counted towards base or station building contracts. Here's what I've come up with so far to get DSEV's Compact ISRU unit to count.

 

@Contracts
{
	@Base
	{
		@PART_REQUEST:HAS[#Part[ISRU,MiniISRU]]
		{
			@Title = Have an ISRU resource conversion unit on the outpost
            Part = CompactISRU
		}              
	}	
	@Station
	{
		@PART_REQUEST:HAS[#Part[ISRU,MiniISRU]]
		{
			@Title = Have an ISRU resource conversion unit at the station
            Part = CompactISRU
		}          
    }
}

I'm clearly not getting it to talk to the stock contract .cfg properly, so it still isn't getting the checkmark in game.  Any ideas?

[Nicias]

I would like the the Small Hardpoint and Structural Pylon to behave as separators not decouplers. If I look at the cfgs of the TR-18A/D I see that the decoupler has this:

MODULE
	{
		name = ModuleDecouple
		ejectionForce = 250
		explosiveNodeID = top
	}

while the separator has this:

MODULE
	{
		name = ModuleDecouple
		isOmniDecoupler = true
		ejectionForce = 250
	}

 

So would this patch change the Small Hardpoint & Structural Pylons to be separators?:

 

@PART[structuralPylon|smallHardpoint]
{
	@MODULE[ModuleDecouple]
	{
	-explosiveNodeID
	%isOmniDecoupler = true
	}
}

 

 

[Aelfhe1m]

4 hours ago, Nicias said:

[snip]

So would this patch change the Small Hardpoint & Structural Pylons to be separators?:

@PART[structuralPylon|smallHardpoint]
{
	@MODULE[ModuleDecouple]
	{
	-explosiveNodeID
	%isOmniDecoupler = true
	}
}

 

 

This looks reasonable except that when deleting a value the syntax is:

-valueName = something // I generally use delete here but anything will do it's the equals sign that matters

Spoiler

Similarly to delete a whole node you need to include a pair of empty braces

-NodeName {}

 

So:

@PART[structuralPylon|smallHardpoint]
{
	@MODULE[ModuleDecouple]
	{
	-explosiveNodeID = delete
	%isOmniDecoupler = true
	}
}

 

[MatterBeam]

This is my favourite thing. Small tweaks through MM patches that shave off hours of grievances in the long run.

Here's my small contribution:

//All engines surface attachable, except SRBs.
@PART[*]:HAS[#category[Engine],!RESOURCE[SolidFuel]]:FINAL
{
		@attachRules = 1,1,1,0,0
}

Pro:
Less structural parts needed to stick rocket engines where they shouldn't go.
Cons:
Jet engines models are messed up, I need help excluding them. Will an !PROPELLANT[IntakeAir] work?

[leatherneck6017]

I'm blind 

Edited July 8, 2017 by leatherneck6017
drrr

[Alshain]

@leatherneck6017 Not to discourage contributing, but that one is already on the list.