undercoveryankee

I was thinking about suggesting a similar approach. Perhaps allow the short-range dishes to double as low-gain antennas with the same field of view but longer range for the low-gain functions.

The 0.90 version that MKS and friends are shipping gives a compatibility warning, but seems to work for everything that RoverDude is using it for. If you don't have any of RoverDude's mods, you can get the updated plugin from https://github.com/snjo/Firespitter/tree/master/For%20release/Firespitter/Plugins . Since only the plugin has changed in ages, nobody has gotten around to repacking the parts pack with the current plugin since before 0.90.

The parts now have procedural sizes. After you place the stack chute part, you can scale it to the size you're looking for from the configuration window in the action groups tab.

1.0 added a new stock chute: the Mk12-R radial drogue chute. The new part is still using the stock chute module after installing RealChute. Looks like we'll need to add a new ModuleManager patch for it.

Thanks! Changed that and removed all but the first # sign in the line with multiple variable lookups. Now it's working. Did the order of evaluation change since the first version with variables? Because the example deletes a temporary variable after referring to it inside a node.

A little troubleshooting help? I'm trying to add FSfuelSwitch to all LFO tanks to add an option for CRP LqdHydrogen. Here's the patch: @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[FSfuelSwitch]] { %lh2Amount = #$RESOURCE[LiquidFuel]/maxAmount$ @lh2Amount += #$RESOURCE[Oxidizer]/maxAmount$ @lh2Amount *= 5 MODULE { name = FSfuelSwitch resourceNames = LiquidFuel,Oxidizer;LqdHydrogen resourceAmounts = #$../RESOURCE[LiquidFuel]/maxAmount$,#$../RESOURCE[Oxidizer]/maxAmount$;#$../lh2Amount$ tankCost = 0;0 displayCurrentTankCost = false hasGUI = true showInfo = true availableInFlight = false availableInEditor = true basePartMass = #$../mass$ tankMass = 0;0 } !lh2Amount = delete } and the log entries: [ModuleManager] Applying node /hydrogen-nukes/@PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[FSfuelSwitch]] to Squad/Parts/FuelTank/Size3LargeTank/part/Size3LargeTank [ModuleManager] Cannot find key lh2Amount in PART [ModuleManager] Cannot parse variable search when inserting new key resourceAmounts = #$../RESOURCE[LiquidFuel]/maxAmount$,#$../RESOURCE[Oxidizer]/maxAmount$;#$../lh2Amount$ As the log entry suggests, the key resourceAmounts is never added to the module. Can anybody see what I'm missing?

Not the author, but I'd say yes. They have different thrust transforms, so I'd say one module is for the main nozzle and one is for the four roll verniers.

There's never been a situation where a flight that didn't complete a contract would void it (unless you destroy the object you were supposed to recover). If the altitude and speed contracts still have the hidden requirement for a manned capsule, then they'll still be there after your sounding rocket flight. If an unmanned rocket can complete them, then the sounding rocket will complete any tiers that its altitude and speed qualify for and the next tier up will be waiting for you afterward. There is no down side that I can think of.

Yes. Unlike 0.25/0.90 rescue contracts, 1.0's recovery contracts may spawn a kerbal inside a randomly-selected command pod.

Only issue I've seen is the one I posted about last night where USI-LS sets off the launch escape system on the Taurus HCV (similar to the conflict that EPL used to have).

Another 1.0 issue: Re-entry from 80km LKO with 35km initial periapsis used zero Ablator from the Taurus heat shield. I compared config files, and the stock shield has a "thermalMassModifier = 0.001" setting that the Taurus shield doesn't.

USI Life Support seems to trigger the LES on vessel launch. I've reported it on the USI-LS thread, and the fix will probably be from RoverDude's end. Just wanted to mention it here in case anyone else runs into the problem.

USI-LS seems to cause the launch escape system on the Taurus HCV to fire on vessel launch. Here's a log from a test run with only the relevant mods and their dependencies, in case it helps. https://www.dropbox.com/s/nq169mv4niq89pk/KSP_Taurus_USI-LS.log?dl=0

The small side chambers can gimbal to provide roll control.

That's to be expected given the changes to how the stock tech tree is loaded. On the bright side, it's supposed to be possible to mod the new tree with no more than .cfg files and perhaps ModuleManager. So this should be the last serious break.

In real life, LH2 is incredibly fluffy, so the mass ratio of an LH2 tank isn't as good as you would get with kerosene/oxygen/storables/etc. I'll have to look up some real stages and run some numbers, but the mass ratio cost for flying an LFO tank with no oxidizer might be proportional to the cost of replacing a kerolox tank with a same-volume hydrogen tank. (Of course, since our tanks are built like battleships, a proportionally similar cost makes a much bigger difference in how far you can get).

For an idea of what factors into your delta-v performance, check out these numerical simulations at http://www.reddit.com/r/KerbalSpaceProgram/comments/2spalr/far_deltav_charts/ and http://www.reddit.com/r/KerbalSpaceProgram/comments/2u8b08/far_kerbin_and_earth_deltav_graphs_rev_2/ . 2.9 with pure rockets is right on the edge of possible if you get the pitch profile right and vary your TWR higher at the beginning and end and lower through max-Q. My personal record with constant full throttle is about 3.1. The optimum flight path for delta-v usage isn't quite a pure gravity turn according to Ferram4. You make your gravity turn a little late to put you on a high arc that gets out of the thick air quicker, then gradually pitch a few degrees below prograde as decreasing drag permits. kOS is your friend here.

All "mass" figures in KSP are taken to be metric tons. That gives most parts plausible densities, and it seems to be what the developers intended.

Chemical engines start to have the advantage once the stage gets small enough that one LV-N would be more mass than you have to spend on engines. The break-even point depends on your delta-v budget and required thrust, and in most cases where a 909 would outperform a nuke, a 48-7S cluster does even better.

In at least parts of the English-speaking world, "Gesundheit" is the traditional thing to say when someone sneezes. So you hear people say it sarcastically to mean "that made about as much sense as a sneeze" or "that contributed to the conversation about as much as a sneeze."

The usual workflow is to let the chute cut, then repack it. That's why there's a configurable number of spares for each chute. Does the "repack" option appear after you cut the chute?

It feels like it should be possible to build a derated variant of a non-throttling engine if there were some way to make the limiter tweakable in the VAB but not in flight. On the other hand, if we get around to modeling the variation in Isp as you run the same engine at different chamber pressures, you wouldn't want to. Derating would mean carrying a heavier engine than strictly necessary for the thrust level, and running it at a lower Isp than it would give at its rated pressure. If the thrust you need is between the engines you have available, the most likely real-world approach is to use a suitable number of smaller engines.

CTT is also a strict superset of the stock tree. It doesn't remove any of the stock nodes, but it adds some additional nodes that SCANsat uses if CTT is installed. Unfortunately, ModuleManager can detect only whether it's installed. MM can't read your mind to tell whether you're planning to load a save with CTT active, so if you have CTT installed you need to be in the habit of using it. Fortunately, I seem to recall KSPI Extended being CTT-friendly. Perhaps the stock tree loading that's been announced for 1.0 will make the tech-tree-modding situation a little more sane in that regard.

I don't know NovaPunch, but I can address KW. KW introduces 3.75m parts in Very Heavy Rocketry. That's the same tier of the tech tree as Heavy Aerodynamics, which has the PF 6-meter unlock, and Meta-Materials, which has the KW 3.75m interstage decoupler. KW's fixed 3.75m fairings are one tier earlier in Advanced Aerodynamics. Since I leave the KW fairings installed and use them for payloads that fit the standard sizes, that placement works for me. If you strip the fixed-size fairings out of KW to reduce the number of parts you're loading, the new PF sizes should probably unlock one tier earlier where the KW fairings would, so you don't have to unlock two separate 550-point nodes before you can take advantage of either. If I were using NovaPunch and had size-3 engines in the 160-point tier, I would probably edit the PF config locally to make size-3 interstages available there. But if you follow NovaPunch's progression in the standard package, you end up with limits that don't affect anyone who isn't using NovaPunch.

KSP is a 32-bit process on OS X, so you'll start to see glitches as you approach 4 GB of RAM used. I've seen address-space pressure cause basically the same failure modes you're describing across a couple of different versions of KSP and OS X. There are enough bugs open on the tracker for apparent leaks that opening another one probably won't add any useful information. The kinds of memory leaks that affect .NET applications like Unity are hard to debug. The system garbage collector doesn't allow unreachable memory to remain allocated (usually; there are a few lower-level bugs where garbage collecting a managed object fails to deallocate an unmanaged allocation that it uses). The more common type of leak is one where an object remains reachable somewhere even after the programmer is no longer interested in it. Automated analysis tools can't tell whether you've leaked that memory or just haven't run the code you were saving it for. And when the crash happens, the stack trace tells you only what was trying to allocate memory when you ran out. You're on your own to figure out what code should have disposed of something to prevent the crash. 1.0 probably won't be the end of memory leaks, but I do hope to see some incremental improvements.