NathanKell

Realism Overhaul requires Procedural Parts. When you have placed a procedural RF tank, right-click and change its type to ServiceModule. Those are pressurized and will accept all fuels.

The only time I've heard LOX talked about for NTR is for LANTR, LOX-Augmented NTR. Because LH2 in an NTR is very efficient but low-thrust, there was a proposal (for Lunox, if anyone remembers Fusty's Munox command pod it was a real thing...) to augment the NTR by pumping LOX into the exhaust, which would react with the LH2 and basically make a hybrid hydrolox/nuclear thermal engine with lower (500-600s IIRC) Isp but much, much higher thrust. There's another problem beyond political with NTR: LH2 is nasty stuff to use, both for its lack of density and its strongly cryogenic nature (high boiloff problems). See this series of posts by Bob Braeunig. Details there, summary a few posts later, Methane gets added a few posts down, and summary at the bottom of the page. tl;dr Liquid Methane NTR is probably the best compromise between stage dry mass, Isp, thrust, and boiloff. Also, Renegade: do *not* look into the abyss of unreality that is ion-powered crewed landers. It hurts too much.

Dr. Death: wait, the game did *not* crash at the loading screen? That's what your log was showing. Also, there's no point in two uploads because *the MM patch does work* with the exception of one or two engines where there was an order of operations problem. But just so there is a single confirmed working patch I will package an archive...

Ubuntu probably remains the simplest and easiest to use, and there's tons of resources for safely installing it on an existing windows box

GregroxMun: I don't read regex as suggesting making everything real-sized, but using non-insane densities for planets. Right now some planets in KSP are approach star levels of density. That's...not exactly a good way to teach kids about space travel. I think also an argument could be made for using the real solar system as an option in the KSP.edu version, since otherwise you will be giving children a quite-wrong impression of how hard or easy spaceflight actually is.

Putting aside for now questions of bundling things, I want to talk up the advantages of Module Manager. As of MM 2.x, it's an extremely powerful tool. In particular, it will allow you to make changes based on what people have installed, so that (as you mentioned some flexibility in re: which mods users would have installed) you could tailor the experience to the install. The wildcard system, combined with HAS, makes using MM actually easier than manually editing cfg files. It also makes updates painless, since you don't have to redo your changes and because (if you're using wildcards) new parts will be automatically supported by your existing changes. Realism Overhaul would be *harder* to maintain if we bundled everything and edited cfgs; it would be a *lot* harder. It would also be far less flexible.

Streetwind: Heh. Going off memory, I *think* the Russians reported testing their NTR (RD-0410). aaaand Astronautix says it was tested in the 80s and was considered operational. 1.8 TWR, 910s vacuum, 35.3kN thrust (so 2 tons). Alas I don't have more data on NERVA; actually your best bet would be Starwaster, who knows a good bit more about NTRs than I do. Also, to the people mentioning Timberwind: you understand that that was only for use once there were missiles in flight, right? It was for an environment so saturated with radiation (and so desperate) that using it would make things better (maybe some of us survive!) not worse.

Go here: https://github.com/rbray89/EnvironmentalVisualEnhancements/tree/Overhaul Click x64 release or x86 release depending on whether you use 64bit KSP or not Click Raw, the file will download. Extract GameData, merge into KSP folder.

Not only is it not showing what mod is causing it, mods aren't causing it. Or rather, their mere presence (not any particular mod) is showcasing bugs in the stock code. Install linux, the KSP x64 for that is stable.

pingopete: wowsers! That may finally make me install linux for stable x64... rbray89: There's a few PQSMods that could really use a makeover, certainly. The vertex heightmap ones should be remade to support 16bit heightmaps. The vertex color one should be killed dead, replaced with a modified shader. The LandControl one should support biome-specified (or really, just texture-specified, and you can reuse the biome texture) land classes. Scatter should be made detail-texture-dependent, so you can have trees in the foresty area of the detail texture, or buildings in the city area of the city texture. Anyway, drop by #kspmodders again some time (ping me) and we should hash this out...

Looks great! Definitely like the idea of the hatch heatshield, and Galileo's. A suggestion: maybe the bucket-style heat shield of CORONA / Discoverer?

Nope, none of that has anything to do with why you crashed; that's all detritus from the Unity player closing unexpectedly. To see what *actually* caused the crash, look at the stack trace at the bottom of output_log.txt. In this case, it's all within the (obfuscated) stock code, and therefore yet another "KSP Windows x64 is just not stable, and doesn't deal with exceptions properly" crash.

You're adjusting the Additional Height slider at the top, not the height slider in the middle.

No, not yet. Ratzap is hard at work getting it to do so, however.

Ok, it's still the error I thought it was. Let me package up a new version of AJE that should finally put this to rest...for now, you can manually go through the cfgs in the AJE folder and subfolders, and replace Kerosene with LiquidFuel, LiquidH2 with LiquidFuel, and LiquidOxygen with Oxidizer.

Sadly I have had to remove the link to this excellent addon due to lack of permission to use the models; let's hope Desolator can secure permission to use the models soon and can put it back!

Yeah, that log confirms it's a KSP 0.24.2 Windows x64 issue, not anything else; the *entire* stacktrace is within stock code. Your best bet then will be to dual-boot into Linux (i.e. install it side-by-side with Windows) and use KSP 0.24.2 Linux x64 (which is stable).

Dr Death: then, as I have said a bunch of times, I need log. Renegade: as you can see, bit of an issue with the MM patch, although you should be safe if you follow the above directions in moving it (so it runs *after* all the other stuff), or even moving it out and putting it in a folder in GameData that starts with z (like zFix).

KSP Win x64 is very unstable. Try to replicate in 32bit. Also, post the *entire* output log (from the KSP_Data folder) when you post log; snippets are almost never enough for diagnosing things. Note it will be too big to fit in a post, so upload it to dropbox. And hey, welcome to the forums!

How so? Then RSS could use it (Biome-based LandControl rather than lat/long/alt-based landcontrol. The latter is not sufficient for RSS, which is why it's disabled; the former is what I would *love* for RSS but vertex colormaps had to suffice.)

Could it be that the first frame it renders, only the AFG is visible and the PQS isn't, and then it doesn't render again for a while?

You can either use a method like TaranisElsu does in TAC Life Support (i.e. do everything on unpack) or you can use a method like asmi does for ECLSS where resources are actually tracked and changed per tick for unloaded vessels.

Can you post a craft and modlist? That sound like a weird issue.

They're not compatible.

Ok, examining your mod list and report again, for once the logs aren't necessary, and the fault is mine. Here's what you need to do. In your AJE folder, make a new folder called zFinal Move the zzWildcards.cfg file into the new zFinal folder Problem should be solved.