Fail-Man 3D

Most of the line endings in UnivDockPorts.cfg appear to be \r\r\n (0x0D 0x0D 0x0A) instead of the Windows-standard \r\n (0x0D 0x0A). I'll test whether or not this makes a difference as soon as KSP finishes loading. Edit: Well, that didn't work. Restoring from backup... Edit v2: Apparently, I'm just as blind as ever.

I've accidentally deleted or reverted numerous flights due to sleep deprivation + muscle memory from the build-test-explode-revert development cycle. There used to be a plugin (for 0.18.x) that did this, but I don't know what happened to it.

Projects DUMBO and TIMBER WIND would like a word with you. Only in real life, or if KSP implements radiation-induced structural damage/crew injuries (the KSP Interstellar mod seems to be laying the groundwork for this...). Or, as someone in the U.S. Army put it, There was actually a proposal for a (manned) Mars lander that used gas-core engines. IIRC the designers picked a gas-core engine so they could vent the fuel instead of waiting for it to cool off after landing. I'll see if I can dig up more info on it.

Check for parts that are clipped into each other. I had a similar-sounding problem (with a spaceplane) that I eventually traced back to clipping-related physics weirdness.

Looks like an out-of-memory error (or just a P/Invoke gone bad) too me, but I have relatively little experience with KSP on Windows. MechJeb tries to dock with the side of the target port, but ORDA works fine (at least on my machine)

Reenactment pics (I forgot to take screenshots at the time) will be added later, once I get some sleepOriginal screenshots have been added, I actually remembered to take some. Built an alternative service module for Bobcat's Soyuz-TMA (FASA Agena aft equipment rack (propulsion, partial RCS, space for solar panels) + upside-down JPLVP Epsilon Post-boost Stage (partial RCS, decoupler) + 2x 0.625m stack batteries clipped into the empty recessed space in the PBS's top, which has room for the batteries but lacks a second node for them.) Played around with the Japanese Launch Vehicle Pack's gigantic SRBs and a few FASA parts. Goals for this project were cost mitigation, safety (structural integrity, <3.5g peak acceleration), precision, and Clean Space Act compliance. All objectives were met, though target altitude range and ascent profile flexibility were reduced (as compared to the baseline Soyuz booster from the Soviet Pack) due to extensive use of SRBs (most of which had almost no fuel to keep acceleration reasonable). Played around with alternate engine loadouts for the FASA Atlas (Atlas A, Atlas A with central SRB, SRBs in place of boost engines + overpowered sustainer engine) Built a 2-seat SSTO with FASA, JPLVP, and KW Rocketry parts. I consider this something of an exploit, since it didn't work with the equivalent World Space H-II parts Designed a new medium-lift liquid-fuelled booster with existing mod parts (FASA engines, tanks, and launch supports; JPLV Pack engines & Fairings). It extends the tower + launch stand setup left over from the aforementioned solid-fuel rocket project, adding a crew elevator (purely cosmetic since there's a payload fairing in the way) and 5 or so new FASA fueling arms. Wrote a ModuleManager config to make the Lionhead Aerospace ATV carry KAS cargo. I settled on "maxSize = 220" based on the Soyuz orbital module (maxSize = 40), but it probably needs some tweaking.

There are actually specialized designs for just such a role (Wikipedia link)

How about custom decouplers with zero ejection force? It might* be possible to make a custom (stack) decoupler for each piece to simulate the appearance of trunnions without the hassle of radial attachment. * Disclaimer: I have never made a single part for KSP, much less a decoupler.

Bad luck. Back up your save now, then revert the flight or load your last quicksave. Other than that, there's not much you can do (except uninstalling mods, getting a better computer, or properly installing texture reduction packs/the Active Texture Management mod)

It makes a twisted sort of sense, if such can be called sense: humans are bad at (or just forget about) light discipline at inopportune times, so why wouldn't other intelligent life forget to turn the lights off (especially when their safety regulations call for warning/navigation lights on spacecraft)?

Disclaimer: this list is extremely me-centric due to lack of experience with 32-bit Windows (I run Win7 64-bit, which maxes out at 4GB instead of 2 or 3* for large-address-aware 32-bit stuff), KMP, or other people's spacecraft. Stuff I'd like to see: FASA: Ever since BobCat added ECLSS support to the Soviet Pack (and I couldn't get rid of it with a custom ModuleManager CFG+deleting the ECLSS DLL), I've switched to FASA's Big Gemini for Kerbin-to-orbit crew transport. 8 Kerbals per launch should also cut down on the amount of on-orbit launcher debris. Kosmos SSPP w/ low-res textures: I make extensive use of Kosmos parts in my space station, crewed lander, and IPV designs. Active Memory Reduction Mod: Should help w/ RAM usage on clients (DXTn-compresses textures as they load). NovaPunch: The tanks aren't as light as the ones in KW Rocketry, but at least NovaPunch has 5m tanks and engines (nice to have, can help reduce vessel part count) Kerbal Joint Reinforcement (depending on how KMP reacts to mixed KJR & non-KJR clients, especially during joint operations): Because placing struts ranges from boring to rage-inducing KSP Interstellar: I only use this for the nuclear reactors, but removing it kills one of the best ships in my IPV program (Grand Tourino-class, powered by a 1.25m KSPI fission reactor). Downsides include a new thermal management system for solar panels & a whole bunch of stateful tech-tree-related stuff, so it probably won't work. Near-Future Propulsion Pack w/ low-res textures: Handy to have for interplanetary ships (especially with KSPI fission reactors) RLA Stockalike: Or anything else that provides a 1.25m to 4x0.625m adapter Porkjet's inflatable modules: Again, nice-to-have for interplanetary stuff (assuming KMP syncs animations, AFAIK the plugin works by reading the current animation state & Kerbal population when you try to add a Kerbal or deflate the module) ORDA: It uses less RCS fuel than MechJeb, and it knows how to dock with the Kosmos APAS-69 (MechJeb tries to dock with the side of the target port for reasons unknown/unfixable by anyone but the Kosmos team). Listed here because, like MechJeb, it uses a few custom parts. Stuff I'll put up with (and maybe even use), but wouldn't ask for: Lazor System: Handy for rescuing EVA'd Kerbals, but "shooting missiles at your buddies" and "long-term playability" tend not to go hand in hand, especially if someone decides to shoot a missile/Sunbeam/etc. at the shared refueling station that took six people and several real-life months of shift work to build. RealChute: I have no experience with it, but I'm planning to install it anyway... SDHI Service Module system: Replaced by FASA's Big Gemini in my space program, but other players might find it useful SDHI FusTek modules: Which version, 3.x release or 4.x dev build? Most parts packs Stuff I wouldn't like to see: FAR: Excessive RAM usage, giant flight data panel blocking my view, rockets spinning out of control KW Rocketry: Has better tanks than NovaPunch, but most of its engines are worse and the textures are huge. Deadly Re-Entry: Burning up on re-entry is so much more stressful than not burning up on re-entry. Lionhead Aerospace's European Pack: Nice to have, but a major RAM hog. Any sort of life-support mod, including ECLSS (therefore no un-modded American Pack or Soviet Pack)

Do any of the landers have enough fuel for a Bop-->Tylo trip? If so, you could park a high-TWR lander (and a small refueling station, if the lander doing the inter-moon crew transfer needs it to get back to Bop) in Tylo orbit while you wait for the Jool-Eeloo transfer window to open.

This isn't your fault. The Mk3 IVA is pre-ModuleManager, so it overwrites stuff in the Squad directory instead of just overriding it at load time. How to fix: Install ModuleManager (1.5 or newer) Unzip the Mk3 IVA to somewhere other than your KSP directory. Delete the resulting GameData directory (not the one in your KSP dir!) Merge the Internals folder into KSP_win/Internals (or _mac or _linux). Linux & Mac users may want to use rsync for this. Final path should look like KSP_win/Internals/Spaces/GenericSpace3TTupgrade Save the following (not tested b/c I'm low on RAM, should work w/ MM1.5) to a new CFG file in GameData[noparse]@PART[*]:HAS[@INTERNAL[GenericSpace3]] { @INTERNAL { @name = GenericSpace3TTUPGRADE } }[/noparse] Restart KSP (don't just reload all parts from the debug menu, ModuleManager does not like that...)

Will it work with the Big Gemini docking compartment? The weight savings (as compared to fairing base plate + Kosmos APAS-69) would be significant. On a related note, is the Big G docking compartment supposed to have two size0 docking nodes and no size1 nodes now? IIRC the older versions had a size0 node and a size1 node... Confirmed in 3.501 (latest on Spaceport, as of when I posted this), it just needs category = Utility in the part's config file. Someone mentioned this earlier, but I can't find the post now...

[thread=24551]snjo's Firespitter pack[/thread] has what you want, and the DLL it uses is required by a bunch of other stuff.

I'm tired of hard-rebooting after a few minutes of 0.22; here's hoping that 0.23 fixes this so I don't have to downgrade everything else...

Allow the user to specify an exact amount of $Resource to transfer. Kerbals are indivisible (short of the Kethane blender... yuck), LiquidFuel is not. Pick a license, slap a legal disclaimer on it and release a beta version?

Not sure if this qualifies, but I like to put fuel tanks on top of my SRBs... This is a(n untested) stockalike mock-up of my proven Archer-2502 launch vehicle. The Archer series use SRB-mounted liquid fuel tanks to keep the core stage topped off during ascent.

Film cameras with ejectable return capsules (for lower tech levels)? The last time I tried this was in 0.20.x with the Lionhead Aerospace telescope (or one using the same/a similar model). I had horrible jitter problems that I blame on floating-point errors. This would be a problem for sun-observing telescopes, unless you include special parts that return a fully black image when not pointed at the sun... Suggestion: make front-of-mirror sensors non-removable, but package some or all behind-mirror sensors in MIX drawers (or, on larger telescopes, full FLEXracks) and add the appropriate bays to some of the body pieces.

I've recently started using unionfs-fuse to manage addons, it helps take the pain out of keeping multiple modded copies of KSP up to date and in sync with each other. It also eliminates the overhead (on non-deduplicating filesystems) of having multiple copies of KSP. Example: I have one KSP prefix with regular ModularFuels (to build stuff for release on Spaceport), and another with Realistic ModularFuels (for actually playing the game). The directory structure would be set up as follows: bases/ bases/KSP_linux/#contents of Squad's ksp-linux-$version.zip, the KSP executable lives here bases/ModularFuels-regular/GameData/ModularFuels/ # contents of the Modular Fuels distribution zip bases/ModularFuels-realistic/GameData/ModularFuels/ # contents of the Realistic Modular Fuels distribution zip prefixes/realistic/ # UnionFS storage dir for KSP with realistic modular fuels prefixes/normal/ # UnionFS storage dir for KSP with normal modular fuels mounts/realistic/ # mountpoint for realistic mounts/normal/ # mountpoint for normal realistic.sh # bash script to handle RealisticFuels mounting normal.sh # another one for normal ModularFuels The source of realistic.sh (public-domain): #!/bin/bash KSPPREFIX="realistic" KSPDIR="${HOME}/.local/ksp022" # initial read-write entry for the prefix must NOT be the same as the mountpoint or *BAD THINGS* HAPPEN! KSPPATH="${KSPDIR}/prefixes/${KSPPREFIX}=RW" # UnionFS writes all changes to this dir, if this==mountpoint then an infinite loop happens & hangs the unionfs driver (requires reboot to fix) KSPPATH+=":${KSPDIR}/bases/ModularFuels-realistic=RO" # load realistic modular fuels overlay KSPPATH+=":${KSPDIR}/bases/KSP_linux=RO" # apply all the previous lines to this base... /usr/bin/unionfs -o default_permissions,use_ino \ -o cow,statfs_omit_ro \ "${KSPPATH}" \ "${KSPDIR}/mounts/${KSPPREFIX}" # ...and mount it here (must NOT be the same as the read-write prefix!) When done, I unmount with fusermount -u ~/.local/ksp022/mounts/realistic

Adding a stock solar panel fixed this for me. Edit: Just noticed that you have the transmitter in relay mode instead of transmit mode. Try changing it to transmit mode.

Views differ on whether or not using mods = cheating. Someone else on the forums (can't remember who) said that the best way to learn gravity turns is to watch MechJeb and try to imitate it, and I wholeheartedly agree. I only consider debug-menu/HyperEdit/etc. to be "cheating" if it has a permanent effect on the save's persistence files (e.g. launching my "Grand Tourino" IPV with HyperEdit and returning to the Space Center is cheating, but testing it on-orbit for wobble and then reverting to the VAB isn't). tl;dr Mods add flexibility to the game, whether or not using mods is "cheating" all comes down to how you use them (and how you define "cheating":P). Don't be afraid to experiment, you might miss out on something useful, challenging, and/or fun.

For stock and RLA ion engines, this is true. However, the Near-Future Propulsion Pack has a game-breakingly efficient quad-grid ion engine. 12 of 'em + a KSP Interstellar nuclear reactor and a hitchhiker can gives a TWR of 0.43ish, making them suitable for single-shot transfers to darn near anywhere from LKO. Really big (1918x994) picture

Are you running a non-multilib system? If so, you'll need to install 32-bit compatibility libraries (it's a pain) before running 32-bit KSP. Otherwise, try to run the 32-bit version of KSP from the command line, then upload ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log somewhere and post a link to it. There's also a binary patch to KSP.x86_64 floating around earlier in this thread that solved the pointer-truncation-related crashes I was having with 0.22 (it disables some 32-bit-only code in libpng that shouldn't have been enabled for 64-bit builds, search the forums for "xxd")

Whether or not methane will be usable in engines, why not allow pyrolysis* to hydrogen and carbon? The converter could store PyrolyticCarbon as a non-transferrable resource, with conversion efficiency decreasing as carbon accumulates; a Kerbal will eventually have to EVA to go and chisel the carbon out (PyrolyticCarbon-->Garbage, initiated from right-click menu, canceled if Kerbal drifts beyond a certain minimum distance). Maybe even unlock a Bosch reactor at a higher tech node (draws more power than pyrolysis reactor alone, but still less then Sabatier reactor + pyrolysis chamber; doesn't have to be manually cleaned as often; produces water+ElementalCarbon instead of oxygen+methane). * This should, ideally, require a large amount of power and generate lots of waste heat. KSP Interstellar already has a fairly mature implementation of thermal power & waste heat, so I'd suggest getting permission to integrate with it.