VaporTrail

Depends on the mass of the engine really... That page you list doesn't list an engine mass for the LANTR engine... but lists the NERVA at 10 tons... The stock LV-N in KSP is listed as less than a quarter of that... 2.25 tons instead of 10, with the same 60kN thrust rating. As long as the mass/thrust and ISP of the partare in line with the stock (even if they're a little over) I can't see that engine being too overpowered. Probably want to look at between 6 and 8 tons though. The 250 Ec/Sec in generator mode is hellishly strong though... you're producing as much Ec as more than twenty-six tons of radioisotope generators (PB-NUK)... and you get thrust out of it too... 25 Ec/sec is probably plenty I'd love to see a mk2 compatible Thermal receiver for KSPI, or even a conformal (if inefficient) MW receiver.

All good to know. Depends on your "spacey" I guess... Apollo 13 spacey vs. Star Trek spacey. Like I said, I like em both And with the tweakable scaling meaning less raw parts, means 'moar room for moar partses.'

I see that the update doesn't include the ZodiusInfuser parts yet... Was thinking about getting those. Guess I'll give it a bit of a wait since the update is save-breaking. Can you have both sets alongside each other (or will you, when the update to ZodiusInfuser's models gets published)? I really like the look of both of them, for different types of applications. The standard MSI hinges and such are great for "rough and ready" type stuff, like Mun Landers and rovers... while the ZodiusInfuser models put me in the mind more of aircraft applications.

Post transfer: Couple of thoughts, not sure if they've been mentioned: First: Perhaps a Minimum Time Before Failure stat. Call it a "Warranty Time Period" since MTBF is taken... Big problems usually take lots of time to get to the point where they're about to happen... then happen quickly. WTPs would range from several days to a week or so (generally lights and other "nonessentials") up to months (big fuel tanks and the like). Basically the idea is to prevent huge problems on the pad for long missions, but still allow the occasional "quality control issue" through. This would probably be a good spot to tie the reliability in... better parts have a longer WTP than those 'built by the lowest bidder.' Second: Perhaps a modifier for systems that have had a failure. Basically, if you have a failure in one type of system (say a battery) then the failure generation system should have a built-in bias against generating the same type of failure immediately thereafter. The idea is to prevent someone having to repair a fault in every battery, on a vessel that mounts a dozen small battery packs because they need the power, and the redundancy, instead of getting a mixed bag of faults. The trick is to ensure that it doesn't prevent getting two of the same failures back to back... just makes it less likely.

Couple of thoughts, not sure if they've been mentioned: Transferred to Dev thread.

Damn... another mod I want to have... and yet I'm getting (what I assume are) memory crashes already, even though I'm using ATM. Time to start ripping out parts I don't need, I guess.

Had a bout of inspiration thanks to this design: http://forum.kerbalspaceprogram.com/threads/76668-0-23-5-Kerbal-Aircraft-Expansion-%28KAX%29-v2-2-1-Now-With-100-More-Helicopters?p=1130093&viewfull=1#post1130093 and I wound up with this. I present the Gyrfalcon VTOL system shuttle. Pics inbound, video to follow. Planning on attempting a cargo version... thought that's gonna be interesting. Balance is really finicky on a VTOL... might balance it for landing, and just STO it (the passenger version is pretty capable in a short takeoff mode). Video's done.

That would work... the only problem (well, I guess it's more an asthetic issue) is that the max capacity of the battery would change. Instead of being 90/100 when max charged and failed, it will be 90/90, as opposed to 100/100 unfailed and max charge.

Wait... 64-bit KSP? Without the 4GB RAM limit? Two questions. Is it stable (for alpha values of stable)? Why you no linky?

Actually I think that's a problem with whatever they're mounted on... These are the curved recessed RCS, rotated 90 degrees from the default, relative to the radial axis... On the stock 1.25m fuel tank... Stock 1.25m RCS tank... Procedural Tank in 1.25m... Stock 2.5m BOT... respectively. As you can see, the bigger the parent part, the better they tend to fit, and the stock fuel tanks tend to have smaller "visible" surfaces than what their radius would suggest. (I think that's colliders being 1.25m with the model being slightly underradius... Not a modder so the technical terms might be escaping me.)

Had an idea for a problem that I don't think is currently covered, but that could make life more interesting... Or maybe just annoying. It might take quite a bit of coding to get this one in though... Example problem: A battery losing a cell, or partial failure of a battery. Basically the battery (radial or stack) works as normal until the failure occurs. When the failure occurs, the battery experiencing the failure loses some percentage (50%?, 25%?, 10%?, Maybe base % on severity of failure?) of it's optimum maximum storage capacity. Basically, this means the battery will (quickly) lose any charge above the new "damaged" capacity, and any charge added to it will not increase the stored EC above this value. For example, we have a stock Z-100 RCBP with a max capacity of 100 EC. This RCBP experiences a 1/10th severity failure and thus can not hold more than 90 EC until fixed. (possibly by adding a "failure" module that "quickly burns" electric charge to the battery in question, until the battery's capacity is 90 or less, then burns charge @ the charge rate of the battery, leaving the battery @ 90 EC. The charge rate is likely to be the total charge rate of the vessel, and in the case of large vessels or KSPI reactors, is likely to be huge.) This would be especially problematic for vessels using Balancer mods to keep their electric charge balanced (though I have yet to run into a scenario where that's relevant) as suddenly every battery has to drain to 90%. Pros: Another possible failure event, and possibly one that would be quite annoying in an unmanned long-duration vessel without sufficient redundancy. Cons:: Not a very high priority failure for manned vessels, unless high %'s are used. If the choice is repairing the leaky fuel tank, or the slightly glitchy battery, the battery's gonna keep the glitch. [Edit] Just realized, the way KSPI Megajoules is structured (I think) a battery failure such as detailed above is going to completely hose power production... as the generators first fill all available EC before switching to MJ... if you have something burning huge amounts of EC (failure module...) then the reactor never gets to produce MJ.

One thing... is there any way to add a couple of lines of code that says, in effect: in control scan loop, w/ legs attached and in use, If (vesselwide electric charge == 0, Brakes == False) { Brakes = True; } continue control scan loop. This would kill the legs' ability to keep right on trucking w/o electric charge... which is possible for a wheeled (or even tracked) vehicle, but quite impossible for an articulated leg setup. Other than that, love the little bugger.

Actually, CO2 as a resource might be a bit too easy to come by... because any Life Support mod is going to have Kerbals generating it. Perhaps if there is going to be some kind of CO2 resource, it should require a seperator and compressor part for "useful" C02, probably in cryogenic liquid state. A built in refrigerator for any CO2 tank (really, any cryo-liquid resource) that consumes EC wouldn't be misplaced either...

Another possible malfunction: a "stuck open" RCS throttle valve. Basically while a RCS thruster is firing, the valve that closes to shut it off, doesn't. Tumble fun time. To fix, requires shutting off RCS functions (R key), disabling the RCS port (secondary shutoff valves, right-click part), stabilizing your ship (either through reaction wheels slowing the resulting tumble, or reactivating RCS and manually flying it), and performing repairs in EVA. The other side of the coin is a stuck shut throttle valve. One thing about EVA propellant leaks: realistically, if your EVA propellant leaks quickly through a puncture, it's probably going to be a thruster, not just a leak... which means your kerbal's going to be doing a dutchman really quickly. Think pinwheel firework in space... A slow leak is possible, that doesn't produce quite as much thrust (making getting back to an airlock difficult, not freaking impossible) but that route isn't going to be a really quick resource drain. Depends really on what you're using for EVA propellant. If you're using silver-catalyzed hydrogen peroxide (which is a monoprop) then all you've got to deal with is liquid H202 boiling to vaccum and generating thrust that way, and then you're not going to get too much thrust. A pressurized-gas system that develops a fast leak is going to be a serious problem.

Now all we need is a tiny, annoying, glowing ball floating around... What? No one else remembers Bit?

Question: is download link in OP for 1.0 or 1.1? Needs updating if the latter.

Probably Extraplanetary Launchpads and Orbital Construction. Believe XPLP is the only one still around... Think OC wound up dying on the vine, but not sure.

Actually, I like the bottleneck. It kinda gives a purpose to the huge storage batteries (NFP and HexCan are what I'm using) and makes the difficulty of actually building something that complex as small as possible a bit more. Not to say that I'm lobbying for it to stay... just that it isn't too broken. Right now, only working in sandbox mode, so career might be quite a bit different... but once you've got Quantum Plasma thrusters, dropping anything into a near-Kerbol orbit is almost trivial.

Oops, meant Kerbol. Fixed. Anyway... Figured it out... I was still in Phys Timewarp x2. Dunno why it halves the output, but it does. Anyway, here's the design: Needs about 3x the EcC to make it actually work fully at that altitude... 214 parts on launch right now... But I should be able to tack on enough. 6 Large Hexcan Batteries should do the trick.

Hmm... Let me see if I've got the math right. I've got a design that's using 8 of the really big NFP blanket panels currently in orbit around Kerbin Kerbol (oops) at 20Mm altitude. This equates to an energy flow (per panel) of roughly 575,000, for a total energy flow rate of 4,600,000 (assuming that's in Ec/sec) from the panels. 1 Ec/sec = 1 kW (yes?) ==> 4.6 GW of available power. 4,600,000 / 50 = 92,000 ==> need 92,000 EcC to transmit the full 4.6 GW. Formula is basically this: Flow rate at altitude * Conversion factor = Capacity ==> (Total Electric Charge Flow (in Ec/sec)) * (1/50 sec) = Ec (capacity) So taking it in reverse, a capacity of 37,315 Ec should max out at 1.86575 Gw transmitted, yes? My design, for some reason, is maxing out at exactly half that.

Don't use FAR personally, so I don't remember it. I've thought about using a PFaring over an umbrella reciever (w/ IR mount) for a spaceplane, but that kind of thing requires a relatively HUGE fairing (in excess of 3m IIRC) to actually pull off. In that vein, if you're going to use thermal anyway, you might be better off using the upgraded thermal turbine when you get it for at least your initial boost phase. Atmospheric mode to where it's starting to get inefficient, transition to rocket, rocket to edge of atmosphere, then plasma thruster to orbit and beyond.

Plasma thrusters work off electricity (in megajoules), not thermal power. If you're going to use thermal power to power a plasma thruster, you need an electrical generator (same as you'd use for a reactor) connected to your thermal receiver. This is quite inefficient (both in mass and power) compared to the regular (umbrella) receiver. The thermal receiver isn't as hard to aim as the umbrella receiver, but getting a high power/mass ratio is easier with the umbrellas. As for aiming the umbrellas, look into Infernal Robotics... The pistons, 1/4 hinges, and 1/2 or 1/4 rotatrons are perfect for setting up an easily workable system.

How many mods are you running? Most common cause for crash while loading is hitting the RAM limit. Look into the Active Texture Management mod (if you haven't already) for a reliable fix.

I'm thinking an extra probe core at the vertical axis of the rotor (properly oriented and using "control from here") should allow this... but transferring control between "movement" and "hover" modes is going to be a bit squirrelly. Do it slightly wrong and you're going to have Mechjeb trying to snap-pitch your helicopter into the dirt.

Actually, if you rationalize the colored dot as a color coded sign saying what color the light is... it works. And it's pretty Kerbal-ish. Almost to the point of "pour... water... out of a boot" level.