damerell

Well, after a year here we are again. LFO alternators were one of the things on my list, complicated by the fact that they're something kerbal rocket engines have and ours - by and large - don't. However, the LV-T45 has one of the best electricity/fuel flow ratios, and is putting out 6kW at one EC = 1kJ. It consumes 68 kg/s which at the 13 MJ/kg LF/O energy density back-of-enveloped above is about 900MW, so the alternator is spitting out 1/1500 of the energy the engine is burning up. I think it's fair to say engine alternators aren't implausibly good and can just be left alone. Hooray!

I've added it to my save, where I'm using USILS on an Orion-powered mission. Thanks.

You can tell CKAN to allow mods from newer versions, which you can easily do to install a parts pack that's likely to work anyway. Then you can report a github issue to CKAN so they can update the metadata. You need to follow the instructions at - a screenshot tells the mod author very little.

I spent a lot of time on Minmus, well, not actually on Minmus. The almost complete lack of traction means once you eventually are up to speed, there is no prospect of braking. My later low-g rovers mounted nose thrusters.

Second the motion. I find that setting a target altitude normally results in a very aggressive climb, and often the plane limps upwards in a series of near-stall events.

FWIW, this isn't dead, just resting. I'm likely to get a significantly faster CPU in the next few months, so I'm not playing KSP until it turns up.

If I had known the answer, I would have posted it. Since I didn't, I posted how to find it. Given a choice between me rummaging through the thread and the person who actually needs to know doing it, I declined to do it myself. What's odd about that?

https://forum.kerbalspaceprogram.com/index.php?/topic/196855-campaign-for-real-electriccharge/ may prove useful. I have been tangling with MM seriously for the first time, and most of what I want to do there is apply a patch to all objects of a given type. http://www.chiark.greenend.org.uk/~damerell/games/ksp/CAMREC/CAMREC.cfg is the actual MM file buried in the walls of text.

Manual installation is a last resort; CKAN metadata gets dependencies and conflicts right for you (if it's right, but if it's not, at least it only has to be fixed once to help everyone). You'll need in any event to go back up the thread to find the fix for the light globe part.

Surely the obvious answer is to stop exploiting the bug where the converters work when uninflated. Inflate them when you get to space and see if there is any unexpected behaviour after that.

It's kind of you to say so, but I'm not sure there is much left to be done (one or two things) until release and (if anyone else uses it) thinking about mod parts that it doesn't play nice with. Progress is kind of limited by me being too lazy to do anything about it unless my current in-game objectives need a particular kind of part's EC usage looked at.

If I understand it correctly, the MedBay can cure Kerbals; the KModule cannot. This matters if a detached expedition's planning is incorrect and it manages to return or be rescued anyway. Otherwise, yes, prevention is better than cure.

I suppose given he's American we should be grateful he doesn't think in BTUs or something. :-/

Oh, I didn't read it as criticism, just as a straightforward suggestion. While I'm here: Russian RITM-200 icebreaker power plant: 175MW/1100 tonnes = 160 W/kg. USI 0.625m nuclear power plant: 190 W/kg (@ 1EC = 1 kJ) USI 3.75m nuclear power plant: 180 W/kg. I guess I can leave those alone.

I'm not sure if you mean "why are you writing rules for specific mods?" or "why are you writing generic rules which will edit any part with a given function, rather than explicitly naming stock parts for conversion?" The answer to the first question is I'm writing the mod I want to use; since I use Kerbal Foundries, ODFC, and Universal Storage (for example), I'm writing configuration to handle those parts. The order in which I'm doing things reflects what I'm trying to get done in my current game; I wrote the KSPWheel rebalancing bit before the ion engine bit because I'm building big rovers not tiny high-dV probes. Also, since this is my first nontrivial use of Module Manager, I've been doing things I do know how to do while hoping to get advice on things I don't. The answer to the second question is that it's less work, and these generic rules naturally work on parts with stockalike balance, which I think the majority of mods out there try for. For example, "Hangar" hangars incorporate EC storage, solar generation, and ex nihilo EC generation representing RTGs, and their mass and cost is intended to partly reflect the mass and cost you'd otherwise have to bring in batteries, panels, and RTGs - saving part count, but nothing else. After CAMREC edits those hangars, they're still balanced relative to bringing CAMREC batteries, panels, and RTGs. (Also, at least until I think of something else, radiators are the only stock part category I plan to address and haven't yet...)

I hit on a better approach; rewrite ion engines as multimodes, with "Accelerated" (realistic EC/s, unrealistic thrust) and "Realistic" (realistic EC/s and thrust) modes, with the default being "Accelerated" to minimise user surprise.

Ah! That makes sense of oddballs like the Ranger Agricultural Module. Thanks.

You're not wrong. It doesn't help that the most up-to-date documentation is in KSPedia... except some bug makes it not appear in KSPedia. Some of this may be wrong, but it reflects my best understanding. "Agronomics" makes Supplies from Mulch and Fertilizer. "Cultivate" is used to produce Supplies from Fertilizer, Water, and Substrate/Dirt. The (to me, rather niche) use case is if you want to produce excess Supplies above and beyond the available Mulch - perhaps because you are sending an expedition from your base that will not carry Agroponics. "Agriculture" makes Organics from the same ingredients, which are used in the production of Colony Supplies. What makes it break even is "Fertilizer (M)" or "Fertilizer (G)" which produces additional Fertilizer from Minerals or Gypsum. On top of this, "Greenhouse" is a mode which boosts the throughput of some "Cultivate" modules; "Crusher" is a mode (for material processors) which boosts the throughput of some "Fertilizer" modules. Big Agriculture modules (like Tundra) offer Agroponics, Cultivate, and Agriculture. These aren't, then, competing ways to keep up with normal Supplies replenishment; they're different functions for different jobs. "Fertilizer (M/G)" comes on material processors, the Ranger Crusher, and the Tundra Agricultural Support Module. The choice of ways to do things for a long mission is between bringing a huge amount of Fertilizer and bringing a way to dig up Gypsum or Minerals and one of these additional parts to make it into Fertilizer. For a long enough mission, the second option is the lighter one. On top of that, then, the second option uses up Machinery (but at a slow rate). There's then a similar choice between just sending a box of the stuff, or sending the modules and SpecializedParts to turn Recyclables back into Machinery, or sending the full kit to dig stuff up and make the SpecializedParts too. I _think_ the "boost" modules have no limit to the number of modules they can support, so a very large base can get more throughput from a tonne of boost module than a tonne of the boosted module. This kind of thing is meant to drive the MKS gameplay. When your base is just 3 kerbals for a short visit, you just bring Supplies. The longer you stay, the more incentive there is to ship in the stuff that's more mass-efficient in the long run, so you naturally have something to do with your base as time goes by.

I've posted a new version of the Module Manager config using some help from the MM thread, and which gives more realistic (high!) power requirements for Kerbal Foundries and stock wheels. However, I've run into the first real tangle. IRL, the NSTAR uses 2.1kW for 92 mN thrust. The KSP Dawn uses 8.74EC/s for 2kN thrust. If the thrust isn't adjusted, the electricity requirement will be enormous (ie, circa 40 _MW_), but if the thrust is adjusted, first of all I'm stepping outside my remit of just correcting EC usage and not worrying about parts like reaction wheels that do the impossible with it, and secondly ion burns will take weeks. (Indeed, if solar powers that 40MW engine, the burn will take weeks anyway...) I guess: if Persistent Thrust is installed, give the engine a realistic TMR and EC usage. It will only be useful with Persistent Thrust. No ion-powered aircraft or sticking rovers to Gilly with ions. If Persistent Thrust is not installed, since the Dawn masses almost exactly 10x as much as the NSTAR (with PPU, etc), increase the Dawn's EC draw by 10. This gives the "right" answer in terms of necessary solar/RTG capacity to run it, but gives you a lot of free thrust if you are, say, using a fuel cell to run it (where this is not a remotely practical option IRL). But I could say, well, even step 1 is outside my remit, and it'll just cause annoyance while eliminating some options which, while unrealistic, aren't unrealistic in terms of EC usage.

I don't wish to be the voice of cynicism (actually, I do) but if you examine their post history you will find the answer to that is almost certainly "no".

I play with FAR, so this may not help with stock aero, but that looks far more convincing to me than those stubby little wings and tiny control surfaces. The other craft just looks very short of control authority.

Gah, this is like being a LISP programmer. However, removing the extra square brackets doesn't make a difference. Sorry, I wrote that in a hurry. To be more clear: @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],!OUTPUT_RESOURCE:HAS[~name[ElectricCharge]]]:LAST[CAMREC] { does select an RTG that outputs LF.

Aha, but I can do: @PART:HAS[@MODULE[ModuleGenerator]:HAS[@OUTPUT_RESOURCE:HAS[~name[ElectricCharge]]]]:LAST[CAMREC] { %tags ^= :$: CAMRECnotRTG: } @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],~tags[*CAMRECnotRTG*]]:LAST[CAMREC] { @description ^= :$: CAMREC RTG buff.: @MODULE[ModuleGenerator] { @OUTPUT_RESOURCE[ElectricCharge] { @rate *= 3 } } } and that _does_ cut out the modified RTG that makes LF. Thanks.

Now I have @PART:HAS[@MODULE[ModuleGenerator]:HAS[!INPUT_RESOURCE,@OUTPUT_RESOURCE[ElectricCharge]:HAS[#rate[>0]]],!OUTPUT_RESOURCE:[HAS[~name[ElectricCharge]]]]:LAST[CAMREC] { Unfortunately, this still selects the RTG that also outputs LF. (Is there a way to test for the number of output resources, please? That would fix all my problems.) @PART:HAS[@MODULE[ModuleResourceConverter]:HAS[@INPUT_RESOURCE:HAS[#ResourceName[LiquidFuel]],@INPUT_RESOURCE:HAS[#ResourceName[Oxidizer]],@OUTPUT_RESOURCE:HAS[#ResourceName[ElectricCharge]]],!OUTPUT_RESOURCE:HAS[~ResourceName[ElectricCharge]]]:LAST[CAMREC] { likewise selects a fuel cell modified to output monoprop as well as EC. I'm pleased to say the MODE deletion rune worked fine. Thanks.

KSP 1.9.1, installed only Hangar, SmartParts, and their dependencies (AT Utils, MM, CRP, KSP AVC) via CKAN. If I put down a Box Fairing in the VAB and right-click it, "Edit Contents" doesn't appear, and there's no Hangar button on the toolbar. http://www.chiark.greenend.org.uk/~damerell/games/ksp/hangar/ has the logs. "Cannot find a PartModule of typename 'Hangar'" and "Cannot find a PartModule of typename 'SimpleHangarStorage'" seem curious. (The AT Utils install at the very least looks just like the one I have in a non-clean install where it _does_ work). Anything else you need, please?