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.