NathanKell

IIRC a number of probes did carry them; thus I kept them, though gave them far, far reduced values. Probably best to remove them from pods though.

That's...very strange. Never heard of that. Let me know if it happens again.

You can add the AblativeShielding RESOURCE block and the ModuleHeatSheild MODULE block (from a heatshield) to the VA's part.cfg

Based off this site: http://alternatewars.com/BBOW/Boosters/Titan/Titan_III.htm

Final is used since RO modifies heatshields of pods that already have heatshields added via DeadlyReentry.

cubetronic: #1 is a known issue that I will try to deal with when I deal more with PQS after .23 #2 I will also look into; your finding that there's a specific level of zoom at which the orbit line switches is actually very helpful to me, and gives me a place to start investigating. Cesrate: Known issue with KSP; Squad is fixing it. The workaround is to somehow load flight again (one was is to revert to VAB and then launch again, then revert again, or F9 as Starwaster says). Note that simply reverting is not enough; you need to reinitialize the camera by loading flight again. That's why ending flight, or reverting to VAB, won't work alone.

1. Weird. I don't see what's wrong here. Sarbian or someone else may have a better idea. 2. I suggest leaving as is. TACLS auto-adds life support to all crew-carrying modules if it's not present, and then will also add (set?) some default resource amounts. This way you have complete control. re: further-above post, great @ energy usage! Hurrah. As I may have mentioned before, I'm loathe to remove LS configs, because then capsule mass will be messed up. As it stands, Gemini is kilogram-perfect; I would have to change part mass as well as life support resources if I had a different life support file. Now, I guess I could just have both the LS resources/modules and @mass in each LS file, and no @mass in the main file?

mys_721tx: It already is scrollable. Make sure you have the latest release of MFS. The bar on the right of the MFS window scrolls up and down.

1. Sorry, that came out a bit harsh. Unintended. 2. Uh, weird. Make sure it's using the right resource names, and no parts being given MFTs already have them. But it's really more so you can see how it's done, or at any rate how I decided to do it when I used TACLS. Also: confirmed solar panel problem. Dangit, thought I fixed them all. Pfui.

Yeah, it's not a question of credit, it's a question of respecting the author's wishes, and this author wishes that anyone seeking to change or redistribute the work seek permission first. You can (AFAIK) definitely put up MM patch code. You can't put up an altered (or not) full part cfg derived from the original work however.

Your MM patches are fine, btw; it's only redistributing original, and/or changed, files, that's an issue (though one hopefully which permission will resolve!)

amo28: cool! Do you have even rough figures on the square-meterage of the NFP panels? jrandom: you have that resource block sitting all alone, rather than inside the @MODULE[ModuleCommand] block. Also, the [] syntax is for when modifying, not when adding. That's why it's messing up. You need to follow exactly the form I gave on the MM thread (reposted here): @PART[*whateverETC] { @MODULE[ModuleCommand] { RESOURCE { name = ElectricCharge rate = 1.0 // 0.5 for avionics, 0.1666666 for operation per kerbal } } } Regarding TACLS, there's a TAC_LS.cfg floating around the end of the TAC LS thread that I made and someone modified. You will also need to change the consumption rates in the LifeSupport.cfg file (in plugindata, created on first run with TACLS). Make sure that consumption * density * 86400 matches tons/day use of each resource, and that BaseElectricityConsumptionRate = consumption_for_pod_in_kW // a constant, no matter the number of kerbals in it ElectricityConsumptionRate = consumption_for_each_kerbal_in_kW Also for obvious reasons make sure that the total mass produced by the production rates equals the total mass consumed by the consumption rates

That's pretty awesome. And wow, now it's looking more like an F-14 cockpit than F-4J. Though...hate to be That Dude, but do you have permission from Sam Hall to modify and redistribute? The license explicitly requires permission to do so.

mys_721tx, there's a config of mine floating around the TAC LS thread. You might like that one. White Owl: will do.

Zander: Are you using the heat shields patch from Realism Overhaul, like the OP says?

Transtage: 12.247 tons wet, 1.95t dry, 71.17kN thrust @ 311s Isp Centaur D (used with Titan IIIE): 16.258t wet, 2.631t dry, 131.22kN thrust @ 444s Isp Note that Transtage is not a type of stage, but a name for one, like Centaur or IUS or Altair. It was, however, designed by Martin Marietta (manufacturer of the Titan) only for the Titan, and is thus sometimes called the Titan Transtage. Both it and the Centaur were planned for use in Circumlunar Gemini missions. With the Transtage, they would launch a lunar flyby Gemini spacecraft atop a Titan IIIC (or M?) with a Transtage upper stage, but the Titan III-2 stage would handle insertion. They would also launch a second Titan III with no payload, just a Transtage with a docking adapter. Gemini would dock to the second Transtage. Combined, the two Transtages would be enough for TLI. The high energy Centaur was sufficient for TLI on its own, but again EOR profile would be needed; Gemini would be launched by itself on a Titan II GLV, and then dock to a Centaur launched by something else (IIIM-Centaur perhaps?). This would require a similar docking adapter for the Centaur's nose as the second Transtage needed. Now, after that does of realism pedantry, gotta say I nonetheless love the paintjob. Especially since Gemini was proposed as a lunar lifeboat for Apollo. EDIT: Oh, and yes, the prior 6-segment-looking SRM is indeed correct for the IIIC's five segment UA1205. One segment isn't really a solid fuel segment. This one works as a UA1204, which they were going to use for Dynasoar launchers IIRC.

Post them. I'm sure someone would volunteer to convert them.

Thalur: I'm afraid that's definitely an installation issue. The telltale sign is that you have two whole Modular Engines info blocks in your info window. It's not like engines can be more than one type. Like it says in the OP, you need to delete ModularFuelTanks/RealFuels/Engines.cfg before installing Realism Overhaul (which includes its own engine configs). Aazard: Do you have the mods from the second post of the RO thread? I haven't added RealChutes there, but the rest should be good stuff.

There isn't any, stock. Instead do: @PART[*]:HAS[@MODULE[ModuleCommand],#CrewCapacity[3]]:Final { @MODULE[ModuleCommand] { RESOURCE { name = ElectricCharge rate = 1 // 0.5 for avionics, 0.1666666 for operation per kerbal } } } (Also I changed it to avionics, since the command module is avionics, and RT2 antenna module would represent comms. Plus, where's the extra 1kW coming from? It should be ~2EC/sec usage for a 3-person pod, IMO.)

By increasing the part's maxTemp. Note that most stock parts have their maxTemp changed in DeadlyReentry/DeadlyReentry.cfg so look for the part there first.

Well crap. I'll check.

It's not even the textures, actually, it's more likely the Voronoi craters. They are EXPENSIVE--when I upped the frequency for the craters for the Mun (for RSS), it used up 700MB (!) of RAM. That's why I didn't change them. And Krag's adding them to the new planets.

Use RealChutes.

Because there is no RESOURCE block to change. They exist only for the unmanned pods where command modules cost EC; manned pods' command modules don't. % was created for just this reason (create-or-change) but above SFJackBauer mentions issues with creating subnodes.

Greys has been looking into real capacity as well, and MFS will eventually switch to it. It's just that the 80% guesstimate works ok for most situations.