ABZB

The need for chargedparticles isn't an explicit fuel - that is all in the magnetic nozzle code itself. Realfuels has an MM patch somewhere in the folder that switches anything using liquidfuel that doesn't get a custom engine config to use kerosene. You can either edit the MN engines to LqdHydrogen directly (also switch all the other LF stuff to LqdHydrogen then) or use a MM patch to do so. @PART[*]:HAS[@RESOURCE[Oxidizer]]:BEFORE[RealFuels] { @RESOURCE[Oxidizer] { @name = LqdOxygen } } @PART[*]:HAS[@RESOURCE[LiquidFuel]]:BEFORE[RealFuels] { @RESOURCE[LiquidFuel] { @name = LqdHydrogen } } @PART[*]:HAS[@MODULE[InterstellarMagneticNozzleControllerFX]]:BEFORE[RealFuels] { @MODULE[ModuleEngines*] { @RESOURCE[LiquidFuel] { @name = LqdHydrogen } } } @PART[*]:HAS[@RESOURCE[Ammonia]]:BEFORE[RealFuels] { @RESOURCE[Ammonia] { @name = LqdAmmonia } } @WARP_PLUGIN_SETTINGS:FOR[RealFuels] { @HydrogenResourceName = LqdHydrogen @OxygenResourceName = LqdOxygen @AmmoniaResourceName = LqdAmmonia }

I tried MM existing radial engines to work with the magnetic nozzle module (idea is to radially attach the engine to the reactor). This did not work. The radials had a thrust of ~495 KN and 66,500 isp, versus 120 KN and ~15500 ISP for an otherwise identical engine attached stack-wise. I *think* that the method by which the MN module searches for attached reactors must mess up somehow on surface attach nodes, but I am unsure as to why, or how that resulted in this.

On the other hand, sufficiently light spaceplanes using electric engines fed by ridiculous power can, for example, feed off of atmospheric CO2 or nitrogen for a good while (basically keep the tank topped off) (I have a magnetic nozzle-run craft I call "Little Zipper") I made a MM config for myself that re-purposes the KarbonitePlus awesome-looking engines (the ones that run of off karborundum) to use the KSPI magnetic nozzle, using LqdNitrogen as the fuel.

In the electric propellant config for CO2 there is a typo - the isp is "0,21987368" instead of "0.21987368"

The 2.5m Nitrogen Cryostat (FNNitrogenCryostat2) has a mismatching rate in the Compressor - the nitrogen rate given is 6458.83293, the rate needed to balance the reverse reaction in the other module (and complete the symmetry to the samller part) is 6593.98 . As is, you end up with a net increase in nitrogen.

Would it be possible for you to create a realchutes config for the parachute?

I can confirm that it checks if that vessel id # has already been used for the experiment: config = PluginHelper.getPluginSaveFile(); if (config.HasNode(vessel_seismic_node_string)) { science_node = config.GetNode(vessel_seismic_node_string); science_experiment_number = science_node.nodes.Count; if (science_node.HasNode(vessel_impact_node_string)) { Debug.Log("[KSP Interstellar] Impactor: Ignored because this vessel's impact has already been recorded."); return; } } else { science_node = config.AddNode(vessel_seismic_node_string); science_node.AddValue("name", "interstellarseismicarchive"); }

It might be tracking by the internal vessel ID thing

This might help (from the source code): /* * NOTE: This is a deviation from current KSPI behavior. KSPI currently registers an impact over 40 m/s * regardless of its mass; this means that trivially light impactors (single instruments, even) could * trigger the experiment. * * The guard below requires that the impactor have at least as much vertical impact energy as a 1 Mg * object traveling at 40 m/s. This means that nearly-tangential impacts or very light impactors will need * to be much faster, but that heavier impactors may be slower. * * */ if ( (Math.Pow(vessel.verticalSpeed, 2d) * vesselMass / 2d < 800d) && (vessel.verticalSpeed > 20d) ) { Debug.Log("[KSP Interstellar] Impactor: Ignored due to vessel imparting too little impact energy."); return; } It is possible if the decoupler is light enough, (inclusive) or the impact is glancing enough (large enough part of the velocity vector is not pointing into the surface), or if the impact altitude is very high (I suspect this might be more of a problem on bodies like Gilly), then the impact will be ignored. There might be a relevant message in the debug log.

Do you know what speed you hit the surface at? I think there is some minimum speed to trigger it.

Stupid question: did you tell it to "record impact data" before hand?

I simply added a Tank Definition for liquidnitrogen. (I use the module-managered integration of procedural parts into real/modular fuels): I copy/pasted boil temp and loss rate from liquid oxygen, if anyone has better numbers, please let me know. @TANK_DEFINITION[Cryogenic|BalloonCryo]:HAS[!TANK[LqdNitrogen]] { TANK { name = LqdNitrogen mass = 0.000808 utilization = 1 fillable = True amount = 0.0 maxAmount = 0.0 temperature = -183 loss_rate = 0.00000000002 note = (has insulation) } }

I concur! It looks awesome.

tweakscale has issues with the air intake stuff KSPI adds. You can either go into the tweakscale MM configs and delete all the ones that add tweakscale to air intakes. This is what to do if you are running an old version. if you are running the new version from this thread, there should be a link in the opening post to a modified tweakscale that fixes the issue.

I think KSPI assumes monopropellant is Hydrazine

Completely Compatible. I use both.

I've looked at the code on github, there is not an obvious bug - (looking at the .9 maintenance one, but I think this has been present for a while).

I have noticed that none of the reactors retrofit properly - the button is there, but clicking it removes the appropriate amount of science, but nothing else happens.

I posted a MM config for using the Plutonium-238 resource (in the resources that come with this mod, but unused). It modifies the stock RTG to hold that Pu-238, and generate electricity using the decay of that resource (using the same module that turns tritium to Helium-3). You can further edit the RTG to move it into an early tech node (which makes sense, we have had self-contained RTGs for probe power for decades). As it is a one-piece part, this solves the part count issue. It does not use wasteheat (an entire new module would be needed to make it work properly, and RTGs in RL are single-unit things anyway, it would not make sense to attach it to a separate generator part). The cfg can be obtained from my dropbox (it includes a mm patch which should moves the RTG to "Electrics": https://www.dropbox.com/s/g74fcjr7f7ps4dn/better_RTG.cfg?dl=0

You know, that might be what causes FAR to throw all of those errors wherein it says that the FAR module in various parts is not at the index it is supposed to be at! EDIT: On another note, in FNRadiator, line 440: Debug.Log("rd _Emissive: " + renderer.material.GetTexture("_Emissive")); is not commented out (causes debug log spam)

We've actually had discussions about how near/medium future advances in space tech will affect our business (importer/exporter of various grades steel)

KING OF THE LAB!! I honestly just did victory hands-in-air thing - it says something about the office I work in that no one took any note of that in any way.

Do you have tweakscale installed? it interacts with one of the modules interstellar runs on intakes (I think). Come to think of it, Has anyone tried removing tweakscale from all intakes and seeing if that fixes the issue? (it should - otherwise every part would do that glitchy thing (I think)).

I installed the latest release from Kerbalstuff, but none of the new planets show up in the tracking station (at level 2, if that helps). Am I missing something? Is there a conflict I might be unaware of?

I think I fixed it: I deleted custom biomes, and the problem stopped. I have no idea why that worked. When I first installed, I did not install custom biomes, and the problem started occurring (I think) after I later added it in.