emiliofloris

Glad to hear you are happy. It has become so rare to see happy people these days, especially in the KSP community. One quick question: Could you name any specific aspects that actually got better since the "first real gameplay" video was released three years ago? Just to silence the naysayers. Also, I would really love to know the ratio between the respective budgets for marketing and QA and how you managed to do all that crazy testing without being able to save the state of the game reliably. Being somewhat involved in software testing myself, I would love to be inspired by your innovative methods and techniques!

I came here because I had exactly the same issue. The main problem with this contract is that it explicitly requires only one day of electric power, which can be provided by a battery, even though implicitly the satellite needs to be powered permanently. Perhaps the best way to go would be to remove the one-day power requirement altogether. Without Kerbalism power consumption for unloaded spacecraft is zero anyway, and with Kerbalism the condition is redundant.

I prefer IE because it's more complicated ;). Seriously: NFT, as nice as it may be, feels almost cartoonish in comparison. I very much like the ion and plasma engines, but one shouldn't forget that they are literally overpowered by a factor of 1000. It's possible to build a plasma engine lander for Duna with NFT! That is just not right. I would like NFT better if the low-thrust engines were integrated into the Warp Plugin framework and the reactors nerfed, because with respect to power generation IE is much more interesting and flexible. On the other hand IE has a highly idiosyncratic scaling policy with its gigawatt reactors and often doesn't really fit into the Kerbal universe. In summary, I would very much like to use the good elements of both, but out of a personal preference for complexity and realism I voted for IE.

My icon is working fine (but I saw the same problem several times recently, always caused by some mod folder not quite being where it was supposed to be), but I'm having a different problem in 1.11.2. I'm starting from a clean installation with only the latest FAR and the bundled MFI: I then go into the Sandbox and check the FAR analyzer on a simple plane. As long as I don't use any dedicated aerodynamic elements it seems to work ok, and I can do both Mach and Angle-of-Attack sweeps. When I add any wing or other lifting/steering surface, things go wrong and the Mach sweep quits doing anything, The log file shows the following error: Full log file is here: https://www.dropbox.com/s/c2395hsxnqlxmzi/KSP_farproblem.log?dl=0

I would like to give you some (positive) feedback on this amazing suite of mods. Using the information on the RSS/RO/RP-1 wikis and threads I got it to work on a fresh 1.11.2 installation without major problems by downloading the latest releases from the various github repos (And Sarbian's Jenkins, although the link on the RO thread is broken. Going to the parent page works fine: https://ksp.sarbian.com/jenkins/job/SmokeScreen-RO/). I'm running it on a rather mediocre system (8GB/2GB laptop) and didn't try any fancy graphics yet, but I could play through the tutorial mission without any glitches. Now I'll just have to spend a few months learning how to use all the additional features... For reference, here is the full mod list from the Module Manager log:

Thanks for looking into the problem! I tried again and realized that it is related to the lights issue described by @Juba. Here you can see that the sun is visible and casts shadows but the sky is pitch black:

When I load both Module Flight Integrator and Kopernicus (and nothing else), the sky on Kerbin turns black. Here are the log files: https://www.dropbox.com/s/05x4pz047kitk7e/KSP.log?dl=0 https://www.dropbox.com/s/8h7rx37v1kcre0u/Logs-Kopernicus.zip?dl=0 Game version is 1.11.2. Loading them separately works fine.

I ran into a similar issue, tried the fix but saw no change. Here is what happens: I have four refrigerators at different scales. Power consumption works as expected, but output is the same for all four. It's not intake-limited, I can turn off one intake and production doesn't change. Another issue: Time warping reduces production/sec. This seems to be a general problem with KSPIE, looking at the waste heat, MegaJoule and charged particle indicators you can see that the total capacity gets scaled up, for waste heat and charged particles in direct proportion to the time acceleration. The rate of change doesn't. Liquid Argon capacity stays the same, but production rate is scaled down. This seems very strange. Using HyperWarp or physics warp gives the same results. A minor comment: What does "mT" stand for in the atmospheric intake? I suppose it's the same as "U", so production for Argon is 0.0093*Intake. But how does it relate to the next line? And another one: Argon production is a lot more profitable than space tourism. In fact my main motivation to try out the refrigerator was rank greed.

I lose the fuel type selection widget, but it must be a conflict with some other mod because with KSPIE-only it works fine. I haven't updated everything to the latest version, so perhaps it's best to ignore the issue unless other people have the same problem.

Yes, I got confused with the k twice, 1EC is of course 1kJ (1EC/s = 1kW), that's just a typo from me, but I completely overlooked the k in the electrostatic thrust. You are right, they are grossly overpowered. It might perhaps be justifiable in terms of time compression, normal ion engines run for months or longer, and that's not easily possible in KSP. That Tokamak, on the other hand... Fission reactors are working hardware, and the FT reactors have reasonable power/mass ratios compared to prototypes. Assuming that you can achieve a ratio 2000x higher than any current design in the first available fusion reactor is very bold. Personally I would say that the factor of 10-20 in the downscaled version might be more realistic. By the way, the 1.20.13 InterstellarFuelSwitch seems to kill the fuel tank type selection. Using an old version (from June this year) works ok as far as I can tell.

I recently ran into the conflict between Interstellar and Near Future, and took some time to understand the compatibility problems, especially the relative performance of NF and KSPI-E nuclear reactors. As far as I understand, the main issue is that NF and KSP stock employ a little gremlin whose only function is to transfer heat from a colder to a hotter reservoir, without expending any additional energy. This puts KSPIE at a disadvantage because thermodynamic processes are modeled more accurately, requiring the generator's cold bath to be in thermal equilibrium with the radiators. A problem in comparisons is that KSPIE uses a completely different energy scale. In NF, EC/s is directly equated to Watts. Reactor output lies in the few MW range, and electric engines are modeled with more or less realistic parameters in terms of mass and power consumption. KSPIE, without the NF patch, uses GW-scale reactors scaled down in size to fit into the KSP framework. Taking the example of a Tokamak, the KSPIE version has a mass of slightly more than 20 metric tons, and a power output of 2-10 GWth. This results in a power/weight ratio of approximately one thousand times more than optimistic estimates for future ground-based commercial reactors, the ITER reactor currently under construction has a weight of 23,000 metric tons and an expected power output of 500 MW. This is quite a mismatch, and leads to inconsistencies. Radiators in the uncorrected version are essentially assumed to be perfect black bodies with a power emission of 5.7x10-8 W/m2 x T4. Their area is increased by a factor of 2, and then again by 60%. The first factor of two is in my opinion incorrect, because the nominal area shown in the description already appears to account for the two-sidedness. I checked the large folding graphene radiators, and they seem to have an extension of 7x10m = 70m2, the description says 140 m2, and the area displayed in the KSPIE VAB tool is 448 m2. I am not quite sure if the factor of 1.6 is due to physics (three-dimensional structure of surface?) or simply rebalancing. Regardless of whether the factor of 3.2 should be applied or not, it seems to be the case here that reactor output per unit mass is vastly higher than it would be in the real world, while the radiators are modeled in agreement with reality, at least to the order of magnitude. In practice this means that outsized amounts of radiators are required to achieve reasonable generator efficiencies, further putting KSPIE at a disadvantage compared to NF. The solution in my opinion lies in using the downscaled (patched) power outputs and requirements, along with treating the radiators as black bodies with nominal area. I tried this in my own version (1.4.5/1.20.13) by replacing %areaMultiplier = 0.01 with %areaMultiplier = 0.3125 in Patches/USI_NF_Mode.cfg. The result is shown in the picture, for a 30 MWth (nominal) pebble bed reactor with an etamax=0.48 thermal generator and eight large folding graphene radiators. At equilibrium, power output is 7.48 MWe, resulting in a power-to-mass ratio of approximately 320 W/kg if radiators and the generator are included. For comparison, NF reactors are in the general range of 200-250 W/kg, Molten Salt without any upgrades is something like 30 W/kg, and the Tokamak starts around 100 W/kg if the 2 MW needed to sustain the fusion process is subtracted (but gets better quickly). The bottomline is that this configuration appears to be reasonable and competitive, and it might be worth considering to use it as default. Two more comments: First, I noticed that the thermal generator has a different mass depending to which reactor it is attached. Could this be included in the description? Or is there a table somewhere on a forum/wiki? Second, the hot bath for the Tokamak has a temperature of 160,000 K, so efficiency (which I assume is simply etamax*(1-Tcold/Thot)?) is always very close to the maximum, as long as the radiator can handle the excess heat. This seems unrealistic for a heat engine, where the generator would not operate directly on the plasma, but rather by means of a secondary cycle. And there is of course the question of whether a Tokamak could be scaled down arbitarily, but that I suppose is where some corners should be cut generously. In any case, overall I'm very very happy with this mod, although I haven't even got around to really try out all its functionalities. Keep up the good work, and let me know in case I misunderstood and/or inaccurately described something!

I looked a little more into the TORY ramjet issue, and here is my understanding of what's going on: By default, the nuclear ramjet uses the AtmosphericIntake module, defined in WarpPlugin (Collectors/AtmosphericIntake.cs). public override void OnStart(PartModule.StartState state) { if (state == StartState.Editor) return; // don't do any of this stuff in editor _moduleResourceIntake = this.part.FindModuleImplementing<ModuleResourceIntake>(); sets _moduleResourceIntake to null, because there is no ModuleResourceIntake module defined in the configuration. This means that public void IntakeThatAir() { if (_moduleResourceIntake == null) return; always returns right away, and no air is taken in. A quick fix is to replace MODULE { name = AtmosphericIntake intakeTransformName = Intake area = 0.01 intakeSpeed = 12 } by MODULE { name = ModuleResourceIntake resourceName = IntakeAir area = 0.01 intakeSpeed = 12 intakeTransformName = Intake } RESOURCE { // Avoid NullReferenceException name = IntakeAir amount = 2 maxAmount = 2 } resourceName = IntakeAtm will work on Kerbin, but not on Eve (didn't check any other atmospheres because I haven't gone anywhere else yet in my campaign game). The nuclear turbojet always works ok, because it requires an external intake.

The solution appears to be to comment out // this.CalculateThrust(); in ModuleEnginesWarp::OnFixedUpdate. I checked Vista and the Open Cycle Gas Core rocket, which are both based on ModuleEnginesWarp, and they seem to be ok now. The engines that weren't affected are all ModuleEngines(FX) I guess.

Don't know exactly how it works, but before the 1.4 upgrade the MechJeb prediction was always correct, so I thought it might be a bug. Might be worth checking, though. Can't you use the sandbox to build a Vista testbed?

I'm having problems with the Vista engine. As you can see in the picture, fuel flow is displayed as 111 Units/sec, but actually 221 (see resource panel). This means that I'm getting only half the predicted (and expected) delta-v. I haven't checked the other KSPI-E engines yet. Some other issues: - IntakeAtm doesn't seem to work in all atmospheres (for example Eve) - The plumes configured in WarpPlugin/RealPlume have vanished (also visible in picture) - ISRUProcessor/Extractor(Large).cfg should probably have DumpExcess = True for Spodumene -> Li, Li6, as it has for Salt. Otherwise Lithium and Lithium-6 can only be produced simultaneously, which doesn't make much sense. Maybe it would be a good idea to have separate modules for chemical processing and isotope separation? Related to the last point, one question: Is there a plugin that displays KSPI-E-specific resources such as Spodumene? It doesn't seem to work with SCANSat. Sorry in case I said something silly. As you can see on the left, I am still a noob.

In NuclearRamJet2.cfg : MODULE { // name = AtmosphericIntake name = ModuleResourceIntake // change name resourceName = IntakeAtm // insert line intakeTransformName = Intake area = 0.01 intakeSpeed = 12 } fixes the problem. I noticed that resourceName = IntakeAir also works, otherwise it wouldn't be possible to use external intakes. In that case RESOURCE { name = IntakeAtm amount = 0.9 maxAmount = 0.9 isTweakable = false hideFlow = false } doesn't apply. A side effect is that using air instead of atm makes the engine run indefinitely without flameout (even in space, although with 0.0 Newtons).