PetWolverine

CRP isn't listed as a dependency, but a few listed mods came with CRP, so I had it. Just to be sure, I just got the most recent version from your link, and it didn't change anything.

I'm having trouble getting KSP to start up without hanging with RO installed. With just RO and its dependencies (none of the recommended or suggested mods), KSP hangs during startup while loading RealismOverhaul/Parts/WACCorporal/TinyTim/TinyTim/TinyTim. When I remove WACCorporal (TinyTim is the only thing in there), it hangs instead while loading Squad/Parts/Engine/MassiveSRB/part/MassiveBooster. When I remove the RealismOverhaul directory, leaving everything it depends on, the game starts right up. It's using 1775 MB when it hangs, and continues to use a little bit of CPU. The last bit of my KSP.log: [LOG 12:15:49.432] *RF* Loading RFSETTINGS global settings [ERR 12:15:49.435] Cannot find a PartModule of typename 'ReflectiveShaderModule' [LOG 12:15:49.459] [MFS] Loading global settings [WRN 12:15:49.475] [MFS] Ignored duplicate definition of TANK of type Hydrogen Please let me know if I can provide any more information to help with debugging this. By the way, this is on a fresh install of KSP 32-bit on Linux. I started with 64-bit, with all of the recommended mods and some of my own picks, not to mention the huge RSS textures, and whittled it down from there; once I identified RO as a suspect I started from scratch, added the dependencies, launched the game, added RO, and watched it hang. Then I removed RO again and added back in all of the other mods I was originally trying to use, and the game was able to start up (in 32-bit with the small RSS textures, in 64-bit with the huge ones). Obviously, though, that's not a configuration that I want to play - RO is a crucial mod!

Check your RemoteTech_Settings.cfg in GameData/RemoteTech. There should be a line like "HideGroundStationsBehindBody = False". Change the False to True. I'm actually pretty sure it defaults to True, so you might just not have the latest version; this feature was added fairly recently.

Very handy! Looks like you swapped the numbers for WasteWater and Waste in the Kerbals row of the Converters sheet. I fixed that and put in my own numbers for the actual converters, and now I'm playing around with a plan to use Kerbals as resource converters, turning food into rocket fuel. I just have to change some things so Oxygen and Hydrogen become LqdOxygen and LqdHydrogen, then deal with boiloff...

I'm still loving this mod. I think I'd put it just after FAR on my won't-play-without list at this point. In particular, there's no way I'd play on hard mode - no reverting, no quicksaves - without the ability to do simulations. Since everyone's asking for a way to recover vessels into storage, and it sounds like you're planning on adding that, I'd like to request that it not be instantaneous; there should be a "Refurbishing" period, faster than building from parts, perhaps dependent on the length of the flight if there's any way to do that. Gotta replace those ablative tiles on the shuttle, fix the engines' ignition system (for those of us playing with EngineIgnitor, most engines can only be ignited so many times) and so forth.

Here's the RO_TACLS_Tanks.cfg that I ended up with, cut down to the last three blocks since those are the ones I changed. For each part, the ratios of inputs and outputs are unchanged, but I rescaled them all (including charge consumption) so that they make more sense. The water purifiers consume enough WasteWater for one or two Kerbals based on the RO-default TACLS config, and produce excess Water; the water splitter produces enough Oxygen for two Kerbals. I left the Sabatier recyclers alone, since they produce the claimed amount of LqdMethane per day. (I switched to the Bosch reaction anyway. I thought it was still locked, but it turned out I just hadn't been able to find it in my mess of a parts catalog.) The rest of the CO2 scrubbers appear to have their rates scaled based on the amount of CO2 produced by a Kerbal, so I left them alone as well. Hopefully someone else finds this useful. One other thing I noticed in the cfg is a disagreement between the potassium superoxide CO2 scrubber's description text, which says it releases water, and its actual config, which says it requires water and releases oxygen. I'm not a chemist, so I don't know which one is right. @PART[TacWaterPurifier]:FOR[RealismOverhaul] { %RSSROConfig = True MODULE { name = TweakScale type = RealismOverhaulStackSolid defaultScale = 1.25 } @description = Get the most from your pee. Recycle. Rated for 1 person @MODULE[TacGenericConverter] { @conversionRate = 1.0 // # of people - Figures based on per/person @inputResources = WasteWater, 0.00003125, ElectricCharge, 0.07744004 @outputResources = Water, 0.00002968749, true, Waste, 0.000001562508, false } !RESOURCE[WasteWater] { } } @PART[TacWaterPurifierLarge]:FOR[RealismOverhaul] { %RSSROConfig = True MODULE { name = TweakScale type = RealismOverhaulStackSolid defaultScale = 2.5 } @title = TACLS Water Purifier @description = Get the most from your pee. Recycle. Rated for 2 people. @MODULE[TacGenericConverter] { @conversionRate = 2.0 // # of people - Figures based on per/person @inputResources = WasteWater, 0.00003125, ElectricCharge, 0.23232013 @outputResources = Water, 0.00002968749, true, Waste, 0.000001562508, false } !RESOURCE[WasteWater] { } } @PART[TacWaterSplitter]:FOR[RealismOverhaul] { %RSSROConfig = True MODULE { name = TweakScale type = RealismOverhaulStackSolid defaultScale = 1.25 } @description = Using electrolysis, split water into hydrogen and oxygen. Rated for 2 people. @MODULE[TacGenericConverter] { @conversionRate = 2.0 // # of people - Figures based on per/person @inputResources = Water, 0.0000117326595, ElectricCharge, 1.1041671689 @outputResources = Hydrogen, 0.01460362, true, Oxygen, 0.00729167, true } }

I just spent some time trying to plan out a largeish space station with RO and TACLS, and I noticed that the rates for the various converters don't line up with the number of Kerbals their descriptions claim they support. My goal was to support the station with an input of only food and a closed cycle for everything else, so I'm using the water purifier, water splitter, and Sabatier recycler (small; I haven't unlocked the large one yet). To support 10 Kerbals, I needed: - 3 purifiers; so they support at least 3.3 people each, not just 2. - 4 Sabatier recyclers; so they support at least 2.5 each. This one makes no claim about the number of Kerbals it supports. - 12 splitters for O2; so they support less than 1 Kerbal each, not their claimed two. Worse yet... - 20 splitters total for H2 for the Sabatier reactors (8 extra on top of what's needed for O2 production). - A 4th purifier to supply water for electrolysis (no surprise). By mass, that's 0.26 tonnes of Sabatier recycler, 14 tonnes of water purifier, and 68 tonnes (!) of water splitter to support 10 Kerbals, which leaves me with a small excess of everything except O2, which is produced in abundance. The tonnage and the excess oxygen might be fine (if surprising), but the inaccurate descriptions combined with the sheer number of water splitters required make me think something's off here. For now I guess I'll just tweak the numbers in my RO_TACLS_Tanks.cfg to make the descriptions accurate. I'll post back with the result when I'm happy with it, but I have no idea if I need to alter the masses and volumes of these things to compensate, so the results might not be realistic. If anyone has explanations or suggestions, bring them on.

That's a combination of a long payload, a fairly high TWR, and most importantly an excess of control authority from thrust vectoring. Try reducing the gimbal range on those engines, or disabling gimbaling on some or most of them (keep it symmetric, of course). The rocket will turn more gradually and have less tendency to overcorrect. You might also want to disable any reaction wheels in the payload before launch, as they can contribute to this sort of twisting; they're far from the rocket's center of mass, so they're just rotating their own local section of the stack.

@Armarnis, you do indeed have to make the connection both ways, so if your main satellite doesn't have a dish pointed at each of the others (or a single dish that catches them both in its cone) then you'll find they aren't connected. Also, the cone angle is only for allowing you to make multiple connections with one dish - you select a target and anything near enough to it in your field of view is also connected (assuming, again, it has an antenna to make the return connection). You don't have to physically rotate the satellite so that the dish is pointed in the right direction, if that's what you're worried about. "Only" a 45-degree angle is a very wide cone, and handy for getting area coverage in medium-range networks; the narrower cones have longer ranges and are suited for long-range point-to-point.

Thanks - I guess I haven't unlocked it yet. I'll have to keep my eyes peeled for it as I get more science.

It used to be that have a mobile command center required a vessel with 6 kerbals. Now this doesn't seem to be sufficient, and I see in the instructions page, Also from the release notes for 1.5.0, But I don't see anything in the VAB to give more details. What am I missing? How do I tell how many kerbals is enough? Have I just not unlocked the necessary "special probe part" yet?

TAC Life Support has been updated for 0.90 as of a few days ago; the "[]" can be removed from it in the listing in OP.

If you mean x64, as in 64-bit, DRE is working fine for me in 64-bit KSP on Linux. On Windows, 64-bit KSP is reportedly very unstable to begin with, and adding mods won't make it better - I don't expect many mod developers to want to try to support it in its current condition.

Small request: When simulations are set to be free, could the simulation dialog not ask how long a simulation should be, or at least default to unlimited?

tgillespie, among FASA's launch clamps, it looks to me like only FASA Umbilical Tower has the module that allows it to refuel the craft. I think this is probably intentional. I haven't actually tested them though. Which one were you using?

The problem seems to be intermittent. I posted after having it happen three or four times in a row; on the next attempt, my tank was full. One thing that might have made a difference is that I upgraded my build rate in the VAB in between attempts - I think it might have built fast enough that the tank wouldn't have been *quite* empty. Maybe it only resets tanks that have at least some fuel in them? On the other hand, the same problem occasionally appears in simulations, where there's no build or rollout time, so maybe my guess about the cause is off base. Anyway, I've seen it happen with multiple crafts in a couple of saves; anything with a cryogenic fuel in it seems to be affected.

I'm loving this mod. I'm playing with Realism Overhaul, and this mod is as much of an improvement to the game as anything else in that pack. I've run into an issue though, and it seems like an unintended interaction between KCT and RealFuels: If I use a cryogenic fuel and no launch clamps, then there's no fuel left by the time the vehicle reaches the launch pad. This makes it impossible to use the early kerolox engines. I assume the stock launch clamps with their refueling feature will prevent this, but I haven't unlocked them yet, and the clamps added by various mods don't seem to refuel. My suspicion is that the tanks are filled when I click "Build it!" and then the liquid oxygen boils off during construction and rollout. It seems more reasonable to have it be topped off on the launch pad, or at least before rollout. On the topic of a name, I think "Unrapid Planned Assembly" is descriptive, memorable and amusing, plus it's already associated with this mod since it's there in the thread title.

This is an essential mod - thank you swamp_ig for your work on it. I was wondering if there's a way to change the energy density of the batteries. Realism Overhaul changes the storage capacity of stock batteries and those from other mods, standardizing (I think) on 1 charge = 1 kW*s = 1kJ. The capacities end up much higher and leave the procedural batteries in the dust. I didn't see anything for energy density in the config; this would be a nice thing to add. Also, with the ability to change the energy density would come the possibility of making it tech-dependent. After all, as far as realism, there's no sense in having a limit on the size of a battery (other than a very small minimum size) - you can always pile on more batteries and stick them in a bigger metal tube. But as technology advances, we get more watt-hours with less mass and volume.

This mod is fantastic. It's one of those things where I had no idea how much I needed it, and now I'll never play without it again. I was always staring at my navball before, neglecting the majestic beauty of my ships, and in some cases neglecting the way they were bending and twisting in the atmosphere during launch. Now I can look at my ship and navigate at the same time, and do so much more precisely to boot - I've noticed that headings that look "close enough" on the navball are sometimes significant distances from my desired heading in the HUD. I have a couple of suggestions that would improve this further: - Others have suggested an anti-heading vector, and I second this. - An anti-node vector would also be useful; Enhanced Navball has this, and it can be helpful especially when touching up a maneuver with RCS. - Speed/thrust indicators like MarrusQ suggested, except I would put speed next to the velocity vector, thrust next to the heading vector and maneuver delta-v next to the node vector. Duplicating these indicators for the retrograde, anti-heading and anti-node vectors would also be a nice option. - What you might call "rotation vectors": an arrow for yaw/pitch rate (direction of rotation) pointing from the heading vector, along with possibly arrows pointing from heading toward prograde, normal, and node that could be enabled/disabled to help rotate into position. That last one is inspired by playing with Realism Overhaul, where magic-torque reaction wheels aren't available and I have to use RCS for almost all rotation; to conserve RCS fuel, I like to turn off SAS, give my craft a little push in the right direction and then be very patient while it rotates, and it would be nice to know that I'm actually rotating in the right direction. The gridlines on the HUD already help immensely with this compared to the navball, but when I need to change both my pitch and compass heading, I'm still half guessing. Anyway, thanks for the great mod! Even this initial version is a great enhancement to my KSP experience. I hope you can keep working on it.

If you can get it out of atmosphere with the first stage, and just need the second stage for circularization, it's very doable. You just have to complete your circularization burn before the first stage falls back into atmosphere. I've used a vertical-launch reusable SSTO rocket as a launch vehicle for most of my current save. For one particularly heavy payload, it didn't quite make it to orbit, but the payload was a lander with enough excess delta-v to finish the job. Since the launcher is piloted by two Kerbals, I would have been devastated - devastated! - if it had not landed safely, but fortunately I was able to do what I described above and get them safely to the ground.

The issue isn't getting the docking port to attach to something other than a docking port; it's having a rocket design that splits and then comes back together. You can't. You can place a quadcoupler so that it appears to be connected to four points, but it is in fact only connected to one of them. You can tell this by selecting another part to place, which will cause the connection nodes to show, or simply by taking the vehicle to the launchpad, where only one of the four nodes will remain stable while the others slide around and the rocket likely falls apart. Possible designs have a tree shape, in the sense that if you diagram a design as a graph, labeling the points on the graph as parts and connecting them with lines where they are connected in the VAB, there will be no loops or "cycles" in the graph. Rather than trying to connect a quadcoupler to four existing attachment nodes, the solution is to connect it to one attachment node in the VAB, and then arrange docking ports such that they will dock as soon as you take it to the launchpad. Not allowed: Bicoupler / \ Part Part \ / Bicoupler Notice that there is a cycle: You can go down one side and come back up the other, returning to where you started from without traversing the same edge twice. Allowed: Bicoupler / \ Part Part | | Dock Dock | Dock Dock \ / Bicoupler There are no cycles in this design. The missing connection between the two docking ports on the left will become connected once physics takes effect, because the ports are positioned perfectly for docking. Cycles are allowed at that point, just not in the VAB.

Strut the boosters and boost the struts, it's off to space we go!

Complicated design. It took me a minute to work out how you were even going to get all the wheels oriented in a sane manner. The first difficulty you're going to have is getting it on a rocket without making the assembly unbalanced. This is just a matter of finding a place where you can attach a stack decoupler and have it lined up perfectly with the center of mass. The next problem is going to be lowering it to the surface of the Mun. Since there's no good place to add fuel tanks and rockets to the rover itself, you might consider using a skycrane. (I see you already have some fuel and rockets, but it doesn't look like enough to land with, even if they were oriented correctly.) Of course you would have to find a spot to attach a docking node or stack decoupler, and again, it would have to be lined up with the center of mass. You could conceivably launch it with the skycrane already attached by attaching the top of the skycrane to a rocket. That way you only have to balance it around one coupling point. Another option would be to attach it to the side of another lander of whatever sort you like, with either another of the same rover, or some other payload on the other side to act as a counterweight - the whole thing still has to be balanced. Honestly though, I would try designing a new rover, keeping these constraints in mind from the beginning. Having a rover that's symmetrical makes it much easier to find attachment points for both lifting from Kerbin and dropping on the Mun. Integrating landing rockets into the rover itself is optional, but in my experience makes things much easier.

Just to make it easier in the future - you can switch between nearby craft without going back to the tracking station by pressing [ and ].

Great idea to start this thread! FAR makes for very different craft. I'll cross-post my SSTOs from elsewhere. All three of these have been to orbit and returned safely at least once - and the Freebird Mk. 1 has even completed rescue missions after a couple of occasions when the Mk. 3 (not pictured) experienced sudden unexpected engine disconnection events. Freebird Mk. 1 Freebird Mk. 4 Epsilon If I remember correctly, that last one got to orbit with over 2500 m/s delta-v left. I haven't actually delivered a payload with any of these yet (apart from a hitchhiker storage container in the rescue missions), because the rovers/landers that I want to put up are too large even for that cargo bay. My next SSTO experiments will involve the use of procedural fairings to make a larger cargo hold.