[1.3] Little changes and tweaks

KerbMav · February 1, 2014

I thought I would share some of the tweaks I usually use in my games. It is a mix of stuff I pasted together from configs I copied left and right, some I changed extensively, a little bit is by myself.

Everything relies on ModuleManager and has to be copied into a .cfg file.

I may also have been a little chatty while updating this ...

----------

Adding a decoupler and heat shield to the MK-1 Pod

In career mode we start out with no decouplers, so any rocket has to land with tanks and engines still attached. Granted, it only takes a short excursion to the launch pad to get enough science for the first decoupler, but it still bothered me.

So I added the decoupler MODULE to the 1-man crew capsule via ModuleManager - and did the same for the Launch Escape System while I was at it.

The capsule will appear in staging with its cute old icon again - which should also add an easy visual indicator for reentry heat - and decouples when staged.

While inserting Porkjet's overhauled parts it became apparent that the new MK1 pod has a bigger bottom and clips through the 1.5m heat shield. So, all the more reason for me to add this little change, as well as throw in a heat shielding of its own.

For more information on adding Porkjet's parts see here:

There is also a post by me with a combined and slightly edited config for integrating the parts, but since I copied 98,5% of it, I dare not link to it directly!

Below the separate change to add the decoupler and heat shield to the pod.

@PART[mk1pod*]
{

	stagingIcon = COMMAND_POD
	stageOffset = 1
	childStageOffset = 1

	fx_gasBurst_white = -1.16832, 0.0, -0.0826454, -1.0, 0.0, 0.0, decouple
	sound_vent_large = decouple
	
	@maxTemp = 3300
	!skinMaxTemp = // 2400

	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 150
		explosiveNodeID = bottom
	}

	MODULE
	{
		name = ModuleAblator
		ablativeResource = Ablator
		lossExp = -7500
		lossConst = 0.1
		pyrolysisLossFactor = 6000
		reentryConductivity = 0.01
		ablationTempThresh = 500
		
		useChar = True
		charModuleName = shieldChar
	}
	
	RESOURCE
	{
		name = Ablator
		amount = 100
		maxAmount = 100
	}	
	
	MODULE
	{
		name = ModuleColorChanger
		moduleID = shieldChar
		shaderProperty = _BurnColor
		useRate = False
		toggleInEditor = False
		toggleInFlight = False
		
		redCurve
		{
			key = 0 0
			key = 1 1
		}
		greenCurve
		{
			key = 0 0
			key = 1 1
		}
		blueCurve
		{
			key = 0 0
			key = 1 1
		}
		alphaCurve
		{
			key = 0 0.8
		}
	}
}

----------

And a Decoupler for the LES too!

@PART[LaunchEscapeSystem]
{
	MODULE
	{
		name = ModuleDecouple
		ejectionForce = 25
		explosiveNodeID = bottom
	}
}

----------

Making Probe Cores receive SAS Software Upgrades via Tech Tree

The newest addition is a modification of the configs for Porkjet's engines that would have been the first Squad parts with upgradable stats had they been integrated into the game. This (upgradable parts in stock) luckily never happened and in the above mentioned thread one can find a way to remove the Upgrade MODULE from these parts, but I used what I saw and learned, and muggled together my own modification for the probe cores.

I always wanted all probe cores to remain valid parts in constructing vessels, regardless on how far a player has progressed in the tech tree.

I added a software upgrade into the respective tech tree nodes (of the probe core that introduces a new SAS level, not always 100% conform though, some plane parts will not grant upgrade when unlocking their tech node, but oh well ...), which will set the SAS level in all probe cores (in new vessels only, not launched ones) to the new level.

And finally with a way to deactivate SAS completely, even for the Stayputnik!

@PART[probeCoreSphere]:BEFORE[SASupgrade]
{
	MODULE
	{
	name = ModuleSAS	
	}
}

@PART[*]:HAS[@MODULE[ModuleSAS]]:FOR[SASupgrade]

{

	@MODULE[ModuleSAS]
	{
				
	%SASServiceLevel = 0
	%moduleIsEnabled = false		
	%showUpgradesInModuleInfo = true
		
		UPGRADES
		{

			UPGRADE
			{
				name__ = SASupgradeLvl0
				description__ = SAS Vers. 1.0
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 0
			}
			
			UPGRADE
			{
				name__ = SASupgradeLvl1
				description__ = SAS Vers. 1.1
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 1
			}
			
			UPGRADE
			{
				name__ = SASupgradeLvl2
				description__ = SAS Vers. 1.2
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 2
			}
			
			UPGRADE
			{
				name__ = SASupgradeLvl3
				description__ = SAS Vers. 1.3
				ExclusiveWith__ = SASb
				//IsAdditiveUpgrade__ = false
				moduleIsEnabled = true
				SASServiceLevel = 3
			}
		}
	}
	
}

PARTUPGRADE
	{
	name = SASupgradeLvl0
	partIcon = probeCoreSphere
	techRequired = electrics
	entryCost = 1000
	cost = 0
	title = SAS Software 1.0
	description = Installs SAS software Version 1.0
	}

PARTUPGRADE
	{
	name = SASupgradeLvl1
	partIcon = probeCoreSphere
	techRequired = precisionEngineering
	entryCost = 5000
	cost = 0
	title = SAS Software Upgrade 1.1
	description = Updates SAS software to Version 1.1	
	}

PARTUPGRADE
	{
	name = SASupgradeLvl2
	partIcon = probeCoreSphere
	techRequired = unmannedTech
	entryCost = 10000
	cost = 0
	title = SAS Software Upgrade 1.2
	description = Updates SAS software to Version 1.2	
	}

PARTUPGRADE
	{
	name = SASupgradeLvl3
	partIcon = probeCoreSphere
	techRequired = advUnmanned
	entryCost = 15000
	cost = 0
	title = SAS Software Upgrade 1.3
	description = Updates SAS software to Version 1.3	
	}

----------

Swap EVA Report and Crew Report to resolve logical issues in my head

An EVA is an EVA and I see no reason why we should learn anything more from an orbital EVA above a certain biome than from looking out of the window - so I swapped the situational modifyers for EVA and crew report as well as their science values.

// situation bits:
// SrfLanded = 1,
// SrfSplashed = 2,
// FlyingLow = 4,
// FlyingHigh = 8,
// InSpaceLow = 16,
// InSpaceHigh = 32

@EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]]
{
        @baseValue = 8
        @scienceCap = 8
        @dataScale = 1
        @situationMask = 63
        @biomeMask = 31
}
 
@EXPERIMENT_DEFINITION[*]:HAS[#id[evaReport]]
{
        @baseValue = 5
        @scienceCap = 5
        @dataScale = 1

        @situationMask = 63
        @biomeMask = 3
}

---------

Tweak USI Life Support settings a bit and load pods with supplies

These definitely only make sense when using the corresponding mod:

USI LS simulates emergency rations (I guess) by letting kerbals survive for some time without supplies, but my OCD would not allow such reality bending! :wink:

All (hopefully) parts that can hold crew now also hold supplies and have room to store mulch for recycling.

// Rate of consumption is 1.8 Supplies per Kerbal per Hour

// Adds 5 days worth of Supplies (per kerbal seat) to Command Modules
// Ignores parts that already have Supplies values declared
@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]
{
	RESOURCE
	{
		name= Supplies
		maxAmount = 40
		@maxAmount *= #$/CrewCapacity$
		amount = #$maxAmount$
	}
	
	RESOURCE
	{
		name= Mulch
		maxAmount = 20
		amount = 0
	}
}

// Adds 10 days worth of Supplies (per kerbal seat) to non-Command Modules
// Ignores parts that already have Supplies values declared
@PART[*]:HAS[!MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]
{
	RESOURCE
	{
		name= Supplies
		maxAmount = 400
		@maxAmount *= #$/CrewCapacity$
		amount = #$maxAmount$
	}
	
	RESOURCE
	{
		name= Mulch
		maxAmount = 200
		amount = 0
	}
}

I also changed the settings to reduce the survival time to 5 days (here: 24hrs!) without supplies (water and food) and 12 hours without energy (AC and air filters). But I halved the required EC to make Gemini like programs in the smaller pods a bit more viable while lacking power generation to avoid having to increase their internal battery capacity.

Everybody dies when their physical needs are not met, and so do my kerbonauts. Although they just quit their jobs when they get home sick and sit around doing nothing while waiting for the bus home (or better entertainment I guess).

	@LIFE_SUPPORT_SETTINGS
{
	@SupplyTime = 432000		//How many seconds before Kerbals are affected by no supplies
	@ECTime = 43200	 			//How many seconds before Kerbals are affected by no EC
	@EVATime = 21600			//How many seconds before ill effects on EVA
	@ECAmount = 0.005			//EC per Kerbal per second						
	@SupplyAmount = 0.0005		//Supplies consumed per Kerbal per second
	@WasteAmount = 0.0005		//Mulch produced per Kerbal per second
	@NoSupplyEffect = 5			//Effect if a Kerbal has no supplies
	@NoSupplyEffectVets = 5		//Effect if a Kerbal is a vet and has no supplies
	@NoECEffect = 5				//Effect if a Kerbal has no EC
	@NoECEffectVets = 5			//Effect if a Kerbal is a vet and has no EC
	@EVAEffect = 5				//Effect if a Kerbal exceeds EVA time		
	@EVAEffectVets = 5			//Effect if a Kerbal is a vet and exceeds EVA time
	@NoHomeEffect = 1			//Effect if a Kerbal becomes homesick
	@NoHomeEffectVets = 1		//Effect if a Kerbal is a vet and becomes homesick
	@HabMultiplier = 1			//Bonus to hab values (1 = default = 100% of the part's rated value)
	@HomeWorldAltitude = 25000	//Altitude on Kerbin that negative effects are removed
	@BaseHabTime = 0.25			//How long can 1 crew capacity support 1 Kerbal, expressed in Kerbal Months
	@ReplacementPartAmount = 0	//How fast life support equipment and habs 'wears out'
	@HabRange = 150				//How close we need to be to use other vessel's habitation modules and recyclers.
	@EnableRecyclers = true		//Use resource recyclers?  Not the same as resource converteres like greenhouses!
	@VetNames = Jebediah,Valentina,Bill,Bob	
	@ScoutHabTime = 9180000
	@PermaHabTime = 459000000
}

//  SIDE EFFECTS:
// 
//  0 = No Effect (The feature is effectively turned off
//  1 = Grouchy (they become a Tourist until rescued)
//  2 = Mutinous (A tourist, but destroys a part of a nearby vessel...)
//  3 = Instantly 'wander' back to the KSC - don't ask us how!
//  4 = M.I.A. (will eventually respawn)
//  5 = K.I.A.

Since USI now requires Fertilizer (can be produced from Ore in the mod) to convert Mulch in space gardens into new supplies, I added a way to refine it from Mulch (with big losses) the same way the mod produces it from Ore: an addition to the small ISRU refinery.

@PART[MiniISRU]
{
	MODULE
	{
		name = ModuleResourceConverter_USI
		ConverterName = Compost
		StartActionName = Start ISRU [Mulch -> Fertilizer]
		StopActionName = Stop ISRU [Mulch -> Fertilizer]

		INPUT_RESOURCE
		{
			ResourceName = Mulch
			Ratio = 0.025
		}
		INPUT_RESOURCE
		{
			ResourceName = ElectricCharge
			Ratio = 30
		}
		OUTPUT_RESOURCE
		{
			ResourceName = Fertilizer
			Ratio = 0.0025
			DumpExcess = False
		}
	}	
}

Old Stuff:

Reveal hidden contents

I thought I would share some of my tweaks to the game.

Some of them might be seen as making the game easier as sometimes a part or two are saved, many are changes to other mods or only make sense when using other mods.

Everything relies on ModuleManager and has to be copied into a .cfg file.

----------

In career mode we start out with no decouplers, so any rocket has to land with tanks and engines still attached. Granted, it only takes a short excursion to the launch pad to get the first decoupler, but it still bothered me.

So I added the the decoupler MODULE to the 1-man crew capsule via ModuleManager - and did the same for the Launch Escape System.

The capsule will appear in staging with its cute old icon again - which should also add an easy visual indicator for reentry heat - and decouple when staged.

@PART[mk1pod]
{

stagingIcon = COMMAND_POD
stageOffset = 1
childStageOffset = 1

fx_gasBurst_white = -1.16832, 0.0, -0.0826454, -1.0, 0.0, 0.0, decouple
sound_vent_large = decouple

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

@PART[LaunchEscapeSystem]
{

stagingIcon = COMMAND_POD
stageOffset = 1
childStageOffset = 1

fx_gasBurst_white = -1.16832, 0.0, -0.0826454, -1.0, 0.0, 0.0, decouple
sound_vent_large = decouple

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

A full load of data will give five times the capacity of science the mobile lab can hold - so I just raised this limit so I do not have to visit it as often.

Raising the data capacity would temper with the conversion speed, so I left it alone until the speed bonus from available data gets capped internally.

@PART[Large_Crewed_Lab]
{
@MODULE[ModuleScienceConverter]
{
@scienceCap = 2500
}
}
 

An EVA is an EVA and I see no reason why we should learn anything more from an orbital EVA above a certain biome than from looking out of the window - so I swapped the situational modifyers for EVA and crew report.

The crew report transmits for 100%, but if there is not enough power available or you wish to return the report to a lab, you will need to get out and remove the report for storage in the pod or use a mod that enables transfer of experiments between parts.

// situation bits:
// SrfLanded = 1,
// SrfSplashed = 2,
// FlyingLow = 4,
// FlyingHigh = 8,
// InSpaceLow = 16,
// InSpaceHigh = 32

@EXPERIMENT_DEFINITION[*]:HAS[#id[crewReport]]
{
@baseValue = 8 // 6
@scienceCap = 8 // 6
@dataScale = 1
@situationMask = 63
@biomeMask = 23 // = 31 for up to FlyingHigh
}

@EXPERIMENT_DEFINITION[*]:HAS[#id[evaReport]]
{
@baseValue = 5
@scienceCap = 5
@dataScale = 1

@situationMask = 63
@biomeMask = 7 // = 3 for surface only
}
 

The game offers no way to save data taken by probes without the presence of a kerbonaut, but using a mod like e.g. Ship Manifest we can move science data around like crew or fuel and this here will allow storing it inside probe cores and service bays. (Said mods might have added this already.)

@PART[*]:HAS[#vesselType[Probe]]
{
MODULE
{
name = ModuleScienceContainer
reviewActionName = Review Stored Data
storeActionName = Store Experiments
evaOnlyStorage = True
storageRange = 1.3
}
}

@PART[ServiceBay_125]
{
MODULE
{
name = ModuleScienceContainer
reviewActionName = Review Stored Data
storeActionName = Store Experiments
collectActionName = Take Data
evaOnlyStorage = True
storageRange = 2
}
}

@PART[ServiceBay_250]
{
MODULE
{
name = ModuleScienceContainer
reviewActionName = Review Stored Data
storeActionName = Store Experiments
collectActionName = Take Data
evaOnlyStorage = True
storageRange = 2
}
}
 
If you only want the rover body to hold science:

@PART[roverBody]
{
MODULE
{
name = ModuleScienceContainer
reviewActionName = Review Stored Data
storeActionName = Store Experiments
collectActionName = Take Data
evaOnlyStorage = True
storageRange = 2
}
}
 

The LV-N - like the RTG - goes on and on forever while it has liquid fuel, but nothing accounts for the radioactive material decaying. For the RTGs there is a mod, for the LV-N I hacked this here together.

It adds Nukleum and Raddish (radioactive rubbish ... ) as resources, the engine holds both and basically exchanges one for the other to avoid loosing mass and getting an advantage over time. The mass of the engine has been lowered by the mass of the new fuel type.

Without a way to replace Nukleum and get rid of Raddish to avoid carrying around 0.2 tons of waste the engine ultimately becomes useless, but a ship with a completely new engine can dock and swap cargo, rationalization: only the LV-N itself is a safe enough means of transportation - new fuel tanks would help, but I have not add-ited/reporpuse-copied any yet.

@PART[nuclearEngine]:FINAL
{
@mass = 2.80

@MODULE[ModuleEngines*]
{
PROPELLANT
{
name = Nukleum
ratio = 0.0001
DrawGauge = True
}
PROPELLANT
{
name = Raddish
ratio = -0.0001
DrawGauge = True
}
@PROPELLANT[LiquidFuel]
{
@ratio = 0.9
}
}
RESOURCE
{
name = Nukleum
amount = 20
maxAmount = 20
}
RESOURCE
{
name = Raddish
amount = 0
maxAmount = 20
}
}

RESOURCE_DEFINITION
{
name = Nukleum
density = 0.0020
unitCost = 1
flowMode = ALL_VESSEL
transfer = PUMP
isTweakable = true
}

RESOURCE_DEFINITION
{
name = Raddish
density = 0.0020
unitCost = 0.01
flowMode = ALL_VESSEL
transfer = PUMP
isTweakable = false
}
 

I also added ways to find and mine more Nukleum, but I have not tested these yet and there is also no tank to take in the Raddish to get rid of it. (Is there a stock way to dump tanks .. hm .. ?)

Eventually the engine should start with no Nukleum in the VAB and not be tweakable, but I will leave this to the player.

@PART[RadialDrill]
{
@MODULE[ModuleResourceHarvester]:HAS[#ResourceName[Ore]]
{
@ConverterName = Surface Ore Harvester
@StartActionName = Start Ore Harvester
@StopActionName = Stop Ore Harvester
}
MODULE
{
name = ModuleResourceHarvester
HarvesterType = 0
Efficiency = 1
ResourceName = Nukleum
ConverterName = Surface Nukleum Harvester
StartActionName = Start Nukleum Harvester
StopActionName = Stop Nukleum Harvester
ImpactTransform = ImpactTransform
ImpactRange = 5
AutoShutdown = false
GeneratesHeat = false
UseSpecialistBonus = true
SpecialistEfficiencyFactor = 0.2
SpecialistBonusBase = 0.05
Specialty = Engineer
EfficiencyBonus = 1

INPUT_RESOURCE
{
ResourceName = ElectricCharge
Ratio = 15
}
}
}

@PART[SurfaceScanner]
{
MODULE
{
name = ModuleResourceScanner
ScannerType = 0
ResourceName = Nukleum
MaxAbundanceAltitude = 1000
RequiresUnlock = false
}
MODULE
{
name = ModuleAnalysisResource
resourceName = Nukleum
abundance = 0
}
}

@PART[OrbitalScanner]
{
MODULE
{
name = ModuleResourceScanner
MaxAbundanceAltitude = 500000
RequiresUnlock = true
ScannerType = 0
ResourceName = Nukleum
}
}

@PART[PotatoRoid]
{
MODULE
{
name = ModuleAsteroidResource
resourceName = Nukleum
presenceChance = 40
lowRange = 50
highRange = 75
}
}

RESOURCE_DEFINITION
{
name = Nukleum
density = 0.0020
unitCost = 1
flowMode = ALL_VESSEL
transfer = PUMP
isTweakable = true
}

RESOURCE_DEFINITION
{
name = Raddish
density = 0.0020
unitCost = 0.01
flowMode = ALL_VESSEL
transfer = PUMP
isTweakable = false
}

GLOBAL_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0

Distribution
{
PresenceChance = 1
MinAbundance = 0.1
MaxAbundance = 0.2
Variance = 50
Dispersal = 3
}
}

PLANETARY_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Eve

Distribution
{
PresenceChance = 65
MinAbundance = 1
MaxAbundance = 15
Variance = 50
Dispersal = 3
}
}

PLANETARY_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Moho

Distribution
{
PresenceChance = 45
MinAbundance = 1
MaxAbundance = 5
Variance = 50
Dispersal = 3
}
}

PLANETARY_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Bop

Distribution
{
PresenceChance = 45
MinAbundance = 1
MaxAbundance = 5
Variance = 50
Dispersal = 3
}
}

PLANETARY_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Sun

Distribution
{
PresenceChance = 0
MinAbundance = 0
MaxAbundance = 0
Variance = 0
Dispersal = 0
}
}

PLANETARY_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Jool

Distribution
{
PresenceChance = 0
MinAbundance = 0
MaxAbundance = 0
Variance = 0
Dispersal = 0
}
}

BIOME_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Eve
BiomeName = Explodium Sea

Distribution
{
PresenceChance = 0
MinAbundance = 0
MaxAbundance = 0
Variance = 0
Dispersal = 0
}
}

BIOME_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Kerbin
BiomeName = Water

Distribution
{
PresenceChance = 0
MinAbundance = 0
MaxAbundance = 0
Variance = 0
Dispersal = 0
}
}

BIOME_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Laythe
BiomeName = The Sagen Sea

Distribution
{
PresenceChance = 0
MinAbundance = 0
MaxAbundance = 0
Variance = 0
Dispersal = 0
}
}

BIOME_RESOURCE
{
ResourceName = Nukleum
ResourceType = 0
PlanetName = Laythe
BiomeName = Crescent Bay

Distribution
{
PresenceChance = 0
MinAbundance = 0
MaxAbundance = 0
Variance = 0
Dispersal = 0
}
}
 

----------------------------------------------------------------------------------------------------

These definitely only make sense when using the corresponding mod:

This is a copied tweak from futrtrubl for USI Life Support in which I only reduced the time the resources will last and added a bit of storage for Mulch to be brought back for recycling.

The whole reason being that USI simulates emergency rations by letting kerbals survive for 15 days without supplies, but my OCD would not allow such reality bending!

// Rate of consumption is 1.08 Supplies per Kerbal per Day

// Adds 5 days worth of Supplies (per kerbal seat) to Command Modules
// Ignores parts that already have Supplies values declared
@PART[*]:HAS[@MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]
{
RESOURCE
{
name= Supplies
maxAmount = 5.40
@maxAmount *= #$/CrewCapacity$
amount = #$maxAmount$
}

RESOURCE
{
name= Mulch
maxAmount = 5
amount = 0
}
}

// Adds 10 days worth of Supplies (per kerbal seat) to non-Command Modules
// Ignores parts that already have Supplies values declared
@PART[*]:HAS[!MODULE[ModuleCommand],!RESOURCE[Supplies],#CrewCapacity[>0]]
{
RESOURCE
{
name= Supplies
maxAmount = 10.80
@maxAmount *= #$/CrewCapacity$
amount = #$maxAmount$
}

RESOURCE
{
name= Mulch
maxAmount = 10
amount = 0
}
}
 
I also changed the settings to reduce the survival time to 6 kerbal hours and make the mod deadly instead of kerbals simply going on strike until resupply arrives.

(Can this be done with ModuleManager, too??)

LIFE_SUPPORT_SETTINGS
{
SupplyTime = 21600
CausesDeath = true
ECAmount = 0.01
}
 

The KIS/EVA Portable Science Container and Transmitter does not work with AntennaRange - with this config it does, but it looses the restriction that only scientists can use it ...

// nominalRange: The distance from Kerbin at which the antenna will perform exactly as prescribed by
// packetResourceCost and packetSize.
// maxPowerFactor: The multiplier on packetResourceCost that defines the maximum power output of the antenna. When the
// power cost exceeds packetResourceCost * maxPowerFactor, transmission will fail.
// maxDataFactor: The multipler on packetSize that defines the maximum data bandwidth of the antenna.
//

@PART[VT_FSPack]:FOR[AntennaRange]:NEEDS[!RemoteTech2]
{
@MODULE[ModuleDataTransmitter]
{
@name = ModuleLimitedDataTransmitter
nominalRange = 10000
maxPowerFactor = 2
maxDataFactor = 2
}

@MODULE[VT_ModuleScienceContainer]
{
@name = ModuleScienceContainer

dataIsCollectable = true
dataIsStorable = true

@storageRange = 2
}
}
 

----------------------------------------------------------------------------------------------------

Thank you to all modders and forumers that answered my questions and helped with ideas!

Edited July 16, 2017 by KerbMav
new stuff

landeTLS · February 1, 2014

Hmm this looks useful. Will try out later.

Now to see who makes the first tier 0 command pod multistage decoupler exploit ship using this:D

Edited February 1, 2014 by landeTLS

KerbMav · February 1, 2014

landeTLS said:
Now to see who makes the first tier 0 command pod multistage decoupler exploit ship using this:D

People were exploiting SRBs as decouplers before, so I do not pay that much thought.

I just wanted a more realistic feel for the first real mission.

landeTLS · February 1, 2014

KerbMav said:
People were exploiting SRBs as decouplers before, so I do not pay that much thought.
I just wanted a more realistic feel for the first real mission.

Yea. I like the idea. I just thought about how that ship would look would be funny

Mecripp · February 1, 2014

Nice didn't think about doing this hehe this could shave some parts off.

Lord_Jeb · February 13, 2014

I like the idea.It would make sense to have this from the start of career mode.

wasmic · February 13, 2014

Actually, this is more of a mod than most things posted here. Most stuff here is either an add-on or a plugin, which means that it doesn't modify anything. This modifies the stock parts, so it's one of the few things in this subforum that can actually be described as a mod.

Gaius · February 13, 2014

wasmic said:
Actually, this is more of a mod than most things posted here. Most stuff here is either an add-on or a plugin, which means that it doesn't modify anything. This modifies the stock parts, so it's one of the few things in this subforum that can actually be described as a mod.

Plugins modify the game itself in some manner. That's the traditional meaning of "mod" in the gaming sense. "Modifying stock parts" is a more KSP-specific notion. But let's not get into a "modlier than thou" discussion.

Edited February 13, 2014 by Gaius

Stratoroc · February 13, 2014

has anyone tried making both nodes explosive? This can make a command pod into an escape pod without decouplers

KerbMav · May 11, 2015

Added stuff.

Kerbas_ad_astra · May 25, 2015

Just wanted to say "thanks" for putting these together -- saves me the trouble of putting them together myself. Storing experiments in probe cores is very useful!

Hotblack Desiato · May 25, 2015

interesting.

so with a little change, the LV-N would properly burn enricheduranium and produce nuclear waste, which already exists in CRS.

there is one other idea, I like quite much: the decoupling pods. they are just a bit a pain because they nowadays need the heatshield below them ;-) (but the mk1 together with deadly reentry has a built in heatshield aswell.

KerbMav · May 25, 2015

Hotblack Desiato said:
there is one other idea, I like quite much: the decoupling pods. they are just a bit a pain because they nowadays need the heatshield below them ;-) (but the mk1 together with deadly reentry has a built in heatshield aswell.

Because of this I ended up not using it for the saves without DRE - although I really miss the decouplers, the stock ones are way to massive ...

KerbMav · June 10, 2017

Over two years since I meddled in KSP?! Anyway, I felt like giving this an update.

[1.3] Little changes and tweaks

Recommended Posts

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