bos

Could the cause be that the NF MM patch applies to InterstellarRefinery but the part actually contains a subclass called InterstellarRefineryController?

Yeah it looks like in the screenshot the reactor is scaled down to 2.42MW by NF mode, while the 'ISRU converter' is still demanding 6MW: 6MW is what it demands in stock mode, so it's not being scaled: The 600MW is just something that happens because the ISRU grabs stock EC if it can't find enough megajoules, and then the EC tries to put a huge demand on megajoules to replenish itself.

For mod authors, I take it this means that foreach is fine when compiled with Visual Studio or Xamarin Studio. And that these would be generally recommended over the old Unity monodevelop?

To me this module manager thing is probably the strongest argument I've seen for keeping the old policy. I was on the mod-author's side before, now I'm not so sure, if a dependency can just be yanked without notice, without clearing out dangling dependencies. Is the point you are trying to prove the opposite of what you are saying? I don't get it . . .

On the contrary, I just tried with a separate fresh install, and CKAN is basically completely broken now. Other mods that depend on Module Manager don't even show up in the list. Even if Module Manager is installed via manual dll. This includes mods for whom ckan is still the recommended install method. While I agree with your suggestion in general, I disagree for mods that could be considered core mods (Module Manager, Community Tech Tree, Community Resource Pack, and maybe Kopernicus come to mind). If a mod has enough different authors with dependencies, and the license is or has been a permissive one, then at least a week or two notice should be required to resolve the concern or find someone who will support it before delisting. There is no need things have to happen right now.

I assume the dll autodetection and dependent mods still work as long as you go grab ModuleManager directly? This feels hastily implemented and ill-thoughtout but maybe I am wrong (don't really want to test it on my install right now).

Okay, mods on which others are significantly dependent should be granted time in order to get a fork going under a new maintainer -- in case one of the dependent mod authors or an interested third party cares enough to take that on. In order to avoid the kind of knee-jerk unilateral nonsense illustrated here.

Can we hold off the nuclear triggers until someone writes an alternative mod manager that works? Please -- managing dependencies is so tedious by hand :/

Are you using RemoteTech? Sounds like the remotetech issue. If so, try the rebuilt dll from here until RemoteTech is updated for 1.1.3:

Simple recompile works okay for me (and I'm continuing my ro/rp-0 career in 1.1.3!). I did check in the dll binary so you could grab it from my github if you don't have the tools to rebuild it yourself: EDIT: <link removed since official release is up>

Do you have RSS DateTime Formatter? Contract parser tries to hard-cast the formatter to the default, which causes problems if you have a mod which replaces the formatter: private string timeInDays(double D) { if (D <= 0) return "----"; int[] time = ((KSPUtil.DefaultDateTimeFormatter)KSPUtil.dateTimeFormatter).GetDateFromUT((int)D); ...

One other minor item, the 'Cryogenic Engines' mod now uses a 15:1 ratio of units LqdHydrogen : oxidizer, but SETI-PartMod-PP-TankLiquid.cfg has a patch for procedural tanks that reverts it to 10:1 ratio. Probably Cryo used that ratio sometime in the past? TANK_TYPE_OPTION:NEEDS[CryoEngines] { name = LH2/OX dryDensity = 0.0764478 costMultiplier = 0.5625 RESOURCE { name = LqdHydrogen unitsPerT = 10256.41 } RESOURCE { name = Oxidizer unitsPerT = 1025.641 } } Can work around in-game by removing the excess oxidizer until KER reports max dV. Or just use non-procedural tanks. Those have the right ratio.

On the hybrid front, I'd say adding around 200 kg of dry mass per 100 kn of thrust would improve balance quite a bit. A big part of the issue with these is they have 3500 dV with no payload, which is around SSTO range. This much extra dry mass would drop them to 2800 dV before payload with almost no impact to their utility as a booster. It also makes sense that the oxidizer pumping / throttling mechanics would add some weight vs an SRB.

One minor bug report. The attachment nodes on the stackable Science Jr materials bay are wrong when both SETI & Ven's are installed. Stock has: node_stack_top = 0.0, 4.9, 0.0, 0.0, 1.0, 0.0 node_stack_bottom = 0.0, -4.10, 0.0, 0.0, -1.0, 0.0 Ven's changes the model and has: @node_stack_top = 0.0, .49, 0.0, 0.0, 1.0, 0.0 @node_stack_bottom = 0.0, -.41, 0.0, 0.0, -1.0, 0.0 But SETI overwrites the Y coordinates back to the stock values when adding size parameter so attachment nodes end up far from the part. //---SC-9001 Science Jr. @PART[science_module]:FOR[SETIrebalance] { @node_stack_top = 0.0, 4.9, 0.0, 0.0, 1.0, 0.0, 0 @node_stack_bottom = 0.0, -4.10, 0.0, 0.0, -1.0, 0.0, 0 Was easy enough to fix up in my install but flagging it since Ven's is on the recommended list.

Shouldn't it be realism overhaul that is replacing all engine modules with realfuels engines? RO is an overhaul / total conversion mod . . . note the part specifically says "non RO" in the screenshot which means it is not guaranteed compatible. Realfuels alone should be far less impactful . . .