emiliofloris

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

5 Neutral

About emiliofloris

  • Rank
    Bottle Rocketeer
  1. 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.
  2. 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.
  3. 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.
  4. 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!
  5. 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.
  6. 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.
  7. 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?
  8. 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.
  9. 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).