ScrapyardBob's 1.0.5 career

[WuphonsReach]

I run a heavily modded game (on Ubuntu Gnome 64bit), lots of part mods, RemoteTech, USI Life Support (USI-LS), KCT (Kerbal Construction Time).  A partial list of the mods that I use can be found in the spoiler (there are a lot of mods that don't have version files).

Spoiler

$ find . -name '*.version' | sort
./000_USITools/USITools.version
./Chatterer/Plugins/Chatterer.version
./CommunityResourcePack/CRP.version
./ConnectedLivingSpace/ConnectedLivingSpace.version
./ContractConfigurator/ContractConfigurator.version
./ContractPacks/AnomalySurveyor/ContractPack-AnomalySurveyor.version
./ContractPacks/FieldResearch/ContractPack-FieldResearch.version
./ContractPacks/KerbinSpaceStation/KerbinSpaceStation.version
./ContractPacks/RemoteTech/ContractPack-RemoteTech.version
./ContractPacks/Spacetux/SharedAssets/SpacetuxSA.version
./ContractPacks/Spacetux/UnmannedContracts/UnmannedContracts.version
./ContractPacks/Tourism/ContractPack-Tourism.version
./ContractsWindow/ContractsWindowPlus.version
./DMagicOrbitalScience/DMagicOrbitalScience.version
./ExtraplanetaryLaunchpads/Plugins/EL.version
./Firespitter/Firespitter.version
./FuelTanksPlus/FuelTanksPlus.version
./InterstellarFuelSwitch/Plugins/InterstellarFuelSwitch.version
./JSI/RasterPropMonitor/RasterPropMonitor.version
./KAS/Plugins/KAS.version
./KerbalConstructionTime/.version
./KerbalEngineer/KerbalEngineer.version
./KerbalJointReinforcement/KerbalJointReinforcement.version
./KerboKatz/KerbalScienceExchange/KerbalScienceExchange.version
./KerboKatz/KerboKatzUtilities.version
./KIS/Plugins/KIS.version
./LETech/LETech.version
./ModRocketSys/ModularRocketSystems.version
./NavyFish/Plugins/Docking Port Alignment Indicator/DockingPortAlignmentIndicator.version
./PlanetShine/Plugins/PlanetShine.version
./RemoteTech/RemoteTech.version
./SafeChute/SafeChute.version
./SCANsat/SCANsat.version
./SETIgreenhouse/SETI-Greenhouse.version
./ShipManifest/ShipManifest.version
./SmartParts/SmartParts.version
./SpaceY-Expanded/SpaceY-Expanded.version
./SpaceY-Lifters/SpaceY-Lifters.version
./StageRecovery/SR.version
./TriggerTech/KerbalAlarmClock/KerbalAlarmClock.version
./TriggerTech/TransferWindowPlanner/TransferWindowPlanner.version
./UbioWeldingLtd/UbioWeldingLtd.version
./UmbraSpaceIndustries/ExpPack/ExpPack.version
./UmbraSpaceIndustries/FTT/FTT.version
./UmbraSpaceIndustries/Karbonite/Karbonite.version
./UmbraSpaceIndustries/KarbonitePlus/KPlus.version
./UmbraSpaceIndustries/Karibou/Karibou.version
./UmbraSpaceIndustries/Kolonization/UKS.version
./UmbraSpaceIndustries/LifeSupport/USI-LS.version
./UmbraSpaceIndustries/SrvPack/SrvPack.version
./UmbraSpaceIndustries/USICore.version
./[x] Science!/[x] Science!.version

And the list of mods that have Parts directories.

Spoiler

$ find . -type d -name 'Parts' | sort
./AB_Launchers/Parts
./Contares-Customized/Parts
./Contares/Parts
./ContractPacks/KerbinSpaceStation/Parts
./ExtraplanetaryLaunchpads/Parts
./GingerCorp/Parts
./JSI/RasterPropMonitor/Library/Parts
./KAS/Parts
./KerbalEngineer/Parts
./KIS/Parts
./LETech-Customized/Parts
./LETech/Parts
./MechJeb2/Parts
./ModRocketSys/Parts
./RemoteTech/Parts
./RLA_Stockalike/Parts
./SCANsat/Parts
./SETIgreenhouse/Parts
./ShadowWorks/Parts
./SmartParts/Parts
./SpaceY-Expanded/Parts
./SpaceY-Lifters/Parts
./Squad/Parts
./Tantares/Parts
./UbioWeldingLtd/Parts
./UmbraSpaceIndustries/FTT/Parts
./UmbraSpaceIndustries/Karbonite/Parts
./UmbraSpaceIndustries/KarbonitePlus/Parts
./UmbraSpaceIndustries/Karibou/Parts
./UmbraSpaceIndustries/Kolonization/Parts
./UmbraSpaceIndustries/LifeSupport/Parts
./UmbraSpaceIndustries/ReactorPack/Parts
./UmbraSpaceIndustries/SrvPack/DERP2/Parts

Good enough to start.  I've been playing KSP long enough that I find early career mode boring, so I always give myself 15 million funds and 5000 science at the start so that I can upgrade most buildings and get moderately deep into the tech tree.  That also means that I use MechJeb2 (MJ) for anything repetitive (that I've done a few dozen times) such as launches, rendevous, setting up transfers, and sometimes docking.

As with all careers, the first contract is to launch a vessel.  I load Jeb into a pod, strap him to a Flea, and off he goes!

Now back to the normal career tactics.  Since I use a life support mod (USI-LS), putting kerbals into orbit comes with maintenance cost of keeping them supplied and happy.  So I prefer to go with unmanned vessels as much as possible at the start.

When starting with RemoteTech in KSP 1.0.5, the first trick is to get your starting network up and running.  There is even a contract pack (Contract Configurator addon) which rewards you for doing so.  My preference is to put up four satellites with DTS-M1 (500km) and Comm-16 (2.5Mm) antennas around Kerbin at 451km (60 minutes).

The second launch should happen just about when the first satellite passes overhead at 451km.  Maybe a little bit afterwards.  In general, when putting up those first satellites, I burn upwards at a steep angle (only 30-40 degrees off of vertical) until I get an Ap around 450km, then circularize at Ap.  Later on, I worry about getting the four satellites spread out around the equator at 90 degree intervals.

After that I focus on getting survey satellites into orbit around Kerbin (polar orbits), Mun and Minmus.  These also serve as local communications satellites for those SOIs with DTS-M1 antennas linking between Kerbin-Mun and Kerbin-Minmus.  Since I have both DMagic and SCANSat installed, I have lots of sensors that need to be deployed at various altitudes around the moons of Kerbin.

One particular survey satellite is of note, and that is the one that holds both the Magnetometer Boom experiment and the RPWS (Radio and Plasma Wave Science) experiment.  Both are from DMagic and you will get repeatable contracts for putting a satellite into a highly inclined (polar) orbit with a large eccentricity for a long period (tens of days).  So for every moon / planet in the Kerbol system, you should plan on having a Mag/RPWS satellite in an polar elliptical orbit.  Put them up, leave them there.  When you get a new experiment to measure the magnetic field, you take one set of readings at high orbit and one at low orbit and transmit them back to start the timer.  It makes for a source of easy money during your career.

 

 

Edited December 31, 2015 by WuphonsReach

[WuphonsReach]

Year 1 Day 328 - Work has begun on building and testing out a Kerbin SOI (sphere of influence) vessel capable of:

• Carrying 3-4 kerbals
• Enough USI-LS supplies for 30-45 days of operations
• dV capacity to get to/from low Minmus/Mun orbit
• dV capacity to perform multiple rescues in the Kerbin SOI
• Lots of blinking lights (so EVA kerbals can find the rescue vessel)
• Automated deployment of parachutes

My current favorite pod for this is the LETech Lithobrake 4K.  It has RPM (Raster Prop Manager) support for the interior, holds four kerbals, and is of a moderate mass.  Plus, unlike the stock 3-kerbal pod, it's symmetrical which makes it easier to deal with in the VAB editor.

I actually run a custom version of the Lithobrake 4K pod.  I did this by copying the .cfg file and changing the mass, EC & monoprop capacity values, and increasing the cost to purchase.  I also added support for 250-300 units of USI-LS "Supplies", but made it so that the supply tanks start only half-full.

Early testing resulted in a craft that looks like this:

For automation, I am using Smart Parts.

That mod adds a part (the ALT-Pro) which can monitor the altitude and whether you are ascending or descending.  When the condition is met, it will fire off an event for one of the action groups in the SPH/VAB.  I usually make use of at least (1) ALT-Pro on all launches to ensure that communications antennas, fairings, and solar panels get deployed as soon as I get above 65km ASL (above sea level).

For craft that return to Kerbin, I use (2) more ALT-Pro modules.

#1 triggers on descent at 3km AGL (above ground level) - it fires off Action Group #9, which deploys any drogue chutes that I am carrying.  The chutes themselves are configured to open at 2.5km.

#2 triggers on descent at 1km AGL - it fires off Action Group #8.  This cuts the drogue chute lines and deploys the main parachutes which will open completely at 950m.

Because I have those modules hooked up on the capsule, I don't have to monitor the return to Kerbin too closely.  Even if I get distracted by the cat or something else, my kerbals will probably land safely.  Even if they happen to come down in the mountains at 3000m ASL.

(Again, this goes with my desire to reduce tedium for things that I've done a bunch of times.)

Video of one of the tests, with triggers at 4km AGL for the drogue chutes (risky if you come down in the highlands).

 

Edited December 31, 2015 by WuphonsReach

[WuphonsReach]

When rescuing kerbals from orbit with USI-LS installed, you have to be mindful of how USI-LS handles starving kerbals.  While stranded kerbals in orbit are ignored after you accept the contract, it's always possible that you will pass within 2.5km of one while doing a launch.  If that happens, then the kerbal's vessel starts to be tracked by USI-LS -- and 14 days later, your kerbal is going to go "on strike" because they haven't had any supplies recently.

When you rendevous with the stranded kerbal's vessel later, you will be met by a grumpy kerbal who will refuse to EVA over to the rescue vessel unless you feed them first.

So in my rescue craft, I have designated seat #4 as the engineer's rescue seat.  I'm using KIS+KAS so I have integrated inventory in each crew member's seat with the ability to carry a few items on the EVA.  The tools of note are the wrench (or screwdriver / electric wrench) along with a radial mount container of USI-LS supplies.

Now, when I come across a hungry and grumpy kerbal who refuses to EVA until they get fed, my engineer in the rescue craft can EVA across, slap that radial-mount container of supplies to the vessel, then go back to the rescue craft.  After retreating to a safe distance, I change focus to the stranded craft and watch the little green monster explode in a frenzy of eating.

(At this point it should be possible to get the kerbal to EVA... should.)

The other thing my engineer carries is a junior-sized docking port.  It's not big enough to allow crew transfer without EVA, but it is enough that I could transfer even more supplies over to the stranded kerbal.  Or move the stricken craft to a different orbit.

 

I also play around with a camera mod in this video, along with RPM (Raster Prop Monitor) and MechJeb's auto-docking.

 

Edited December 31, 2015 by WuphonsReach

[WuphonsReach]

In order to deal with blackouts due to planet transits (mostly Kerbin) or sub-optimal alignment of planets, I always put a pair of satellites in moderately tight orbit around Kerbol (the star).

These two Kerbol anchor satellites are expensive, but contain the following antennas from RemoteTech:

• Comm 88-88, pointed at Moho, Eve, Kerbin, Duna, Dres
• Comm 88-88, pointed at the sister satellite
• GX-128, pointed at Dres, Laythe, Vall, Eeloo
• GX-128 pointed at "active vessel"

That gives me complete coverage of the Kerbol system, even if the GX-128 / Comm 88-88 equipped satellites at Kerbin are blocked.  The downside is that a relay from Kerbin to a 2.8Mm orbit around Kerbol can introduce 40-75 seconds of signal delay.

All future inter-planetary vessels launched after these will point both at Kerbin as well as at least one of these two Kerbol satellites.

Another advantage is that those two satellites never have to deal with blackout periods since they are inside the orbit of Moho and nothing can block Kerbol's light.  They're also close enough in that the solar panels are over-producing (and I could probably trim back to just 3 or 4 gigantor panels).

[WuphonsReach]

Year 2 Day 195 -- Crew rescues have been proceeding well so far (it's the best way to recruit kerbals in 1.0.5), enough that I'm ready to risk a few kerbals on a trip to Minmus.

For a lander pod design, I'm using one from the CONTARES mod called the Tucana.  As with the Lithobrake 4K pod, I have created a custom version of the Tucana that is heavier and which contains more RCS fuel, more EC storage and support for USI-LS supplies.

The spoiler contains a "diff" of the two configuration files, showing the changes.

Spoiler

$ diff Contares/Parts/PPTS/_Tucana_Crew_A.cfg Contares-Customized/Parts/PPTS/Tucana_Crew_A_XLS.cfg
4c4
< name = Tucana_Crew_A
---
> name = Tucana_Crew_A_XLS
6c6
< author = Tantares
---
> author = Tantares-WuphonsReach
20,21c20,21
< entryCost = 9200
< cost = 3400
---
> entryCost = 25000
> cost = 10000
25c25
< title        = Tucana Crew Capsule
---
> title        = Tucana Crew Capsule XLS
27c27
< description  = A large capacity command pod.
---
> description  = A large capacity command pod with extended life support (USI-LS) supply storage.
31c31
< mass = 1.6
---
> mass = 1.9
61,62c61,62
<     amount = 500
<     maxAmount = 500
---
>     amount = 2500
>     maxAmount = 2500
68,69c68,69
<     amount = 95
<     maxAmount = 95
---
>     amount = 250
>     maxAmount = 250
81,83c81,83
<     PitchTorque = 6
<     YawTorque = 6
<     RollTorque = 6
---
>     PitchTorque = 7.5
>     YawTorque = 7.5
>     RollTorque = 7.5
88c88
<         rate = 0.32
---
>         rate = 0.45
133c133,146
< }
\ No newline at end of file
---
> 
> RESOURCE
> {
>     name = Supplies
>     amount = 100
>     maxAmount = 300
> }
> RESOURCE
> {
>     name = Mulch
>     amount = 0
>     maxAmount = 100
> }
> }
 

• EC storage changed from 500 to 2500
• Monoprop changed from 95 to 250
• Slightly more reaction wheel power (6.0 -> 7.5)
• Maximum of 300 USI-LS Supplies, default of 100
• Mass increased from 1.6 to 1.9

This is a no-frills 2.5m pod with limited IVA that holds 6 kerbals and has a low mass (it's probably a bit OP).  I'll attach a 2.5m tank to the bottom along with some radial tanks and legs, put an probe core on the front along with a Jr-sized docking port.

This can handle getting to/from the Mun/Minmus from Kerbin orbit, including landing and returning to orbit around Mun/Minmus/Kerbin.  The payload is enclosed in a 3.75m stock fairing for launch.  The orbital insertion stage that gets it from ~57km to an ~85km orbit after launch usually has 1500-1800 dV leftover.

I didn't bother attaching any science experiments to the craft because I wanted to keep the cost down for something that will probably be used for multiple launches.

There are still a few CLS issues with the craft due to the use of the Athena (FASA) probe core at the front of the rocket between the docking port and the pod.  But since I'm using a Jr-sized docking port (which is not crew-passable), it doesn't matter.  The docking port is just there for resource transfer.  The crew will be forced to EVA to move from one vessel to another.

[Geschosskopf]

Nice program.  Also some nice tips on mods I've never tried.

As to USI-LS, Kerbals within Kerbin's SOI automatically get 14 days or so of supplies.  I once sent a Kerbal to Duna and unintentionally only packed supplies for a 1-way trip (plus the Kerbal threw a month's worth out the airlock in a fit of space rage).  Anyway, he got grump while at Duna.  Fortunately, the ship had a probe core so could come back by itself, but the probe core was in the OMS stage so would be ditched after the deorbit burn, and thus wouldn't be available to control the landing or open the chutes.  Thus, I was planning to do a food-supply rescue like you're doing.  However, much to my surprise, once ship entered its parking spot at LKO to await rescue, I discovered the Kerbal was active again so he landed by himself.

[WuphonsReach]

Yeah, I'm still figuring out USI-LS and how to rescue kerbals that have gone inactive due to grumpiness. Attaching radial food packs (either USI-LS or DERP) to the stricken craft is still a smart idea prior to docking, because it gets the feeding frenzy out of the way before they gain access to your rescue craft's supplies.

(Currently running a rescue mission using the UKS Kerbitrail docking ports which can be surface mounted and carried, like a backpack, in the KIS SC-62 container during EVA.)

[WuphonsReach]

Mission to Minmus #1 - Year 2 Day 195 (or thereabouts)

Crew launched from KSC on Y2D195: Loddo (P), Gregson (E), Bill (E) and Bob (S).  Note that Bill was already up at the Kerbin space station and just EVA'd across to the 'Eagle' lander when it docked for refueling / resupply.  After a brief rest and resource transfer using SM (Ship's Manifest) to fill up all fuel tanks, the crew departed for Minmus.

The initial plan was to land them at Minmus (no particular place), then bring them back to Kerbin.  This should be pretty easy because the lander has ~4500-5000 dV of fuel in it, along with ~45 days of supplies for 6 crew.  Full mission goals:

• Launch from KSC
• Dock at Kerbin station, refuel and resupply
• Depart for Minmus with crew of 4
• Land on Minmus
• EVA to plant flags
• Return to Kerbin orbit
• Dock at Kerbin station
• EVA across to one of the Litho4K pods
• Return to KSC

Everything up until the EVA to plant flags went as planned.

Flags planted, crew gets to rest a bit as I change plans as there were other gears in motion...

I still had not delivered the Minmus station to Minmus orbit, it was still sitting back in Kerbin low orbit (oops).  I also decided to send the Minmus #1 crew out of Kerbin's SOI so that they could get some more XP before returning to Kerbin.  But that required more life support supplies then what I had loaded onto the vessel (oops).

So, the mission parameters changed:

• Minmus station 'Freyja' was still in LKO, it needs fuel before it can leave
• Launch a supply vessel with more fuel, life support supplies, monoprop and dock with 'Freyja'
• Send up a Litho4K pod with another four crew members and dock at 'Freyja'
• Send up a 2nd Litho4K pod to act as a CRV (Crew Return Vehicle) for the Minmus #1 crew
• EVA to attach KAS struts between vessels
• Send 'Freyja' station + attached vessels to Minmus
• Insert 'Freyja' into < 30km orbit
• Plant flags for the 4 new Kerbals on Minmus
• Send all 8 Kerbals out of Kerbin's SOI for XP
• Return all 8 Kerbals to Kerbin

The second crew (Minmus #2) consisted of Kati (S), Jedbert (S), Dudin (E) and Halgan (E), and they launched on Y2D219 in a standard Litho4K vessel.  These were all rescuees from previous rescue missions.  Upon arrival at the 'Freyja' station around Kerbin, Halgan got put to work lashing all the craft together.

Since the KAS attachment points are all pre-mounted, the EVA consisted of getting near a pair of points, right-clicking on the part and using the "Make Link" button.  Then going to the other part and repeating the process in order to create the KAS strut between the two points.  If the KAS struts were not already mounted, I would use struts from the KIS inventory along with the KIS wrench / screwdriver.

The Minmus #2 crew then departed towards Minmus on Y2D227.

 

 

Edited December 31, 2015 by WuphonsReach

[WuphonsReach]

Short notes - the Minmus station arrived at Minmus on Y2D236 and Halgan was once again set to work on EVA.  The goal was to undock one of the two Litho4K pods in order to make room for the lander to dock at one of the two Jr-sized docking ports.  However, because KAS struts were in use, those have to be unlinked before undocking can take place.

Minmus 'Eagle' craft ascended and docked with the station to take on supplies and fuel.  Kati and Jedbert EVA'd over to join the rest of the Minmus #1 crew for a trip out of Kerbin's SOI.  Dudin and Halgan were left behind at 'Freyja' station around Minmus.

The Minmus 'Eagle' lander then burned about 200 m/s outwards from Minmus in order to escape Kerbin.  After exiting the SOI of Kerbin, I had to execute a second 400 m/s prograde burn to catch back up with Kerbin and get back within its SOI.  Unfortunately, by doing this "leave Kerbin and come back" style, and because I had limited life-support (~45 days), I could not rendevous again with Minmus, so the crew had to go all the way back to a 500km orbit around Kerbin.

Y2D239 - A second lander, 'Sparrow', has been launched from KSC.  This is also a 6-kerbal design, identical to 'Eagle'.  The crew consisted of three pilots; Ribster, Anbree and Machel as they were the only kerbals left at KSC.

Here - I made a goof.  I also launched (3) tourists in a pod with no return capability (it's a vacuum-rated lander, no way to come home) and without a docking port big enough to do a crew transfer without EVA.  Since tourists can't EVA, I've got a problem...  The contract called for them to visit the station around Kerbin and then return.

Oh well, I guess they'll have to settle in and be comfortable at Kerbin's station until I can figure something out.

Enter the MKS/OKS mod, the UKS Kerbitrail docking port can be surface attached and is large enough to be CLS-passable.  By attaching one (via a KIS/KAS EVA) to the 'Sparrow' lander and having one on the rescue vessel, I should be able to transfer the tourists.  There are however, a few issues:

• The Kerbitrail docking port is 800L in KIS size units, too large to fit in a Kerbal's inventory
• Therefore I need to use the SC-62 containers, mounted on the vessel somewhere

The SC-62 kontainers can be used as backpacks to allow the kerbal to move around during EVA with up to 1000L of parts.  The downside is that they are big, bulky, and endanger all nearby solar panels and other fragile protrusions, so ladders are a must so a kerbal can cling to something while they do construction.

The 2.5m service bay is from the MRS mod.

The rescue takes place on Y2D251-252 and took 25 minutes from start to finish.

I encountered a few problems during this rescue mission:

1. The Tucana pod that I was using did not have the CLS flags set properly to allow "surface attach".  So even though the Kerbitrail port was properly attached, it didn't count for CLS (Connected Living Space).  So I had to fudge a bit.

2. Docking the two Kerbitrails was messy.  MJ's docking autopilot made a hash of the first attempt and the controls were sloppy.  So I had to simply fiddle with it using manual controls until I got it to work.

3. I might have been able to 'carry' the docking port part instead of using the SC-62 as a backpack.  That would have saved time and effort during the EVA of not having to lug around that big SC-62.

All three tourists were thus successfully returned to Kerbin for contract completion, and the robotic probe core on Sparrow was used to send the lander to Minmus for future service.

[WuphonsReach]

Note: Had to start a new career for 2016 as things were getting a bit wonky in the old career.

Created a spreadsheet of all of the orbital science experiments and SCANSat sensors that I have installed, along with EC usage, low/optimum/high altitudes, etc.

https://drive.google.com/open?id=1N6hAAOpIsGVosptA7AzIwAnECMvlHd5wcdhROtmSqAA

The list of map-creating scanners that I have to cram onto a single satellite is thus:

SCANsat Resource Scanners
KA-100 Detection Array (Karbonite)	Umbra Space Industries	1000	10km	150km	500km	3deg FOV	0.4 EC/s
M4435 Narrow-Band Scanner (Ore)	(stock?)	1000	10km	150km	500km	3deg FOV	0.4 EC/s
M700 Survey Scanner (FuzzyResources)	(stock)	1500	15km	150km	1000km	5deg FOV	0.5 EC/s
Magnetometer Boom (Ore, MetallicOre)	DMagic	1000	30km	50km	60km	2deg FOV	0.8 EC/s
Multi-Spectral Imaging Platform (Minerals)	DMagic	5000	50km	200km	300km	2deg FOV	1.0 EC/s
Multi-Spectral Imaging Platform (Biomes)	DMagic	5000	5km	250km	500km	4deg FOV	1.5 EC/s
Planetary Survey Camera (MKS resources)	Umbra Space Industries	2500	10km	150km	500km	3deg FOV	0.4 EC/s
SCAN Multispectral Sensor (Biomes, Anomolies)	SCANSat	9000	5km	250km	500km	4deg FOV	1.0 EC/s
SCAN RADAR Altimetry Sensor (Altitude)	SCANSat	3500	5km		500km	5deg FOV	0.1 EC/s
SCAN SAR Altimetry Sensor (Altitude)	SCANSat	25000	5km	750km	800km	2deg FOV	1.5 EC/s
Soil Moisture Sensor (Water)	DMagic	4500	50km	250km	500km	3deg FOV	1.5 EC/s

I'll generally start with a 250km orbit for 15-45 days, then move down to a 150km orbit, then up to a 400km orbit for similar periods.  The "Resource Settings Window" for SCANSat is configured as:

• (ON) Resource Biome Lock
• (OFF) Instant Resource Scan
• (ON) Require Narrow Band Scanner
• (ON) Disable Stock Scanning

You have to set those settings at the start of each new game.

The one sensor in the list that I don't bother with is the Magnetometer boom, it has a really low scanning altitude and there are other sensors that also do "Ore".  On the other hand, it's not that expensive and I should probably throw it on there to search for EPL (ExtraPlanetary Launchpads) metallic ore.  But that might get picked up by a different sensor, I can't remember (possibly the MKS/OKS PSC).

 

[WuphonsReach]

This is now my standard "truck" for LKO, the TCRV (Tucana Crew Return Vehicle).  I've added some radiators and tweaked solar panel positioning.

• Holds 6 kerbals
• USI-LS supplies for up to 45 days
• Has about 1900 dV when full (gets to orbit with about 1600-1700)
• 2.5m MRS cargo bay with (2) KIS SC-62 containers (1000L each)
• Automated deployment of solar panels, radiators, omni-directional antennas on ascent at 65km
• Automated retraction of all fragile bits on descent at 65km (and reorientation of vessel to retrograde)
• Automatic deployment of drogue chutes at 3km AGL (above ground level)
• Automatic deployment of main chutes at 1km AGL, plus air bags for rough landings

The whole back part (service module / trunk) is also designed for reentry and recovery using the Stage Recovery mod.  Upon descent down to 65km ASL, it will separate from the pod and both craft will prepare for reentry.  The entire descent is hands-off once I set the Pe low enough to capture.

Downside of being a truck, it's a bit over-built, so has 100 parts when in orbit, but it can handle automated missions within 500Mm of Kerbin.  I can also create extended versions with large fuel tanks, or change up the cargo bay configuration for bigger / smaller payloads, or put a 2.5m passenger cabin on it for bigger crew transfers.

[WuphonsReach]

Notes on costs for the TCRV:

• Total launch cost is about 170k (before adding things to the SC-62 or seat inventories)
• 69k to 70k gets refunded for the first stage (Stage Recovery addon, level 3 tracking center)
• The service module / trunk is about 29k refund (Stage Recovery) if it comes down near KSC
• Recovering the pod near KSC gives back another 29k or so

That puts my net launch cost for a 6-kerbal crew vehicle at around 45k if everything gets recovered as planned.

[WuphonsReach]

General tactics for an RT network in my saves:

The "450km (60 minute)" ring around Kerbin in equatorial orbit.  This is a series of at least four satellites (90 degree spacing) with:

• DP-10 (for launch)
• Comm-16 or Comm-32 for connections to anything with 2.5-5.0Mm of LKO (low Kerbin orbit)
• DTS-M1 - one pointed at Mun, one at Minmus
• (4) Comm 88-88 - pointed at Moho, Eve, Duna, Dres
• (1) GX-128 - pointed at "active vessel"
• (3) GX-128 - pointed at Eeloo, Vail, Laythe
• (2) Comm 88-88, pointed at sats in orbit around Kerbol at about 3Gm altitude (inside Moho orbit)

I will eventually increase the number of sats at 450km to six or eight, mostly to make sure I have ~500km coverage of all launches from launch to orbit insertion. On the other hand, once I have half a dozen vessels parked at the 150km orbit altitude, coverage is "good enough".  Plus I use the ALT-Pro from Smart Parts to ensure that a Comm 16 or Comm 32 auto-deploys at 65km ASL on the ascent, so even if communications go dark once I get over the horizon from KSC (or more then 500km away from KSC), my Ap is already at 85km and I'm above 60km altitude and coasting to Ap.

The two satellites in low Kerbol orbit (2.5Gm to 3.5Gm orbits) have similar antenna needs (and because they are so close to Kerbol, they need minimal solar panels):

• DP-10 for launch
• Comm-16 for getting away from Kerbin
• DTS-M1 pointing back at Kerbin until I'm outside the SOI
• Comm 88-88 pointing back at Kerbin's Mission Control (only 100% reliable after 30-40 days away from Kerbin, before that there are frequent blackouts as Mission Control is on the wrong side of Kerbin and the 450km satellite ring is not covered by the cone angle of the Comm 88-88 completely.  That's usually not a big deal as I can just delay burns by 1-3 hours while I wait for KSC to come back into view.
• (4) Comm 88-88 for pointing at Moho, Eve, Duna, Dres
• (3) GX-128 for pointing at Laythe, Vail and Eeloo
• (1) GX-128 pointing at "active vessel"
• (1) Comm 88-88 to point at the "sister" satellite in low Kerbol orbit

The hard part is putting those two sats into orbit around Kerbol at only 2.5-3.0Gm.  That requires at least 8k dV (and 10k dV would not be excessive).  So I spend 300-450k on a launch vehicle for those two satellites.  But they are the keys to my entire communications network for the outer planets.  It is easier then trying to get to Moho, because I'm not trying to hit a small planet with a small SOI that is in an inclined orbit, so "close" is good enough as long as the orbit is stable.  Because they're in orbit around Kerbol, they almost never have a blackout issue.

Communications at Mun/Minmus get handled by three survey satellites (SCANSat, DMagic Orbital Science and other sensors).  Each has a DTS-M1 pointing back at Kerbin, plus a Comm-16 or Comm-32 for talking to anything else within the Mun/Minmus SOIs.  One of those three satellites usually has a view back to Kerbin and they are in different polar orbits.  By the time I add orbital stations, re-supply ships, landers and other vessels at Mun/Minmus, I have half a dozen ships pointing DTS-M1 antennas back at Kerbin, which gives very reliable coverage at those two moons.

For Moho/Eve/Duna/Dres missions, all vessels have (2) Comm 88-88 antennas (plus DP-10 / Comm 16/32 and DTS-M1 if needed).  One that points at Kerbin (or Mission Control) and one that points at one of the satellites in low Kerbol (sun) orbit.  I might even put (3) Comm 88-88 antennas (one for KSC, one for each low Kerbol orbit satellite) on super-important missions.

For missions out past Dres, they need at least one GX-128 (two or even three is better).  One points at KSC (Mission Control), one points at one of the two satellites in low Kerbol orbit.  For power out past Duna, you need RTGs or reactors (from Umbra Space Industries).  Dres is marginal for solar power (0.11x the power produced compared to something in Kerbin's SOI).

 

[WuphonsReach]

Since I have a lot of mods installed, figuring out what docking port will dock with what is tricky:

First up is figuring out how many different node sizes there are (that controls what can dock to what)

$ find . -name '*.cfg' -exec grep -o 'nodeType.*=.*' '{}' \; | sort | uniq
nodeType = apasSize0    
nodeType = apasSize1    
nodeType = kasplug
nodeType = size0
nodeType = size1
nodeType = size2
nodeType = size3
nodeType = size4
nodeType = size5
 

So I have six "normal" docking node sizes and three oddball ones (KAS, APAS).  The "size0" is the Clamp-o-tron Jr size, "size1" is the normal Clamp-o-Tron size, and "size2" is the 2.5m "Sr" sized docking port.

The "size0" parts in my install are:

./FASA/Apollo/ApolloCSM/FASA_Apollo_DockingDevice.cfg:nodeType = size0
./FASA/Apollo/LEM/DockingCone/FASA_DockingCone_Lem.cfg:nodeType = size0
./FASA/Gemini2/FASA_Agena/Agena_Docking.cfg:nodeType = size0
./FASA/Gemini2/FASA_Gemini_BigG/Gemini_BigGDocking_Ext.cfg:nodeType = size0
./FASA/Gemini2/FASA_Gemini_NoseCone2/Gemini_Nosecone.cfg:nodeType = size0
./FASA/Gemini2/FASA_Gemini_NoseCone2/Gemini_Nosecone_White.cfg:nodeType = size0
./ScrapyardBob/Welded-Parts-MRS/Parts/DockingPorts/dockingPort1-MRS10.cfg:nodeType = size0
./ScrapyardBob/Welded-Parts-MRS/Parts/DockingPorts/dockingPort1-MRS20.cfg:nodeType = size0
./Squad/Parts/Utility/dockingPortJr/dockingPortJr.cfg:nodeType = size0
./Tantares/Parts/ATV/_Capella_Engine_A.cfg:nodeType = size0
./Tantares/Parts/FOBOS/Agena_Port_A/part.cfg:nodeType = size0
./Tantares/Parts/FUJI/Polaris_Port_A/part.cfg:nodeType = size0
./Tantares/Parts/GEMINI/Spica_Port_A/part.cfg:nodeType = size0
./Tantares/Parts/SOYUZ/_Soyuz_Port_A.cfg:nodeType = size0
./Tantares/Parts/SOYUZ/_Soyuz_Port_B.cfg:nodeType = size0
./Tantares/Parts/TKS/Alnair_Port_A/part.cfg:nodeType = size0
./Tantares/Parts/TKS/Alnair_Port_B/part.cfg:nodeType = size0
 

The size 1 parts

$ find . -name '*.cfg' -exec grep -oH 'nodeType.*=.*size1' '{}' \; | sort | uniq
./ScrapyardBob/Welded-Parts-MRS/Parts/DockingPorts/dockingPort2-MRS11.cfg:nodeType = size1
./ScrapyardBob/Welded-Parts-MRS/Parts/DockingPorts/dockingPort2-MRS21.cfg:nodeType = size1
./ShadowWorks/Parts/ShuttleExtras/CBM.cfg:nodeType = size1
./ShadowWorks/Parts/ShuttleExtras/PMA.cfg:nodeType = size1
./ShadowWorks/Parts/StationModules/ISSTruss/TrussADPort.cfg:nodeType = size1
./ShadowWorks/Parts/StationModules/ISSTruss/TrussDPort.cfg:nodeType = size1
./Squad/Parts/Utility/dockingPort/dockingPort.cfg:nodeType = size1
./Squad/Parts/Utility/dockingPortInline/dockingPortInline.cfg:nodeType = size1
./Squad/Parts/Utility/dockingPortShielded/dockingPortShielded.cfg:nodeType = size1
./Squad/Parts/Utility/GrapplingDevice/part.cfg:nodeType = size1
./Squad/Parts/Utility/mk2DockingPort/mk2DockingPort.cfg:nodeType = size1
./Tantares/Parts/SOYUZ/_Soyuz_DockingMechanism_A.cfg:nodeType = size1
./Tantares/Parts/SOYUZ/_Soyuz_DockingMechanism_B.cfg:nodeType = size1
./Tantares/Parts/SOYUZ/_Soyuz_DockingMechanism_Y.cfg:nodeType = size1
./Tantares/Parts/SOYUZ/_Soyuz_DockingMechanism_Z.cfg:nodeType = size1
./UmbraSpaceIndustries/Kolonization/Parts/MKS_DockingPort.cfg:nodeType = size1
./UmbraSpaceIndustries/Kolonization/Parts/MKS_ExpandoTube2.cfg:nodeType = size1
./UmbraSpaceIndustries/Kolonization/Parts/MKS_ExpandoTube4.cfg:nodeType = size1
./UmbraSpaceIndustries/Kolonization/Parts/MKS_ExpandoTube8.cfg:nodeType = size1
 

The size 2 parts:

$ find . -name '*.cfg' -exec grep -oH 'nodeType.*=.*size2' '{}' \; | sort | uniq
./Squad/Parts/Utility/dockingPortSr/dockingPortSr.cfg:nodeType = size2
 

The size 3 parts

$ find . -name '*.cfg' -exec grep -oH 'nodeType.*=.*size3' '{}' \; | sort | uniq
./SpaceY-Lifters/Parts/Docking/SYdocking3m.cfg:nodeType = size3
 

The size 4 parts

$ find . -name '*.cfg' -exec grep -oH 'nodeType.*=.*size4' '{}' \; | sort | uniq
./SpaceY-Lifters/Parts/Docking/SYdocking5m.cfg:nodeType = size4
 

The size 5 parts

$ find . -name '*.cfg' -exec grep -oH 'nodeType.*=.*size5' '{}' \; | sort | uniq
./SpaceY-Lifters/Parts/Docking/SYdocking7m.cfg:nodeType = size5
 

The rules for docking is that both sides have to have the same size listed in their "nodeType = " line (parts can list multiple sizes on the nodeType line as of KSP 1.0.5) -- plus, both sides need to either be genderless (androgynous) or one side needs to be male and the other side needs to be female (also added in KSP 1.0.5).

As for the original question I was trying to answer for myself -- will the MKS/OKS Kerbitrail docking port mate up properly with a normal 1.25m docking port?  The answer is "yes" because it is has "nodeType = size1" and is androgynous.  So when doing rescues of kerbals trapped in things that don't have an airlock / docking port, I can slap the surface-mountable Kerbitrail docking port on the pod using KIS, and then dock with the stricken vessel.

[WuphonsReach]

One of the constant battles in KSP 1.x is frame-rate issues.  One primary solution is "less parts per vessel".  As a result of this quest, I make a lot of use of Ubiozur Welding, but I also create my own custom .cfg files of parts that need to do more then what they currently do.

For instance, the stock "Service Bay (2.5m)" (mass 0.3t, cost 500).  By default, it's pretty barebones, but I want to add a bit of battery capacity and mono-prop storage to it, and do so in a balanced fashion.

1. Create a folder in your GameData/ directory where you will put your personal customized parts.  This keeps all your changes in one place, making them easier to backup.  Personally, I like to have one folder per mod.  So all of my stock .cfg files are under "GameData/PersonalCustomizations/Stock".

2. Find the .cfg file of the part that you want to duplicate and then change.  You'll need a program that can search inside of files, but since I'm on Linux (or you can use Cygwin), I have find/fgrep available.

$ find . -name '*.cfg' -exec fgrep -H 'Service Bay' '{}' \;
./GameData/Squad/Parts/Utility/ServiceBay/ServiceBay_125.cfg:    title = Service Bay (1.25m)
./GameData/Squad/Parts/Utility/ServiceBay/ServiceBay_250.cfg:    title = Service Bay (2.5m)
 

3. Copy the file that you want to change to your own personal directory (created in step 1).

(At this point, if you have a version control system available, add your files to it before you start making changes.)

4. Change the "name =" line in the PART{} block.  This is the unique identifier for the part and has to be unique across your entire KSP install.  A popular technique is to suffix the old part name with your initials, i.e. changing "name = ServiceBay_250" to "name = ServiceBay_250_WR".

5. Now we need to figure out what to add to this part file.  In the case of adding monoprop, I'm looking at adding four of the Stratus-V Roundified tanks.  So I'll open up the stock .cfg file for that part and jot down a few key numbers.

• entryCost = 6200
• cost = 200
• mass = 0.075
• RESOURCE
          {
                  name = MonoPropellant
                  amount = 60
                  maxAmount = 60
          }
   
• maxTemp = 2000

6. I also need to figure out how to add battery storage to the part.  So I need to find the "Z-1k" part file, and jot down the key elements:

• RESOURCE
          {
                  name = ElectricCharge
                  amount = 1000
                  maxAmount = 1000
          }
• maxTemp = 2000
• mass = 0.05
• cost = 880
• entryCost = 8200

7. The entryCost for the 2.5m service module is 1000.  When combining parts, I like to use either the maximum cost of one of the individual costs, or just add all the unique part entryCost values together.  So 1000+8200+6200 gives me an adjusted entryCost of 15400.  That's probably a bit high, so I'll use "entryCost = 12000" in my custom .cfg file.

8. For the "cost =" line.  I want to total up the costs as if I stuck them together by hand within the VAB/SPH.  So 500 for the service module + 1000 for the Z-1k battery + 200x4 for the Stratus-V tanks = 2300 funds.  Sometimes I'll add a few hundred funds as a convenience fee.

9. Repeat the process for the "mass =" line.  (0.3 + 0.05 + 0.075x4) = 0.65 adjusted mass for the final part.  That keeps the part "balanced" in terms of "capability vs mass".

10. I'm not going to change the maxTemp value for the part, because I'm pretending to put everything inside the service bay.

11. The title still says "title = Service Bay (2.5m)", if we don't change that it will be difficult to tell the difference inside the VAH/SPH editor.  I'll use "Service Bay (2.5m), Expanded".

12. You can also change the "manufacturer =" line.  If there is not one in the file, then you can add it after the "title =" line.  Part files without the manufacturer line show up in the VAB as "Found lying by the side of the road".  I suggest coming up with your own manufacturer moniker as it will make it easier to find your custom parts.  I use "manufacturer = Scrapyard Bob's Welding Ltd".

13. Add the RESOURCE{} blocks to the end of the file, before the final curly brace.

At this point the part is finished and ready to use.  Some key notes:

• Don't edit existing .cfg files, copy them to a new folder.
• Failure to change the "name =" line to something unique in your new .cfg file will prevent KSP from working.
• Changing the "name =" line at a later date is a very bad idea (existing craft that use that part will break).
• Changing any of the "node_stack_" or "attachRules" will likely break things.