limitations to ModuleResourceConverter?

[seanth]

I think I might have found a limitation in how ModuleResourceConverter works when combining productions steps.

As a specific example, I have a setup where I am making liquid methane from CO2 gas pulled out of the atmosphere by a part + H2 gas being released from a tank by another part, and the rxn takes place in a 3rd part. So:

Atmospheric extractor ---> CO2 gas

Liquid H2 tank -->release valve part-->H2 gas

CO2gas+H2gas-->reactor part-->methane

methane-->compressor part-->liquid methane

There is very limited storage of both CO2 gas and H2 gas on the test setup. And I know this seems absurdly complicated, it's just how I set it up using parts I had been using for some biology-related reactions (production of H2 and CH4 from waste breakdown, and then their compression)

Everything works fine until I switch away to the space center, time accelerate, slow down time, and then return focus to the ship. Regardless of the amount of time accelerated, there is no increase in the product of the CO2 + H2

Am I correct in thinking that ModuleResourceConverter is doing the math to look at the time delta, finding there is not enough room on the craft to store the CO2 and H2 that would have been generated in that time frame, and just stopping the calculation? Without a calculation of the the intermediate products, any further rxns are not calculated using the time delta? Is this correct?

Maybe I need to skip the production of gas intermediates and just use and produce the compressed forms? So CO2+liquidH2 --> liquidMethane, or have something like biological breakdown input and output liquid forms of gasses (liquidMethane+liquidOxygen --> liquidCO2+liquidHydrogen, even though the CO2 and Oxygen are used in gas form with life support mods)

Guidance?

[simon56modder]

Maybe you can try using ModuleGenerator instead.

So what you can do is adding proper resources to the module in parts config.

MODULE
{
      name = ModuleGenerator
      isAlwaysActive = false
      activateGUIName = Turn on
      shutdownGUIName = Turn off
      INPUT_RESOURCE
      {
            name = InputResource1Name
            rate = rate
      }
      INPUT_RESOURCE
      {
            name = InputResource2Name
            rate = rate
      }
      OUTPUR_RESOURCE
      {
            name = OutputResourceName
            rate = rate
      }
}

[Diazo]

Actually, the issue is that ships outside the currently physics bubble "freeze" and don't process, the current time warp doesn't matter.

If you want to do that you need to either implement a "time passed" check every time the vessel initializes, or look at using the "Background Processing" mod which provides a frame work that does that for you.

D.

[seanth]

Actually, the issue is that ships outside the currently physics bubble "freeze" and don't process, the current time warp doesn't matter.

If you want to do that you need to either implement a "time passed" check every time the vessel initializes, or look at using the "Background Processing" mod which provides a frame work that does that for you.

D.

Oh! I had thought the ModuleResourceConverter worked on rails so you'd get the illusion that Ore processing was happening even when the craft is not selected. That would explain what I'm seeing.

I just did a test and the ModuleResourceConverter module on the ISRU Converter does work on rails. Give it a lot of Ore, and a big empty LiquidFuel tank, start it up, go to the space center, fast-forward time for a few days, go back to the craft, and the LiquidFuel tank is full.

I stand by my initial thought that the module is not able to link more complicated production strings.

EDIT #2: I edited RoverDude's inflatable airbags to act like excess gas balloon parts to hold intermediate gas products and everything works as I thought it should. So ModuleResourceConverter definitely needs intermediate products to have storage space, even if your setup would normally consume the intermediates immediately.

Edited July 6, 2015 by seanth

[AaronLS]

If ore conversion is written as suggested, such that conversion is calculated when it comes off rails based on time elapsed, then that would explain what you are seeing in your test, so it's creating the illusion of working on rails.

If that is true, then when you come off rails, to account for all the possible combinations lf complex workflows you might need to look at the time elapsed when you come off rails, divide that into many small intervals, and do iterative loop to calculate processing.

You could try to do it all at once, start with the beginning of the work flow to ensure later steps have input ingredients, but that doesn't account for intermediate tanks being overfilled, and vice versa starting at the last step to consume full tanks will fail when an intermediate tank is empty (but would otherwise incrementally fill from an earlier process).

An iterative method will mitigate error introduced from both problems. The smaller the interval thd better. You'll have to balance processing time with accuracy.