Starman4308

You do realize protein folding is driven by hydrophobic effects, right? Most proteins will have their polar side chains exposed to solvent, with a hydrophobic core providing stability to the fold. The intra-chain hydrogen bonds, such as those characterizing alpha-helices and beta-sheets, is barely, if at all, more favorable than hydrogen bonding with water. If there is life living in a methane environment, I'd expect it be invert that, and have hydrophilic, polar/charged cores to its macromolecules, with hydrophobic groups surface-exposed to the methane. The worst solvent for life would be something like a soap, which can dissolve across a very wide spectrum of hydrophilicities. As to Venus: on the surface, that's a flat-out "no"; the temperatures there would rip any non-covalent interaction, and many covalent interactions, to shreds. Maybe in the clouds, but I'm not so sure about that one. At least on Titan, there is a condensed-phase substrate that won't slaughter any organism that comes across it.

So, NecroBones, do you have the time to either figure out how to re-configure the OMS systems to operate purely as RCS thrusters and/or make oversized linear RCS ports? It'd be useful for ullage on Real Fuels rockets, and it's kinda annoying to sprinkle the bottom of my second stages with dozens of the stock linear RCS ports.

Because MechVal doesn't do what MJ does, and MJ doesn't do what MV does. Most of what's shown on the screenshot is MechJeb, and the author makes no claim that it is part of MechVal; MechVal is a set of kOS scripts used to split up the MJ maneuver node into a bunch of periapsis kicks. To the OP: It would probably be less confusing if the MechJeb windows were removed from the screenshot, so it's showing primarily just the resultant maneuver nodes.

Okay, just to be sure: you are aware that RAM is a physical component of your computer, the part that holds all the information the computer is currently working with, correct? You can't get more RAM out of your computer; you can add RAM (up to a motherboard/OS-dependent limit), and you can do things like close unnecessary programs to free up RAM for KSP, but what your computer has is all it has. Also, "more RAM = more stable" is rather incorrect; you need enough RAM, and a bit more won't hurt (to reduce the frequency of garbage collection), but after a point, adding RAM will do precisely nothing for the performance or stability of your game. Your crashes are most likely due to bugs in the code and/or weirdnesses in your save file/mods, and performance issues are usually CPU-dependent for KSP.

At least from the perspective of a relatively casual player: mostly because it exists as a GitHub repo with no installation instructions, with the last commit six months ago, and no mention whatsoever about 1.1.2 or 1.1.3 compatibility. I know it's kind of a band-aid fix (Karbonite assumed to be whatever combination of NH3, H2O, and CO2 it needs to be), but I did develop a Karbonite config here: A question I wanted to ask quick: is the reason that most of the hydrolox configs run hydrogen-rich (by molar rate, not by mass) because hydrogen is a nice, lightweight gas to be throwing out the exhaust (higher velocity at given temperature), and complete combustion would lead to excessive combustion chamber temperatures?

You're going to need an engine configuration, either Realism Overhaul or Real Fuels-Stockalike. You're also going to need Kopernicus for RSS, which carries out the rescaling. By themselves, RSS just makes the solar system realistic, and Real Fuels just adds the propellants and some of the mechanisms such as ullage simulation. If you're going for Realism Overhaul, you're almost certainly going to want to do that via CKAN, due to all the dependencies involved. EDIT: To clarify a bit: RSS has configurations for Kopernicus which swap out the different planets for real ones. Real Fuels has configurations for new propellants and mechanisms such as ullage. Real Fuels-Stockalike adds configurations for engines to go along with the new fuels. Realism Overhaul does something similar, but swaps out a lot of default KSP parts for real-world parts, nerfs reaction wheels, and a million other things for a much more realistic package. Personally, I go for a midway point with KScale64, Real Fuels-Stockalike, RemoteTech, etc.

Well, on my end, having logged possibly > 1000 hours, I've planned multiple Duna missions, and landed on Duna precisely... once. My biggest problem is just restarting it all; something happens like I decide to go whole-hog on realism, or it's been a while and I'd rather restart, or major performance improvements come along that make upgrading KSP (and thus breaking my many mods to oblivion) worth it, or I get frustrated by bugs. I'm pretty sure I'm on my seventh iteration of trying to get this all working. I'm trying to be systematic about it this time around, doing things like keeping a KSP folder around just with those mods I know to be stable. Hopefully this is the second time I get to Duna; I'm planning on just skipping 1.2.

The node does attach if you flip it upside-down. From there, you can rotate the part 180 degrees so it's not poking into your vessel. Otherwise: if you're still up to it, could you maybe add a midrange directional antenna, one somewhere in between the existing helical antenna and the big interplanetary antennae? At least with the setup I've got*, nothing but those big interplanetary antennae will reach from low Jool orbit to the outer Jool moons, and those antennae have such a narrow beam that they're hard to use for anything but interplanetary communications. *KScale64, etc; it probably holds for stock but I'm not quite as sure. If it's not obvious, I'm trying to set up relay satellites around every major body.

Did you install SigmaDimensions? It's a KScale64 dependency, but the mod author, last I checked, refused to have it hosted on CKAN. As such, that has to be installed manually. Also note that what comes off CKAN doesn't seem to contain all the latest files hosted on the KScale64 GitHub, the lack of which make atmospheric reentry extraordinarily impractical*. *You probably want to grab at least the ProcParts-SizeLims.cfg, HeatTweak, and play about with the DeadlyReentry settings (what I have below has worked so far). // RSS specific tweaks (untested in KSP 1.0.5!) @PART[*]:HAS[@MODULE[ModuleHeatShield]]:AFTER[DeadlyReentry] { @MODULE[ModuleHeatShield] { @lossExp *= 1.05 @lossConst *= 0.18 @pyrolysisLossFactor *= 2.4 } }

@NathanKell, I am trying to make sense of how the code is arriving at a clearly broken result, without having figured out where the KSP side code is. No need to be snippy. I've tested one other thing out, by the way, which was to set the egg fairing's mass to 1000 tonnes in the .cfg (where it was previously 0). The result is still correct, and a rocket flies as it should, so again, somehow, there must be a difference in how cost and mass are being handled.

There is something really wonky going on. As the code is, it was returning negative costs, an obviously incorrect result that was almost certainly caused by subtracting a base mass. Again, it seems to behave properly for mass but not for cost Testing out a 0.75m fairing base underneath an OKTO and a conic fairing: Without fairing sides: 470 cost (450 for OKTO, +115 for PF cost, -100 for base cost) 0.115t (0.1 for OKTO, 0.015 for PF mass, seems about right) With 2 fairing sides: -1102 cost (450 for OKTO, +115 + 32 for PF cost, (-100 -1600) for base cost, probably a roundoff error to get to -1102) 0.122t (0.1 for OKTO, 0.015t + 0.006493t for PF mass, probable roundoff error to get to 0.122t) EDIT: The primary mysteries to me is why the cost isn't -1302, as the subtracted base cost should be 100 (fairing base) + 200 (side base) + 2*800 ("missing" ablative shielding resources), and why the masses seem correct with a calculation that doesn't work for cost.

I'm pretty sure I've tracked down the source of that issue. It's from, A, a Deadly Reentry config which adds 800 cost to the part*, and B, what I believe to be a coding goof made when NathanKell fixed the fairing masses. Code-wise, the issue is at all instances of 'public float GetModuleCost(float defcost, ModifierStagingSituation sit)'; that method subtracts defcost when it should add defcost. I'm 99% sure I know why it crept in, too; Nathan probably fixed the mass by subtracting base mass, which is how it should be (mass should be area * density/area), and then applied the same "fix" to cost, which is a different case (which should be base cost + (cost/area * area)). I'd submit the pull request myself, but, A, I have GitHub issues (can't have a separate personal account for KSP modding and a professional account), and B, I have only limited capacity to test it (I've tried to compile the .dll locally, and the cost works... but then other parts of the mod break). *That solves an issue with how KSP calculates price costs; the "cost" field in a config is for a fully loaded tank. So, when DRE adds capacity for 800 funds' worth of ablative shielding to the fairing, it needs to add 800 funds to the base cost, so the fairing doesn't wind up costing -700 when empty of ablator. EDIT: Also, I double-checked, the mass fix is working as intended, so kudos to NathanKell there. EDIT 2: Also, if/when it gets fixed, would you mind releasing it for both 1.1.2 and 1.1.3? I'm still on 1.1.2, as not everything I want is updated to 1.1.3 yet. Again, I haven't figured out how to successfully compile the mod, probably because I'm trying to use VS 2013 and you're using a .bat script.

I haven't really played with that parts pack, but I'm not sure Real Scale Boosters even has something I'd use for a Mun lander. I usually wind up using one of the 0.625m Spark engines from NecroBones's Modular Rocket Systems pack (maybe an Ant for particularly small landers or a Terrier for particularly large ones); that's around the perfect size for this sort of work. And since low Munar orbit is about 1.4 km/s, 1.8 km/s seems about right, unless you have really low TWR. In any case; are you using the Stockalike configs for RealFuels? I'm not sure RF does anything by itself.

Is there anybody else having severe overheating problems? I've tried a number of things to fix it, but I can't reenter without heatshields exploding, even from relatively gentle profiles (i.e. 10,000 apo/30 peri, w/ some lift). These are the sorts of reentry profiles which worked for me back in 1.0.5. EDIT: Finally tracked down the major issues (at least as they apply to what's currently available via CKAN):it doesn't use any aero physics tweaks, and it sets heatshield max temps to 1800, leading to very, very, very crispy heatshields at 64k reentry speeds. I'm not sure why there's such a discrepancy between what's on CKAN and what's on the GitHub repository, but mangling out sections of RSS configs fixes things; I'm guessing the configs on GitHub will do so as well. EDIT THE SECOND: Also, just going to say: with the non-flat terrain, and EVE installed? 64k is beautiful.

So, a big favor (getting back into KSP/64k): is there an explanation anywhere of the math and variables behind simulating heating? I'm trying to debug some issues on overheating during reentry in a 64k installation, and right now, I have little idea what I'm even looking at. EDIT: No longer urgent; figured out what was going on (CKAN version of 64k lacks some essential configs).

I accepted a contract to place a satellite in solar orbit without looking at the fine print. The target has a periapsis near Kerbin and an apoapsis a bit past Duna... and an inclination of 150 degrees. Given that I'm using the 6.4k mod (which scales up the Kerbin system by 6.4x), if I tried to launch straight from Kerbin, I'd be looking at probably ~80 km/s of delta-V, which basically makes it flat-out impossible. Right now, my thinking is to wait until I have nukes and ions, and then set up a Jool intercept and make a burn at Jool periapsis (combined with the slingshot) to make the inclination change. Are there any other tricks you guys can think of? The other possibility I can think of is a Jool-assisted bielliptic transfer, but that'd take a hilariously long time (even without that, I'll probably need to edit the save game to give myself enough time on the contract). The alternative, of course, is to bite the failure penalty (or cheat and use Hyperedit), but it's such an interesting challenge that I want to try it anyways. EDIT: To be perfectly clear, 80 km/s is "I perform almost the entire maneuver straight from Kerbin orbit"; I suspect it'll be a fair bit more reasonable by abusing Jool... at least for certain definitions of "reasonable" which probably do not include making a profit on this mission.

Two possibilities I can think of: #1: You haven't upgraded the Tracking Center; a level 2 tracking center is necessary for patched conics. #2: If you are using a Kopernicus-based mod, you might actually be exiting to solar orbit if the Mun is very close to the edge of Kerbin's SOI. I'm pretty sure it's happened before when a modder forgot to update Kerbin's SOI.

Bearing in mind I haven't really tried launching from a high-latitude site... I suspect what you will want to do is launch when the space center is just a little bit ahead of the Mun/Minmus (or 180 degrees from there, working out similarly). The thing is: KSC will be approximately at the highest-latitude point of the orbit, 90 degrees away from the equatorial AN/DN, and you will want your transfer apoapsis to be near the equatorial AN/DN, because the Mun/Minmus have very low inclinations (and thus your transfer AN/DN will be near or at the equatorial AN/DN). A little bit ahead is probably preferable, both so you can wait until the optimal transfer, and so that you encounter the AN/DN before you enter the lunar SOI. So: AN is ~90 degrees behind the target. Initial KSC location is approximately underneath the target, as it will be the highest-latitude point of your orbit (and thus 90 degrees away from AN/DN). DN, and the transfer apoapsis, is 90 degrees ahead of the target. Lunar encounter is approximately 90 degrees ahead of the target's current location; it's a bit of a rule of thumb for lunar transfers (although if I did the math right, one would start about 116 degrees behind for a very small moon very far away from the parent body). Alternately, what you could do is a dog-leg; launch high and southeast to an apoapsis above the equator, drift until you're near the equator, and then burn northeast into an equatorial orbit.

One other interesting benefit of the ridiculously heavy stock tanks and engines is that it encourages creative staging techniques like asparagus and twisted candle. Realistic tank/engine masses make it much less urgent to stage. For all that I go in for the realistic side of things, I will admit stock's not all bad.

There's an archive of prior releases on Github. Git is wonderful, and Github is mostly wonderful (minus a few annoyances). EDIT: Also, if you're looking for 0.25 releases, CKAN should give you access to 0.25 mods when you're installing on a 0.25 installation.

Straight up-and-down is going to fry your reentry vehicle. Put some horizontal velocity on it, and you can abuse a combination of orbital mechanics and a lifting reentry to keep your vertical velocity low. To clarify on the lifting reentry part: if your capsule is pointed above atmospheric retrograde*, FAR will give your capsule a bit of lift. 2-5 degrees usually does a decent job. One way to do it very efficiently is to have an asymmetric capsule. If your center-of-mass is above the midline, atmospheric drag will naturally tend to pull your reentry vehicle to a proper lifting reentry. This is important in the real world, where reaction wheels are very limited, because you can control that with roll, instead of struggling with brute-force pitch. *Ensure your velocity display is set to surface.

It won't help your cause that the SpaceY engines will still have abysmal stock-like TWR numbers, on account of RO not having a configuration for SpaceY engines. At least you'd be enjoying the benefits of magical stock LF/O with realistic tank masses.

The parts should wind up with a giant "NOT SUPPORTED BY RO" flag anyways. If a part's not configured for RO, they're not going to play nicely. I'm not particularly familiar with the process of RO-ifying parts, but there'd probably be a lot of tuning of engines to fit a real-world niche. The stockalike configs for RF do have SpaceY engines, but I'm pretty sure they're not configured for RO.

Not necessarily. You'll just regrow those same stems next year, so the CO2 released by decay gets absorbed into the next year's crop. Cellulosic biofuels are probably in the end a good idea, I'm just concerned that it might cause a net flux of nutrients from farms to the processing plants. An ideal process would let you extract the phosphorous, nitrogen, and other useful things and return it as fertilizer.

No, that's where you want the discussion to begin. To me, "because it would be impressive" is not a good rationale. I'm not arguing against that. I'm arguing against the need to send men there. A meteorologist is perfectly capable of looking at a camera feed, and while sample contamination could be an issue, it is almost certainly cheaper to send ten duplicate unmanned missions than a single manned mission. Rovers would be an entirely separate question on account of the incredible temperature and pressure on Venus's surface. I'm not sure we even have electronics which work at these temperatures; without that, we would need sophisticated insulation and active cooling, etc. Regardless, if we can operate Mars rovers from Earth, we can certainly operate Venus rovers from Earth: the distance is shorter, and the additional complications of Venus operation are all independent of whether we have a short or long communication loop. Except, you know, the whole "craft must remain proof against sulfuric acid after months in space" thing.