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 . . .

Try changing terrain detail level.

Yeah it's not hitting the suborbital condition. I added a debug and see that I often get a zero thrust update before it packs the vessel. Unfortunately it looks like the TimeWarp.WarpMode is still set to HIGH mode so not sure if there is any way to know that it is going into warp. Maybe hack around it by ignoring the first 0 thrust update if throttle is non-zero? // Realtime mode if (!this.vessel.packed) { // if not transitioning from warp to real // Update values to use during timewarp if (!warpToReal) { IspPersistent = realIsp; ThrottlePersistent = vessel.ctrlState.mainThrottle; //ThrustPersistent = this.CalculateThrust(); this.CalculateThrust(); ThrustPersistent = this.finalThrust; Debug.Log ("Thrust " + ThrustPersistent + " timeWarp mode = " + TimeWarp.WarpMode); } } (Filename: /Users/builduser/buildslave/unity/build/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Thrust 1.877129 timeWarp mode = HIGH (Filename: /Users/builduser/buildslave/unity/build/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Thrust 1.877128 timeWarp mode = HIGH (Filename: /Users/builduser/buildslave/unity/build/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Thrust 0 timeWarp mode = HIGH (Filename: /Users/builduser/buildslave/unity/build/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) Packing space telescope for orbit (Filename: /Users/builduser/buildslave/unity/build/artifacts/MacStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

I've seen this too. The warp throttle stays at the right percent, but warp thrust goes to zero Mn when entering warp. It doesn't happen 100% of the time, so toggling warp on/off/on/off until the thrust 'sticks' usually works. I suspect there is some kind of race condition going on where it might be getting 'thrust = 0' before 'hey we're in warp now' sometimes, but this is just guesswork. That worked pretty well too. It's a quite a bit heavier payload to feed the hungry hungry AGI core (5MW!) for the long journey with fission, but is certainly more near-term tech realistic .

BTW, this was quite useful for doing the gravitational lens experiment. Got the telescope out to 550 AU (and completed braking into orbit) in just a couple years with a fusion powered vessel, running the boron reaction.

I get the same issue on mac where the addon disables. It is caused by non-default value in the window position fields. Maybe fractional pixels are just a Mac thing, but the window location can end up with floating point positions. However, the config parsing tries to read as an integer. If you don't move the window but leave it in the default upper left corner position, the problem doesn't happen. Example config segment: SM_Windows { ManifestPosition { x = 296.4063 y = 423.332 width = 320 height = 282 } } I guess it either needs to be written as integer or parsed as float to squash this bug. Some exception-handling to revert to default config mightn't hurt either.

How about movement of EnrichedUranum? Ammonolysis doesn't work since the ISRU cannot feed EnrichedUranium from tanks, that would be a necessary factor for ISRU replenishment.

This is in the KSPI-E patches folder, not coming from TAC. Looks like some attempt had been made to do something with TAC previously?

Okay, space plane is now equipped with the new RCS blocks. Huzzah! Successfully completed the Kerbin -> Eve surface and return mission without using the warp drive

A simpler justification may be that it is actually stored in gaseous form (and cryogenic power reqt can be removed, if there?). The Lqd would then just mean that the units are liquid-liter-equivalent.

I just use a similar procedure as the x64 hack from Windows. So far it's been much more stable for me. The windows x64 community workaround thread has dire warnings of bugs and instability but for me it's been painless. And really almost anything is better than suffering KSP's load time several times an hour. This is with FAR + SXT + Ven's + KSPI + a few other smaller mods like science alert, so it's okay for (lightly?) modded installs too. Note, x64 did NOT work with a big RSS + RO + FASA modded install. That one either locked up or had significant graphical corruption of 2d elements like the navball and staging list, when going from VAB->launchpad. On the other hand, 32-bit mac KSP couldn't even boot that mod set without crashing, so I have exiled it back to the Windows bootcamp partition . BTW, this does not actually fix the memory leak -- I still see memory leaking on scene changes (f9 quickload, launching new rocket, going back to space center) in the Activity Monitor. The difference is that the process will happily keep running at up to 50GB used. At this point my MacOS starts complaining about running of space on the system partition due to the ever-growing swap file. Still, it takes a loooong time to reach that point, so I am happy enough. And there are no obvious swap thrashing performance issues, so the OS seems to do a good job of keeping the actual stuff in memory rather than the leaked