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

December 22, 2016

Put something together to halve the masses of certain stock structural parts, namely the beams, trusses and micronode. Compared to any comparable parts I've seen from mods these are extremely heavy. The model 650 beam is untouched since its mass is already similar to the modified value for the 200 Pocket Edition, and is a similar-sized part.

@PART[structuralIBeam2]:FINAL
{
	@mass = 0.1375
}

@PART[structuralIBeam3]:FINAL
{
	@mass = 0.09375
}

@PART[structuralMiniNode]:FINAL
{
	@mass = 0.075
}

@PART[structuralPanel1]:FINAL
{
	@mass = 0.0375
}

@PART[structuralPanel2]:FINAL
{
	@mass = 0.15
}

@PART[trussAdapter]:FINAL
{
	@mass = 0.125
}

@PART[trussPiece1x]:FINAL
{
	@mass = 0.0625
}

@PART[trussPiece3x]:FINAL
{
	@mass = 0.1875
}

If you put it in the OP I'd like to ask not to be attributed for its creation.

Edited December 22, 2016 by Guest

December 24, 2016

Is there or could there be a config to set wheel drive limiters to 100% by default?

steve_v · December 26, 2016

Add the science transfer functionality of the new science box to labs & command pods, the lack of which has been irritating me for a while:

@PART[*]:HAS[@MODULE[ModuleScienceContainer]]:HAS[@MODULE[ModuleScienceLab|ModuleCommand]]
{
	@MODULE[ModuleScienceContainer]
	{
	      %canBeTransferredToInVessel = True
	      %canTransferInVessel = True
	      %showStatus = True
	}
}

Edited December 26, 2016 by steve_v
Stupid editor has stupid syntax highlighting.

DuoDex · December 26, 2016

Adds InterstellarFS compatibility to all parts, more or less. Relatively OP.

// See: http://forum.kerbalspaceprogram.com/index.php?/topic/109225-stock-fuel-switch/&do=findComment&comment=2151857
// Code by Badsector, Nertea and veryinky
// LF tanks added by Bigglesworth, 24th July 2015
// Keep resource nodes, fix LF changed by SpaceNomad, 23rd August 2015
// moved to InterstellarFS, refactored, cleaned log warnings and made to work with tanks that aren't full by default by TRauMa, 29th August 2015
// cleanup, slight rebalance by DuoDex sometime in between 2015 and 2017

// we could add :NEEDS[InterstellarFuelSwitch], but as we only touch the InterstellarFuelSwitch node, it's not really necessary  

// -----------------------
// LFOX tanks
// -----------------------
@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch]]:FOR[InterstellarFuelSwitch] {   

    // temporary variables - if you add one here, add it below in cleanup, too
    %tempVar = 0
    %resCost = 0
    %totalCap = 0
    %dryCost = 0
    %LFCost = 0
    %OXCost = 0

    // Total tank capacity
    @totalCap = #$RESOURCE[LiquidFuel]/maxAmount$
    @totalCap += #$RESOURCE[Oxidizer]/maxAmount$

    // compute cost of fuel fitting in part
    @tempVar = #$RESOURCE[LiquidFuel]/maxAmount$
    @tempVar *= 0.8
    @resCost = #$tempVar$

    @tempVar = #$RESOURCE[Oxidizer]/maxAmount$
    @tempVar *= 0.18
    @resCost += #$tempVar$

    // and get dry cost as total cost - resource cost
    @dryCost = #$cost$
    @dryCost -= #$resCost$
    // we don't really use dryCost yet, but as LF tanks are more expensive in stock than their LFOX counterparts, this may change

    // Now compute tank costs adaption as new res costs - old res costs
    // - LF
    @tempVar = #$totalCap$
    @tempVar *= 0.8
    @LFCost += #$tempVar$
    @LFCost -= #$resCost$

    // - OX
    @tempVar = #$totalCap$
    @tempVar *= 0.18
    @OXCost += #$tempVar$
    @OXCost -= #$resCost$

    MODULE {
        name = InterstellarFuelSwitch

        # the first option should leave the tank like it is in stock
        resourceGui = Rocket Fuel;Liquid Fuel;Oxidizer
        resourceNames = LiquidFuel,Oxidizer;LiquidFuel;Oxidizer
        resourceAmounts = #$../RESOURCE[LiquidFuel]/maxAmount$,$../RESOURCE[Oxidizer]/maxAmount$;$../totalCap$;$../totalCap$
        initialResourceAmounts = #$../RESOURCE[LiquidFuel]/amount$,$../RESOURCE[Oxidizer]/amount$;$../totalCap$;$../totalCap$
        tankCost = #0;$../LFCost$;$../OXCost$

        displayCurrentTankCost = true

        hasGUI = true
        showInfo = true

        availableInFlight = false
        availableInEditor = true

        basePartMass = #$../mass$
        tankMass = 0;0;0;0;0
    }

}


@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],@MODULE[InterstellarFuelSwitch]]:AFTER[InterstellarFuelSwitch] {   

    // temporary variables cleanup to supress PartLoader warnings
    !tempVar = DELETE
    !resCost = DELETE
    !totalCap = DELETE
    !dryCost = DELETE
    !LFCost = DELETE
    !OXCost = DELETE

}


// -----------------------
// LF tanks
// -----------------------
@PART[*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],!MODULE[InterstellarFuelSwitch]]:FOR[InterstellarFuelSwitch] {   

    // temporary variables - if you add one here, add it below in cleanup, too
    %tempVar = 0
    %resCost = 0
    %dryCost = 0
    %mixCost = 0
    %OXCost = 0
    %LFcap = 0
    %OXcap = 0

    // compute cost of fuel in part if at capacity
    @resCost = #$RESOURCE[LiquidFuel]/maxAmount$
    @resCost *= 0.8

    // and get dry cost as total cost - resource cost
    @dryCost = #$cost$
    @dryCost -= #$resCost$

    // Now compute tank costs as dry costs + res costs at capacity
    // - LFOX (also calculate caps: 45% of full cap for LF)
    @LFcap = #$RESOURCE[LiquidFuel]/maxAmount$
    @LFcap *= 0.45
    @tempVar = #$LFcap$
    @tempVar *= 0.8
    @mixCost += #$tempVar$
    @OXcap = #$RESOURCE[LiquidFuel]/maxAmount$
    @OXcap *= 0.55
    @tempVar = #$OXcap$
    @tempVar *= 0.18
    @mixCost += #$tempVar$
    @mixCost -= #$resCost$

    // - OX
    @tempVar = #$RESOURCE[LiquidFuel]/maxAmount$
    @tempVar *= 0.18
    @OXCost += #$tempVar$
    @OXCost -= #$resCost$

    MODULE {
        name = InterstellarFuelSwitch

        # the first option should leave the tank like it is in stock
        resourceGui = Liquid Fuel;Oxidizer;Rocket Fuel
        resourceNames = LiquidFuel;Oxidizer;LiquidFuel,Oxidizer
        resourceAmounts = #$../RESOURCE[LiquidFuel]/maxAmount$;$../RESOURCE[LiquidFuel]/maxAmount$;$../LFcap$,$../OXcap$
        initialResourceAmounts = #$../RESOURCE[LiquidFuel]/amount$;$../RESOURCE[LiquidFuel]/maxAmount$;$../LFcap$,$../OXcap$
        tankCost = #0;$../OXCost$;$../mixCost$

        displayCurrentTankCost = true

        hasGUI = true
        showInfo = true

        availableInFlight = false
        availableInEditor = true

        basePartMass = #$../mass$
        tankMass = 0;0;0;0;0
    }

}

@PART[*]:HAS[@RESOURCE[LiquidFuel],!RESOURCE[Oxidizer],!MODULE[FSfuelSwitch],@MODULE[InterstellarFuelSwitch]]:AFTER[InterstellarFuelSwitch] {   

    // temporary variables cleanup to supress PartLoader warnings
    !tempVar = DELETE
    !resCost = DELETE
    !dryCost = DELETE
    !mixCost = DELETE
    !OXCost = DELETE
    !LFcap = DELETE
    !OXcap = DELETE

}

fourfa · January 14, 2017

Is this possible? I'd like my aircraft landing gear to have the following default behavior. When placing in SPH/VAB, lights are turned on and assigned to Gear action group (and removed from Lights). So, gear down = lights on, gear up = lights off by default on launch. The AGs are no problem, but what about the lights on while placing parts?

Snark · January 14, 2017

3 hours ago, fourfa said:

The AGs are no problem, but what about the lights on while placing parts?

Well, the landing gear uses the same ModuleLight that the regular lights use, so it ought to be doable, at least in terms of setting the default state on/off.

However, it wouldn't track the "gear up / gear down" state if you adjust that in the vehicle editor-- you'd have to toggle the lights and the gear separately. (If they get out of sync with each other, they'll re-sync in flight as soon as the gear group is toggled.)

MalevolentNinja · January 14, 2017

I didn't see one of my favorites listed, maybe you want to add this.

// full science for each experiment the first time the experiment is performed

@EXPERIMENT_DEFINITION[*]
{
	%baseValue = #$scienceCap$
}

Armisael · January 16, 2017

I'm having trouble with the autohibernate script; it doesn't seem to be doing anything for me. Can someone else either confirm that or let me know that it's just an issue for me?

Also, any idea how'd I'd go about having fairings start with the interstage nodes disabled?

FWIW I suspect that I'm the author of the 'no monoprop' patch; the timing with this post seems right.

JAFO · January 17, 2017

The auto-hibernate script is working for me.. I suggest you double-check yours for a missing bracket or similar.

32 minutes ago, Armisael said:

Also, any idea how'd I'd go about having fairings start with the interstage nodes disabled?

This is something @5thHorseman and myself have both wanted for a while.. We concluded it couldn't be done.. but just now I dug a little deeper into the API, and I found it!

// Fairing nodes default to off
// Author: JAFO
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:FINAL
{
	@MODULE[ModuleStructuralNodeToggle]
	{
		showNodes = false
	}
}

I haven't found anything in the API that relates to the trusses (maybe they're under some non-intuitive name) but with nodes disabled by default, they're not really a problem anyway.

JAFO · January 17, 2017

1 hour ago, JAFO said:

I haven't found anything in the API that relates to the trusses (maybe they're under some non-intuitive name) but with nodes disabled by default, they're not really a problem anyway.

I've got the trusses nailed too, now.

// Fairing trusses default to off
// Author: JAFO
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:FINAL
{
	@MODULE[ModuleStructuralNodeToggle]
	{
		showMesh = false
	}
}

If you prefer, it's also possible to combine all the fairing tweaks into one patch, and just set the individual items on/off as preferred.

// Fairings your way
// Authors: Alshain, JAFO
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:FINAL
{
	@MODULE[ModuleProceduralFairing]
	{
				// Clamshell or confetti fairing
		useClamshell = true
				// Set number of fairing sides
				// Change to any whole number between 2 and 6
		nArcs = 4
	}
	@MODULE[ModuleStructuralNodeToggle]
	{
				// Enable/disable trusses - set to true to enable
		showMesh = false
				// Enable/disable interstage nodes - set to true to enable
		showNodes = false
	}
}

Edited January 17, 2017 by JAFO
typo

Armisael · January 17, 2017

I was having a dumb moment - left the files as txt instead of cfg.

Anways, @fourfa if you're still looking for that radial decoupler crossfeed default:

//New radial decouplers allow crossfeed
//Author: Armisael
@PART[*]:HAS[@MODULE[ModuleAnchoredDecoupler]]:FINAL
{
  @MODULE[ModuleToggleCrossfeed] 
        {
            @crossfeedStatus = true
        }
}

@PART[*]:HAS[@MODULE[ModuleDecouple]:HAS[#explosiveNodeID[srf]]]:FINAL
{
  @MODULE[ModuleToggleCrossfeed] 
        {
            @crossfeedStatus = true
        }
}

Edited January 17, 2017 by Armisael

JAFO · January 17, 2017

@Deimos Rast

@Alshain

On 20/07/2016 at 2:26 AM, Deimos Rast said:

Any way to set a RX wheel to start in the disabled setting, by the way?

On 20/07/2016 at 4:32 AM, Snark said:

May I ask why you'd want 'em to start disabled? If you're going to have all your reaction wheels disabled, why add them in the first place?

On 20/07/2016 at 6:24 AM, Deimos Rast said:

I saw someone use "operational = false" but that doesn't work.

The reasoning is that I want to have a large central RX wheel in a crew compartment (for example) and have it serve as a backup, secondary RX wheel. It's pretty niche; mainly I just want to know how it's done for the sake of knowing.

@AlshainIt wouldn't be a global disable, I should clarify, it would have been a part by part basis.

On 20/07/2016 at 0:57 PM, Alshain said:

I tried several options that I see in the object browser, however none of them seemed to work. There is a boolean called "operational", I also found property called "State" and a variable called "wheelState" which are an enumerated value type called "WheelState" containing the values Active, Broken, Disabled. Sadly, modifying these didn't seem to affect the game. There has to be something behind the scenes in the KSP code overriding me. There are methods called Activate, Deactivate, and Toggle, however methods can only be triggered from a mod. So it would take a DLL to do what you want.

Whilst I can't speak for earlier versions of KSP, in 1.2.2, directly setting WheelState to the value you want DOES work.

Here's a proof-of-concept patch that will selectively disable the reaction wheels in all crewed pods and drone cores, whilst leaving inline reaction wheels enabled. All stock parts containing reaction wheels are listed, so that each can be enabled/disabled on a part-by-part basis.

// Reaction Wheel Control
// Allows for individually enabling/disabling reaction wheels
// Author: JAFO

// IMPORTANT NOTE! - In this proof-of-concept demonstration,
// all crewed pods and probe core reaction wheels are DISABLED,
// and all inline reaction wheels are ENABLED.

// PLEASE BE SURE TO EDIT THIS FILE TO SUIT YOUR REQUIREMENTS.

// WheelState = 0 - Enabled
// WheelState = 1 - Disabled
// WheelState = 2 - Broken

// Advanced Reaction Wheel Module, Large
@PART[asasmodule1-2]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 0
	}
 }
 
 // PPD-12 Cupola Module
 @PART[cupola]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Advanced Inline Stabilizer
 @PART[advSasModule]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 0
	}
 }
 
 // Small Inline Reaction Wheel
 @PART[sasModule]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 0
	}
 }
 
 // Mk1-2 Command Pod
 @PART[Mark1-2Pod]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk1 Cockpit
 @PART[Mark1Cockpit]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk1 Lander Can
 @PART[landerCabinSmall]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk1 Command Pod
 @PART[mk1pod]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk2 Inline Cockpit
 @PART[mk2Cockpit_Inline]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk2 Cockpit
 @PART[mk2Cockpit_Standard]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // MK2 Drone Core
 @PART[mk2DroneCore]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk2 Lander Can
 @PART[mk2LanderCabin]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Mk3 Cockpit
 @PART[mk3Cockpit_Shuttle]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Probodobodyne HECS
 @PART[probeCoreHex]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Probodobodyne OKTO
 @PART[probeCoreOcto]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // Probodobodyne OKTO2
 @PART[probeCoreOcto2]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // RC-L01 Remote Guidance Unit
 @PART[probeStackLarge]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }
 
 // RC-001S Remote Guidance Unit
 @PART[probeStackSmall]:AFTER[Squad]
 {
	@MODULE[ModuleReactionWheel]
	{
		WheelState = 1
	}
 }

Edited January 17, 2017 by JAFO

The_Lieutenant · January 20, 2017

The "parachute stage toggle" mod no longer works, which means I'm back from the dead to bother you all again.

Raphaello · January 31, 2017

This small code makes Convert-O-Tron 125 useful. It allows for continous work and increases its efficiency and cost five times - making it only two times less efficient than it's bigger brother. I did not change its mass.

// Make mini ISRU useful
@PART[MiniISRU]
{
	@mass *= 1
	@entryCost *= 5
	@cost *= 5

	@MODULE[ModuleResourceConverter],*
	{
		@INPUT_RESOURCE:HAS[#ResourceName[Ore]]
		{
			@Ratio *= 0.2
		}
	}
	
	@MODULE[ModuleCoreHeat]
	{
		@MaxCoolant *= 2
	}
	
}

Edited January 31, 2017 by Raphaello

tg626 · February 3, 2017

Give your antennae some class!

The latest Delta V map (linked below) has included on it the various Tracking Station Levels and "Antenna Class" needed to reach spacecraft on or around the various planets. Trouble is, this "Class" ranking seems to be derived from their ranking, by range, in the wiki. Not exactly a handy reference while in the VAB - so I created this patch:

@PART[longAntenna]:FINAL {
	+description ^= :^:<color=orange>Class 1 Antenna.</color> :
}

@PART[SurfAntenna]:FINAL {
	+description ^= :^:<color=orange>Class 1 Antenna.</color> :
}

@PART[HighGainAntenna5]:FINAL {
	+description ^= :^:<color=orange>Class 2 Antenna.</color> :
}

@PART[mediumDishAntenna]:FINAL {
	+description ^= :^:<color=orange>Class 3 Antenna.</color> :
}

@PART[RelayAntenna5]:FINAL {
	+description ^= :^:<color=orange>Class 3 Antenna.</color> :
}

@PART[HighGainAntenna]:FINAL {
	+description ^= :^:<color=orange>Class 4 Antenna.</color> :
}

@PART[RelayAntenna50]:FINAL {
	+description ^= :^:<color=orange>Class 4 Antenna.</color> :
}

@PART[commDish]:FINAL {
	+description ^= :^:<color=orange>Class 5 Antenna.</color> :
}

@PART[RelayAntenna100]:FINAL {
	+description ^= :^:<color=orange>Class 5 Antenna.</color> :
}

Here is what to expect in the VAB:

Link to the Delta V Map:

Biggen · February 15, 2017

Anyone get the deflatable heat shield cfg to work? I made the cfg and it appears it gets patched up loading KSP, but when i right click an inflated shield in game, I dont see an option to deinflate.

Biggen · February 15, 2017

Well I got it working. Apparantly, it won't work on heat shields that were affixed to crafts BEFORE the .cfg file was patch. So any ships I have out there can't deflate their shields. But it works on new ships.

JAFO · February 15, 2017

1 hour ago, Biggen said:

So any ships I have out there can't deflate their shields. But it works on new ships.

You can probably make it work with ships you've already launched by using KML to edit your persistence file. Find a (new) craft that has a working collapsible heatshield, and compare the heatshield configuration with one that doesn't.. copy/paste the config differences from the functional heatshield to the non-functional ones, save, and you should be good to go.

Biggen · February 15, 2017

7 minutes ago, JAFO said:

You can probably make it work with ships you've already launched by using KML to edit your persistence file. Find a (new) craft that has a working collapsible heatshield, and compare the heatshield configuration with one that doesn't.. copy/paste the config differences from the functional heatshield to the non-functional ones, save, and you should be good to go.

Thanks! Ill try it out.

toric5 · February 17, 2017

Quote


// Add angle snapping to Squad Docking ports (12 increments as on textures)
// Author: Psycho_zs
@PART[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]:FINAL
{
	@MODULE[ModuleDockingNode]
	{
		// If you want X degrees margin, use cos(0.5*X) as captureMinRollDot
		// 0.5 degrees = 0.99999048
		// 1 degree    = 0.99996192
		// 2 degrees   = 0.9998477
		// 3 degrees   = 0.99965732
		captureMinRollDot = 0.99996192
		snapRotation = true
		snapOffset = 30
	}
}

how would i appy it to any docking port that does not already have snapping defined?

JAFO · February 17, 2017

4 hours ago, toric5 said:

how would i appy it to any docking port that does not already have snapping defined?

The entire point of these patches is that they are automatically applied by ModuleManager when you start KSP. None of the stock ports have angle-snapping defined. Creating this patch is what applies it to them.. (assuming you already have MM installed, of course)

That's what the line "@PART[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]" is all about.. it's a list of the "system names" of all the stock docking ports in the game. If you want the patch to work with non-stock docking ports, you need to open the relevant .cfg file for each port and look for the line "name = xxxxxx". (It's usually right at the top of the file). I'd recommend making a separate duplicate patch (suitably named, of course) just for the non-stock ports. Replace the section "[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]" with the list of parts you want to patch.. eg:

[mydockingPort1|mydockingPort2|mydockingPort3]

Installation instructions for the patch are at the top of the first post in the thread.

On 2/4/2017 at 3:50 AM, tg626 said:

Give your antennae some class!

The latest Delta V map (linked below) has included on it the various Tracking Station Levels and "Antenna Class" needed to reach spacecraft on or around the various planets. Trouble is, this "Class" ranking seems to be derived from their ranking, by range, in the wiki. Not exactly a handy reference while in the VAB - so I created this patch:

Nice.. somehow I missed this.. thanks!

Edited February 17, 2017 by JAFO

JAFO · February 18, 2017

On 12/24/2016 at 8:07 PM, String Witch said:

Is there or could there be a config to set wheel drive limiters to 100% by default?

There is.. (it's in ModuleWheelMotor, and it's called driveLimiter) and it's already set in-game to 100% by default.

Edited February 18, 2017 by JAFO

fourfa · February 19, 2017

@swjr-swis had a great post over on another thread, with code to allow fuel jettison to any fuel tank, using the same mechanic as the stock ore tanks. Seems like a great candidate to be expanded upon over here?

toric5 · February 20, 2017

On 2/17/2017 at 4:45 PM, JAFO said:

The entire point of these patches is that they are automatically applied by ModuleManager when you start KSP. None of the stock ports have angle-snapping defined. Creating this patch is what applies it to them.. (assuming you already have MM installed, of course)

That's what the line "@PART[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]" is all about.. it's a list of the "system names" of all the stock docking ports in the game. If you want the patch to work with non-stock docking ports, you need to open the relevant .cfg file for each port and look for the line "name = xxxxxx". (It's usually right at the top of the file). I'd recommend making a separate duplicate patch (suitably named, of course) just for the non-stock ports. Replace the section "[dockingPortLateral|dockingPort2|dockingPort3|mk2DockingPort|dockingPortLarge|dockingPort1]" with the list of parts you want to patch.. eg:

[mydockingPort1|mydockingPort2|mydockingPort3]

i know that, im thinking about something along the lines of:

@PART[*]HAS[@Module[ModuleDockingNode]HAS[snapRotation = false]]

JAFO · February 20, 2017

15 minutes ago, toric5 said:
i know that, im thinking about something along the lines of:
@PART[*]HAS[@Module[ModuleDockingNode]HAS[snapRotation = false]]

Ahh.. ok.

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

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

Recommended Posts

Guest

Link to comment

Share on other sites

Guest

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation