Closed wchristian closed 4 years ago
I like the idea, but the underlying logic isn't that easy, because the inserters are too clever for us. I ran into similar problems in an earlier version of the mod. A desired feature is that if all belts are fully saturated and all machines not running, we want all of the machines to be "FULL". Unfortunately, this can happen with some machines having empty input buffers, which would then count as "BLOCKED" with the input-bound logic. This happens, because an inserter will not insert ingredients into a machine that already has a full output buffer. To reproduce, have an assembler build, say, pipes, and drip feed it iron on a belt, well below its production speed. It will assemble 3 pipes, and then stop. Its input will be empty, even though the belt has more iron.
Edit: I had written "STOPPED" where I meant "FULL".
You're right, and thanks for the explanation. Would it be possible to measure how full the output buffer of a machine is?
Just as a sanity check, do you think these function might be helpful in checking if the output inventory is blocked?
Oops. I can see I wrote "STOPPED" in the above where I meant "FULL".
I think the key to get the logic right would be to check whether the output buffer is below the limit that would allow for new ingredients to be inserted, e.g., something like:
if (running) state = "RUNNING"
else if (output >= limit) state = "FULL"
else state = "STOPPED"
I am not sure how this generalizes to recipes with multiple outputs or fluid output.
I'll postpone fiddling with the logic until the rewrite for the new graphics primitives of 0.17.
With multiple outputs you need to check each output on its own and can stop the check once you hit a single one that can't fit in, if i read that right.
Note that there's no way to check a limit. Instead you have to get the recipe, get the products from it, and try to check if each individual product stack could be inserted.
And if a big rewrite is coming up, fair to delay. :D
More than just graphics we have entity_status defines for .17! I have a mockup using both the status and the drawing system. It is crude and unoptimized but about a 50% improvement in speed and could easily be made as a control.lua "soft-mod". I'll post the code in a few days for you to peep.
This? https://lua-api.factorio.com/0.17.0-preview/defines.html#defines.entity_status
Damn, it looks like it'll make a lot of code superfluous. :D
Yup. The mod will basically only take care of swapping over the graphics. Ideally, it would just be a single table lookup what the new graphics should be, and this table could be configurable by the user.
Just because I wanted to do a similar calculation for a class I teach: The current version of the mod is said to cost 2 UPS on a big base, and if Nexela's estimates are true, 0.17 changes would cut this in half. That means that the savings would be 1/60 CPU load on each machine. Let's estimate the average gamer-CPU to use 60W. Thus, the savings i 1W/player. Factorio has, on average, 6k players at any given time, and let's assume (very optimistically) that half of them use the mod. That's a global 3kW saving. The mod has existed for 2.5 years, or ~20k hours. If the logic hadn't been Lua-bound all that time, the better code would have saved 60MWh, which equates around 30 tons of CO2 emissions, or more tangably, the full carbon footprint of 2 Danes over the same time period.
And yes, I am well aware that the calculations don't hold, even if the shaky estimates did: Since the mod "costs" 2 UPS, the machine would just have used the same time to simulate the factory a little faster. The game might even be slightly more enjoyable at the faster speed, so the player would play slightly longer, so the emissions might even be higher with the faster code...
Closed by #62
Note: This is my first time poking at Lua, and at Factorio modding, so other than intent, anything here can be wrong.
Previously all machines that were stopped and had some output waiting were counted as "full".
This meant machines that were lacking inputs but had some material still in the output tray, either sitting or being transferred out were given a yellow light instead of a red light.
This wasn't optimal, as "red" was easy to read as "materials missing", but when reading "yellow" as "the output is bottlenecking the machine" was sometimes correct and other times not.
After this change the "blocked" status is applied to machines that have a completed crafting cycle yet aren't working. This is marked with "yellow" and can be read with high confidence as "the output is bottlenecking the machine".
Stopped machines without a full crafting cycle are now marked as stopped or full separately, so one can still search for machines with stuff in them via the icon, but both are "red" now so it's easy as "bottlenecked due to missing inputs".