Fail-Man 3D

Gentoo Linux ~amd64, kernel 4.10.17 (upgrading to 4.12 while I write this) with XFCE 4.can'tremember. It supports my GPU (RX 480 8GB, factory overclock) and weird motherboard (4x Socket G34, only half-populated due to me breaking a CPU while trying to remove it from the plastic shipping tray) with minimal effort Installing the libraries needed to make KSP work is fairly painless (vs. other distros wanting to pull in the entire universe as cascading dependencies). Transparent ZFS compression reduces load times, deduplication keeps actual disk use from spiraling out of control, and snapshots mean not having to go digging through backup media when something goes minorly wrong. Almost a decade of familiarity with the distro and its ways of doing things unionfs-fuse simplifies mod management (no more rolling back to the previous filesystem snapshot after careless flailing-about in CKAN breaks a beloved save) Linux also used to be the only platform with a (mostly-)working 64-bit build of KSP, which allowed the "mod it 'til it crashes" play style to scale much further than on then-contemporary Windows builds. I no longer trust Windows enough to allow it unrestricted bare-metal access I also occasionally test stuff on Windows 7 and Mac OS, mostly for mod ideas that end up dying in the trackless wastes of cross-platform packaging while attempting to make native-code dependencies work.

After lots of OpenRC-hackery, xorg.conf dead-chicken-waving, and doing an unsupported in-place system profile change on my new Gentoo box, I managed to get KSP running. My first* flight in ~6 months was a modified Aeris 4A (2x RAPIER + 1x LV-909) to LKO without any mods whatsoever. Edit: Now let the modding commence! * (That Windows VM doesn't count; it wasn't on bare metal and didn't use my mod-management scripts!)

I've been playing lots of Dwarf Fortress on my work/emergency backup gaming machine; on a very related note, cat owners should clean their computer's heat sinks regularly to prevent catastrophic thermal runaway.

I run lots of mods (so many that KSP routinely uses 20+ GB of RAM), and like to experiment with different sets of mods for different projects. Instead of using CKAN, I manage my mods with a custom set of shell scripts that call UnionFS-FUSE to do the actual work. UnionFS-FUSE supports copy-on-write, which allows me to fake having multiple installed KSPs for different (incompatibly-modded) projects while saving lots of disk space (only files that are changed get copied). Example script (written for WINE + the Windows version of 1.1.2 to avoid the infamous "double free or corruption" bug in the Linux version of Unity 5): #!/bin/bash # vim: fenc=utf-8 nobomb ff=unix ft=sh ts=4 sts=0 sw=4 noet KSPPREFIX="$(basename -s .sh $0)" # name of the KSP prefix to use, derived from the name of this file KSP_TYPE="win64" # added 2016-05-30 for WINE support KSP_VERSION="1.1.2" # added to separate 0.90 stuff from the mishmash of other mods KSPDIR="${HOME}/ksp" # where the whole tree lives KSPDIR_MOUNTS="${KSPDIR}/mount-points" # where UnionFS mountpoints are KSPDIR_STORAGE="${KSPDIR}/unionfs-storage" # where UnionFS write-diversion directories are KSPDIR_MODS="${KSPDIR}/overlay-mods/${KSP_VERSION}" # where mods live KSPDIR_SCRIPTS="${KSPDIR}/scripts" # where these mount scripts live KSPDIR_BASES="${KSPDIR}/app-templates" # where stock KSP releases live KSPDIR_LOCAL="${KSPDIR}/local-overlays" # local empty-file overrides and tweaks live here to avoid confusing them w/ actual mods KSPDIR_DOCS="${KSPDIR}/docs/${KSP_VERSION}/${KSPPREFIX}" # user-generated documentation e.g. for craft files mkdir -p "${KSPDIR_DOCS}" # where unionfs writes changes. # This is NOT the mountpoint, setting it to the mountpoint causes an infinite loop!. # Must be the only RW entry unless you *want* your mods to get clobbered. KSPPATH="${KSPDIR_STORAGE}/${KSPPREFIX}=RW" # mods go here (if 2 or more share an internal pathname, then the first in the list takes priority)… # the GameData dir goes into ${KSPDIR_MODS}/<mod-name>/ KSPPATH+=":${KSPDIR_MODS}/MechJeb2-2.5.7.0=RO" # mechjeb.com ##### BASE GAME & TWEAKS KSPPATH+=":${KSPDIR_BASES}/KSP_${KSP_TYPE}_${KSP_VERSION}=RO" # apply all the previous lines to this base... cd "${KSPDIR}" # chdir into the instroot mkdir -p "${KSPDIR_STORAGE}/${KSPPREFIX}" UNIONFS_OPTS="default_permissions,use_ino,noatime,cow,statfs_omit_ro,hide_meta_files" mount_point="${KSPDIR_MOUNTS}/${KSPPREFIX}" mkdir -p "${mount_point}" /usr/bin/unionfs -o "${UNIONFS_OPTS}" "${KSPPATH}" "${mount_point}" case $KSP_TYPE in 'win64') # setup write diversion for Wine prefix winemnt="${KSPDIR}/.winemnt/${KSPPREFIX}" # mount point winestor="${KSPDIR}/.winestore/${KSPPREFIX}" # UnionFS write dir winepfx="${KSPDIR}/.wineprefixes/KSP_${KSP_TYPE}_${KSP_VERSION}" # UnionFS template dir, FIXME this currently needs to be set up manually with winecfg mkdir -p "${winemnt}" "${winestor}" /usr/bin/unionfs -o "${UNIONFS_OPTS}" "${winestor}=RW:${winepfx}=RO" "${winemnt}" echo "cd \"${mount_point}\"" echo "optirun -b virtualgl --no-failsafe env WINEPREFIX=\"${winemnt}\" wine \"./KSP_x64.exe\"" echo "" echo "To unmount:" echo "fusermount -u \"${winemnt}\"" echo "fusermount -u \"${mount_point}\"" ;; 'linux') echo "cd ${mount_point}" echo "optirun -b primus --no-failsafe ./KSP.x86_64" echo "" echo "To unmount:" echo "fusermount -u \"${mount_point}\"" ;; esac

I decided to bite the bullet and upgrade to 1.1.2, which (due to a Linux-specific known bug in Unity 5) involved extending my custom mod-managing shell script to also manage WINE prefixes.

Parts (especially landing gear) sinking into the runway is a known issue; IIRC it has something to do w/ how gear colliders work + the runway's collider not lining up exactly w/ the viewmodel. While RSS/RO do make it easier to notice, it can be observed in stock as well if you zoom in far enough. As for the poor takeoff characteristics: The nose gear looks badly overloaded. The shock absorber is fully compressed (presumably due to too much mass sitting on it), so any bumps will get transmitted directly to the fuselage (which will make landing very "Fun"). The rear landing gear should be slightly behind the center of mass, not way at the back of the plane (unless the CoM is actually back there). keptin made a great infographic about this (and other plane-design topics) back in 2013.

I accidentally built a rotational Kraken drive (Kraken gyroscope?) by adding modded-in grid fins to my Mun flyby probe's free-return instrument package; it nearly destroyed the (expensive) Mun-survey satellite it was co-launched with. Craft file to follow after I've had some sleep.

The JetWing just saved my butt in career mode; it's a wonderful little drone platform for high-margin contract farming of the "temperature scan in flight at $place" variety. It has a few minor quirks (attach node orientation, kickstand getting stuck in the level-1 runway, off-centre CoT when used as definitely-not-intended), but they are easily worked around. Overall, I give it a solid 9.5 out of 10; the JetWing may be a little rough around the edges, but it's the part I never knew I wanted.

Earlier today (approx. 01:30 my local time, I was too tired to write about it), I tested a huge mining rover in my career save. Unfortunately, the extremely large chassis and 6-track design resulted in a hilariously large turning radius; the project is now on indefinite hold until I unlock Infernal Robotics hinges. Pictures here (I'm tired of weeding my imgur account, so I decided to get my own virtual server). I also freed 9GB of disk space by compressing old KSP saves.

As of <some-ancient-version>, "chmod a-rx BadPlugin.dll" would cause the game to hang when it tried to load the plugin. I don't have 1.0.5 set up to test with (due to disk space issues + a heavily-modded career save), but I can test with 1.0.4 within the next few hours. EDIT: Looks like this was fixed; the game now logs an UnauthorizedAccessException and skips the plugin instead of freezing.

Kerbal Foundries, KSPI Extended, Kerbal Planetary Base Systems, and the new USI Karibou rover parts are each excellent on their own. When (ab)used together, however, things can get weird; in very related news, I accidentally made my most impact-resistant (and waterproof) rover yet. Pictures to follow^W^W have arrived! Huge picture 1 (view from the driver's seat) Huge picture 2 (view from outside)

Pentaborane is my personal favorite; it features extreme acute toxicity (on par with some nerve agents) with delayed symptom onset, is highly flammable (and usually pyrophoric due to residual impurities), and it reacts with chlorinated hydrocarbon solvents (among many other things) to form poorly-characterized shock-sensitive explosives. It was briefly considered (along with diborane and several alkylated boranes) as a rocket and jet engine fuel. Source: "The Green Flame: Surviving Government Secrecy" by Andrew Dequasie. American Chemical Society, December 1991. ISBN13: 978-0841218574

I developed one for my FRX medium-lift expendable booster family, but it doesn't really transfer well to aircraft. As all FRXen share a common 2.5m core stack, the FRX Designation System lacks many of the earlier (unreleased, circa 0.18.x) Archer Designation System's features. FRX[MY][RC][LSS]-[LBS]-[SBS] [MY] = last 2 digits of model year [RC] = revision code, omitted for the release-to-manufacturing model (revision zero). [LSS] = Liquid Stack Specifier, syntax is L[CSS](.[CSS])... where [CSS] = Component Stage Specifier (order in LSS indicates staging) [LBS] = Liquid Booster Specifier (also covers drop tanks) The syntax for this section isn't nailed down yet, I haven't really had a reason to build a FRX with liquid boosters or drop tanks. [SBS] = Solid Booster Specifier, syntax is S[BSS].[BC] where [BSS] = Booster Size Specifier (03, 06, 12, 25, 37, and 50 are defined) [BC] = number of boosters of this type Example part numbers: FRX14L2-S06.4: Model year 2014 FRX, with 4x 0.625m SRB and a stretched first stage FRX125r2: Second major design revision of the model year 2015 FRX FRX15r2L1.L2-S06.4: As above, but with both liquid stages stretched and 4x 0.625m SRB added. This variant has enough oomph for a single-launch Mun mission. My current successful spaceplanes are named after various minerals (typos in their names are deliberately preserved across generations), with a short suffix indicating the orbital maneuvering fuel for easy ISRU planning. The previous generation (circa 0.25.x/0.90) used two random nouns followed by a revision code (e.g. "Canada Spark r3"); said generation's cargo spaceplanes evolved organically from the B9 recon drones, and had a B9-derived prefix added before the standard name (e.g. "UAS-10 Bismillah XP").

I sent a mobile MetalOre extraction/smelting vehicle to my Mun base. Due to MechJeb experiencing severe control-loop jitter in differential throttle mode (the landing frame's main fuel tank was at the extreme end for fairing-related reasons), I had to land it by hand. It landed about 13.5km away from the target, and it doesn't have headlights (the built-in ones on the anti-legstrike gear don't work, I have no idea why). Or, to [thread=30031]paraphrase[/thread] [thread=30530]Herbo[/thread] [thread=33845]Kerman[/thread], "Truckin' on the Mun!" (at about 4m/s due to lack of working headlights). Edit: First the truck got stuck in a crater, then something ate my 220k+-line career save's CONTRACTS node. I fixed it by hand-merging a recent backup into persistent.sfs with dev-util/diffuse.

My favorite "hidden gem" isn't even a KSP mod; it's (still) unionfs, which I use to manage mods. Manual mod management via "unzip" and "rm -rf" gets to be a bit of a chore with the number of mods I run (upwards of 120 at a time), and not all of my favorite mods are available through CKAN. To make matters worse, different modders follow different directory-structure conventions for their release packages; ones I have seen include (but are not limited to): Put GameData and Ships into the root of the archive (I call this "canonical form", as it lets me do a simple "unzip ${pkgname}.zip -d ${modname}/" and call it finished) Put GameData and Ships into a directory named after the mod, then put that directory into the root of the archive. Put everything that goes into GameData into the root of the archive, but also put Ships/ in there, too. unionfs lets me canonicalize the mod's directory structure once, then use it in multiple project-specific KSP prefixes without creating additional copies. AIES Aerospace is a close second  it's not on my "must-have" list (as I have been forced to do without it for a long time), but the ultra-thin 1.25m decoupler, radial mini-RTG, and wonderful liquid-fuel engines were worth the wait for 1.04 compatibility.

I tested revision 6 of my new Eve SSTO. Everything was going okay, until MechJeb suddenly decided to land on the opposite side of the planet while less than a kilometer from the ground. I almost salvaged the landing manually, but a non-obvious slope caused the vehicle to fall over. Unreasonably huge picture, taken during final approach.

I had to hand-edit my career-mode save to work around some mod-related weirdness. On a related note, TIL that ShipManifest's crew transfer panel doesn't work on parts that aren't supposed to hold crew, even if the engine wedges a Kerbal into one for a "save $kerbname stranded at $place" contract. edit: The Kerbal was stuck inside a 1.25m diameter x 0.2m thick heat-blocking engine washer (from one of several thermal-management mods, not sure which).

Most of these happened in 0.90: MechJeb smacked an XU-1 Blue Dragon supersonic bomber spyplane "transport" prototype into the hills west of KSC N.E.A.R. + 2200 m/s at 15000m + Split S turn = "Where did the rest of the spaceplane go?" Mun lander landed sideways, smacked into a hill at 150m/s while trying to take off again FRX15 booster prototype slammed into the bottom of the capsule during an abort test

I use MechJeb because it saves me time and effort. I focus on designing stuff, not flying it; every minute of flight-micromanaging saved is a minute I can spend building my Tylo base. Yes, this has severely crippled my ability to respond to emergency situations and control non-MechJeb-compatible craft. The tradeoff became worth it (for me) when I started trying to dock stuff that could never have properly-balanced RCS (e.g. the outer crew tunnels on a "Mars One Crew Manual"-derived Duna mission).

The DropMax has served me well since mid-2014, but it has a few issies: Fission reactor is buried in the middle of the ship, requires a ModuleManager patch (pumpable KSPI UF4 and nuclear waste) for refueling 17 VASIMRs leaves a bit to be desired TWR-wise Argon is heavy and expensive 70 parts and 6 RAM-hungry mods for the ultra-minimalist export version Central VASIMR's protective shroud panels tend to mulch other engines when they decouple (I tried to fix this with a cage, it only made things worse). I spent a good chunk of today working on a launch vehicle (and a badly-done composite picture thereof) for its successor. Meet the SHSLS ThrowMax (huge pictures here and here), SHSLS's answer to the DropMax's many problems. Lessons Learned: Fission reactor located in the nose, right underneath the docking port (EVA refueling not tested) 9 MHD thrusters and 8 hydrogen VASIMRs strike a good balance of TWR and fuel economy Hydrogen is light (a little too light to launch easily, in fact) and dirt cheap Only 53 parts, and much cheaper than the DropMax. Not prone to spontaneous engine destruction

I use Fleas with top-mounted LF+O tanks and fuel lines to uprate my existing launchers for bigger payloads and greater delta-V; I've found the it to be somewhat more cost-effective than the RT-10 and LV-T30 in this role. I've also considered using a single Flea as a crasher stage for a heavy Mun lander, but haven't had time to test this yet..

Stuff I did: Set up a new UnionFS prefix for 1.0 (I manage mods with sys-fs/unionfs-fuse and a few [thread=60412]homebrew shell scripts[/thread]) Attached a big scanner to a tiny satellite bus, then put it into orbit Built and launched the AREVE The Atmospheric Re-Entry Vehicle Experiment (AREVE) is quite simple, both in concept and implementation. The mission profile is as follows: Vertical liftoff Tilt to 80 degrees (equatorial prograde) Jettison LV-T30 boost pods to reduce maximum TWR (central Skipper sustainer engine is kept) Exit atmoshpere, jettison payload fairing At first stage depletion, decouple first stage & start second stage After attaining the desired trajectory, point straight down toward Kerbin & wait for apoapse Expend & decouple liquid upper stage Activate payload RCS, wait for re-entry heating effects Fire payload motor Here's a picture of the AREVE, shortly before splashdown.

Seconding this, the current part-based fairings are a great way to add additional structural support. The design below was inspired by one of the Shuttle-derived expendable proposals, but takes a few design cues from Energia-Polyus.

First successful test flight (without a payload) of the UAS-11 Stardart (craft file), a UAS-10 Bismillah XP clone for 1.25m payloads:

All of my flags relate to my (long-defunct on the forum due to frustration with BBcode, but still releasing stuff on KerbalX) spacecraft company. I start with a SVG template containing the SHSLS logo (less than an hour in Inkscape) and change the black text under the logo as needed. Edit: The background is supposed to be flat white. I tried transparent, but it was unreadable on dark parts and didn't play nicely with FASA's attachable flag plates. The difference in font between the default flag (company logo in flag form) and the department-specific/mission-specific flags is also deliberate. Edit2: I just found the first SHSLS logo while looking in ~/Documents for old stuff to delete. Those of you who saw it on Spaceport may remember it; it had horribly rescaled purple text on an ugly yellow background. Not gonna post it.