ElementConsumer does not respect capacityKG storage limitations

Need to subscribe to OnStorageChanged, and call OnActiveChanged from there. In OnActiveChanged perform the storage checks in addition to the operational checks. This prevents one or the other from switching it on and off when it shouldn't.

The 2/3rds efficiency comes from the water being satisfied but not the CO2 so the water scales back and uses what little CO2 it has.

1 minute ago, Risu said:

The 2/3rds efficiency comes from the water being satisfied but not the CO2 so the water scales back and uses what little CO2 it has.

How would the CO2 not be satisfied when it has kgs of storage of each?

1 minute ago, rezecib said:

How would the CO2 not be satisfied when it has kgs of storage of each?

The scrubber is actually one of the few element converters who never wait for enough mass to turn on. As it is always running it's constantly trying to convert what it can, so every time either water or CO2 is below the required amount it scales back the conversion to match the lowest amount available.
 

6 minutes ago, Risu said:

The scrubber is actually one of the few element converters who never wait for enough mass to turn on. As it is always running it's constantly trying to convert what it can, so every time either water or CO2 is below the required amount it scales back the conversion to match the lowest amount available.

But I'm observing the 200 g/s conversion rate even when it has 20kg water and 1000+ kg of CO2. There is a real bug there, not just a confusing display.

In fact, the only reason why the storage of CO2 cascades out of control is because it keeps dropping to 200g/s periodically.

See (the area around the scrubber is also over pressure with CO2 while this is occurring):

Edited June 19, 2017 by rezecib

9 minutes ago, rezecib said:

But I'm observing the 200 g/s conversion rate even when it has 20kg water and 1000+ kg of CO2. There is a real bug there, not just a confusing display.

In fact, the only reason why the storage of CO2 cascade out of control is because it keeps dropping to 200g/s periodically.

Been watching the scrubbers in your save and I'm seeing the 2/3 thing occasionally but never the 666.67 polluted water that would indicate that the conversion scaled back, so something is causing the scrubber to go nonoperational for a tick to screw up the rolling average on the production counter. Might be the power grid actually.
 

2 minutes ago, Risu said:

Might be the power grid actually.

At the time it is using 200 g/s, the power consumption of that subsystem is only 480W or 720W (depending on whether both pumps are running), with 800W generated. That particular subsystem is basically never strained and always has a full battery.

Edited June 19, 2017 by rezecib

52 minutes ago, rezecib said:

At the time it is using 200 g/s, the power consumption of that subsystem is only 480W or 720W (depending on whether both pumps are running), with 800W generated. That particular subsystem is basically never strained and always has a full battery.

I increased the time scale from 3 seconds to 10 seconds and I think I may have an idea what it's doing.

It's likely discarding the game tick that the time window is reset.

Edit: Here's how it usually looks at 60 seconds.

Wonder if it's actually lag causing it to skip game ticks? Either way not seeing anything wrong with the scrubber itself there.

Edit 2: Watched it at slow speed for a few minutes and it stayed at this the whole time.

 

Edited June 19, 2017 by Risu

9 hours ago, Risu said:

Either way not seeing anything wrong with the scrubber itself there.

It isn't just misreporting the usage, if you watch the storage it spikes when it dips into 200 g/s periods. Also, if it were actually consuming at 300g/s for both of them, then there would be no way for the storage to increase; the 7 natural gas generators can only produce 577.5 g/s of CO2, so they should be burning through their storage at a shared rate of 22.5 g/s.

I tried at all the normal game speeds and all of them ended up dipping into low-activity periods.

The element consumer ticks every 0.25 seconds from the simulator. The converter ticks every 1 second from its own timer.
These timers do not line up directly. The scheduler may in fact be losing game ticks from lag.
The simulator timer can't go out of sync because the game depends on it.

So it can build up CO2 faster than it can convert.
 

Edited June 19, 2017 by Risu

@Risu So that could be a bug with SchedulePeriodic in general?

I think I misinterpreted you when you said " not seeing anything wrong with the scrubber itself "-- I thought you meant that it was working properly and just skipping a tick in terms of accumulating numbers for display, but I guess you meant that nothing external is interfering with its function.

Right. The scrubber is doing what it is suppose to with the components it was given. The components are just at fault.
I think the scheduler should be getting its updates from the simulator timer, not the unity engine like it is doing now.
This is not the right time for real time timers. 

 

I'd imagine then, this can effect other buildings, like the Algae Terrarium as well?  When you drip water on it, as opposed to having Dupes feed it water?  If you over drip them, then they'd soak up more and more water the higher the lag gets?

This will be fixed next major update. (Experimental -> Public)
 

Came to report this same issue with scrubbers stopping conversion. I have the same setup as described by OP, enclosed room etc. One scrubber had 16,000 Kg of CO2 stored. Stops outputting polluted water or taking in water, keeps eating CO2.

This should be fixed in the latest hotfix(221295).