Here is a picture of the new setup I am using for documentation
- 04-25-2025, 18-32-26.png (1.91 MiB) Viewed 45 times
Previously there was a 3 tick delay that needed to be accounted for. In order to ensure timings were accurate I adjusted things and also investigated exactly where the delay was coming from, to ensure accuracy in the data. What I found was the clock itself is perfectly accurate, if it is hooked up to a source directly it will always display the value exactly. There is a 1 tick delay while it turns on, but the clock also starts counting at 1 instead of 0 so these cancel out completely. The clock itself also has no shutdown delay, because when it no longer pushes the next second through the combinator, meaning its instantaneous. So of the 3 ticks from before, 0 were from the clock.
Doing some testing I found the inserter consistently has a delay of 2 ticks being enabled via circuit condition. I confirmed this by setting up two clocks, one was enabled alongside the inserter, the other when the inserter picked up its first item, and there was a consistent 2 tick discrepancy. I also tried various other methods of enabling the inserter and measuring and consistently replicated 2 ticks. Not sure why this behavior exists, but it is consistently replicable. Also by coincidence I noticed that if you manually insert the item into the inserters inventory, it actually spins 1 tick faster than normal, implying that 1 tick is used picking up the item. This isn't relevant though since that's not related to the discrepancy, I just thought it was neat. Anyway that means 2 ticks for the inserter, and we know the final tick was for data to re enter the circuit network through a combinator to control the master signal.
Seeing the inexplicable 2 tick delay on the inserter raised concerns over whether there was delay on the power switch too, as this would impact measurements. There was no good way to devise a test for this, so I just slowed down the gamespeed and watched the indicator light on the machine. Personally I believe I observed it also being 2 ticks. I think the 2 ticks is 1 tick for combinator delay, even though it was manually enabled the output is still 1 tick slow, and the second tick is the machine processing it was enabled. This may seem trivial but its important for testing. Thankfully both are identical so there are no issues with the accuracy of the measurements. All of this means we still need to subtract 3 ticks from the measured time like before though
I found the originally measured speeds were completely accurate upon rechecking, but because this post is meant to double as an improvement over the previous documentation I'll list them clearly below
Inserter Speeds
- Burner Inserter: 76 ticks per transfer
- Yellow Inserter: 70 ticks per transfer
- Red Inserter: 50 ticks per transfer
- Blue Inserter: 24 ticks per transfer
Now for the electrical testing. The methodology followed this time was basically identical to last time aside from the decoupling of the power grids as mentioned previously. Because the test no longer ran to death, a circuit condition was established using the accumulators charge reading. An important detail to mention at this time is accumulators read to the circuit network via a rounded percentage rather than an actual reading in joules. What this means is that the circuit network reads 0% when there are still 25kJ left in the accumulator. This needs to be removed from the total 5MJ for accuracy, giving us an effective power test of 4.975MJ
Electrical Data
- Yellow Inserter: 4.975MJ / 48,933 ticks, 700 item transfers
- Red Inserter: 4.975MJ / 33,920 ticks, 679 item transfers
- Blue Inserter: 4.975MJ / 14,353 ticks, 599 item transfers
- Green Inserter: 4.975MJ / 5,061 ticks, 211 item transfers
- Stack Inserter: 4.975MJ / 2,552 ticks, 107 item transfers
Code: Select all
type = "burner",
fuel_categories = {"chemical"},
initial_fuel = "wood",
initial_fuel_percent = 0.25,
. Even increasing the game speed to max this took a very long time. Here is the data below, with the 4.5MJ data included since its a similairish figure to the electrical data that we already have.Burner Data
- Burner Inserter: 4.5MJ / 68 item transfers ; 20.0005GJ / 29,903.5 item transfers
Breaking that data down into average wattage we get:
Average wattage at peak throughput
- Burner Inserter: ~52.815 kW
- Yellow Inserter: ~6.1 kW
- Red Inserter: ~8.8 kW
- Blue Inserter: ~20.797 kW
- Green Inserter: ~58.98 kW
- Stack Inserter: ~116.967 kW
Firstly, what is "item spike". This was the term used to define max power spikes during inserter behavior, which generally only occurred during item pick up and drop off.
- 04-24-2025, 00-12-56.png (10.46 KiB) Viewed 45 times
Code: Select all
{
name = "inserter",
energy_per_movement = "5kJ",
energy_per_rotation = "5kJ",
energy_source = { type = "electric", drain = "0.4kW" },
extension_speed = 0.035,
rotation_speed = 0.014
}
The key to deciphering this data is realizing the speeds are in tiles per tick for the extension and percent rotated per tick for the rotational. So using our example inserter we have 0.014 * 60 (to convert to seconds), and you can see this gives us 0.84, which is very close to our empirically measured speed in spins per second. Its actually a little low though, because doing doing 60 / 70 we get ~0.857, which is a decent amount higher. After checking against our item rate, we see that to move 700 items at the games programmed speed we would have needed to run for 50000 ticks, but we actually only ran 48933. To confirm this I reran the test, but instead of waiting to run out of power I stopped it at exactly the moment it began the 700th item transfer, or in other words completed 699 cycles. That time was 48930 ticks exactly, and when I divided it by 70 it gave me a perfect 699, confirming that 70 is the actual speed. This happens because the game rounds its math. In order to move half the swing (which is the base unit as it never moves more than 180 degrees at a time) it would need ~35.7 ticks, and there is no fraction of a tick so it truncates it. The fact this is done every half spin instead of whole spin is important to remember because the blue inserter as an example has a spin speed that evenly divided into 25 ticks for a whole spin, but because it only does half spins that 12.5 becomes 12, which is why our time is 24 ticks.
Anyway now that we have the games rated number, it also claims to use 5kJ across the spin. We will try the calculation with both our empirical speed and the games theoretical speed, and to do this we simply multiply the speed by 5kJ. This makes 4.2kW theoretical, ~4.286 kW empirical.
Now we need to calculate the extension power using the same rules. 0.035 * 60 * 5 = 10.5. This is the theoretical, so now we will try to confirm it empirically. For this we will need the games extension activity time, which I will continue to refer to by the previous term "item spike duration". I will generate a table for each inserter to check against for easier readability. The data is acquired by setting the game speed to 0.01 and then just watching the power panel and counting, assuming the behavior follows a square wave.
Item Spike Duration
- Yellow Inserter: 5 ticks
- Red Inserter: 4 ticks
- Blue Inserter: 1 tick
In order to calculate further we need to determine the travel distance of the extension. Based on our empirical tick duration we can derive 0.035 * 5 = 0.175, assuming the games speed is accurate (which is rare lol). I figured it would be more accurate to know the distance from the start so I dove back into the games code and found this
Code: Select all
//Yellow Inserter
pickup_position = {0, -1},
insert_position = {0, 1.2}
//Red Inserter
pickup_position = {0, -2},
insert_position = {0, 2.2}
Also just a fun observation before we move on, this means by default inserters face upwards. Also while we're on the topic of directions there is something of a myth that inserters behave differently based on their orientation. So far the math strongly suggest otherwise to me, and I just quickly measured a couple things in the alternate orientation, nothing too comprehensive or anything, but I saw no difference.
Anyway now we can finally check if the theoretical power matches the empirical data. I'll be using empirical speeds for the calculations as we've already confirmed they're more accurate. So we have 10 ticks in a cycle of extension, so that's 0.04 * 10 * 5 = 2 kJ. Then we have the ~4.286 kW from before, giving us ~6.286kW. If its accurate this number should match our number from before for average power draw during testing. And it doesn't, fun
We know that our average power consumption was 6.1, or 5.7 without drain, which leaves 1.414 unaccounted for. Multiplying by 6 gives us ~8.486kW, and we can confirm averaging these numbers for the testing gives us back 6.1, so its empirically accurate. This creates a new mystery though because that would mean our peak power is ~12.77, but the games power panel clearly tells us that it is 15kW, and likely its actually 15.1 as is the stated max power, but the power panel is rounding it. It also means that games value of 5kJ would actually be ~3.536 with our 0.04 speed, which is starkly different.
Doing another quick empirical test I powered on the inserter on a separate grid from the accumulator and tested how long it took to do its initial extension when it receives power for the first time, as well as how much power that took. The circuit network was set to "end" the test when it registered it picked up the first item, which is assumed to be the moment it finishes extending. To get the distance traveled, I was able to find the specification in the code base
Code: Select all
starting_distance = 0.85Checking the speed, if it extends 0.15 in 7 ticks its moving ~0.0214 units per tick, which means we now have a third potential speed number
. Before taking this speed at face value, while I observed the power on behavior carefully in slow motion in the game, and found that even after grabbing the item it continued to show the same 5 ticks of item spike as before, meaning it was still doing some kind of lateral movement for some reason despite having reached the item. That means its possible the movement actually took 12 ticks and it just grabbed the item early by reaching the hitbox. That would mean the speed is even slower than the already slow speed so I'm going to guess that it might be preemptively moving to the next position in advance, and that would explain why item spike happens after the item gets picked up and not before. That means its possibly moving 0.35 in 12 ticks, for a speed of ~0.02917, which is now a fourth speed. It also just doesn't make sense how it could be moving 0.2 in 5 ticks, but 0.15 takes 7. All these different numbers are very frustrating, and ultimately the goal was to confirm whether the games rated kJ of 5 was accurate after accounting for rounding errors, so lets try to work backwards from there since we have a kW estimate. Removing the drain we have 10.4kW, divide by 60 * 5 equals ~0.0347. And holy crap, thats actually super close to the games original value! Which makes it all the more baffling that no matter which way we multiply this number by the duration it doesn't add up. According to the math it should have taken just 4 ticks after the truncated rounding to move 0.15, but if it moved between 7-8 ticks worth of this distance it would be somewhere between ~0.2427 - ~0.2773. It seems likely that the actual number would be 0.25. I went and watched the power panel extremely carefully during its initial boot up with the inserter disabled, and found that it actually take a full 10 ticks to complete the process. There is one tick of initialization spike, and then 9 ticks of extension. The initialization spike is its own mystery sort of, but we won't delve into that today. So in my mind what this is confirming is the inserter actually moves 0.35 units, to a total extension of 1.2. That process would take it exactly 10 seconds. And this almost makes sense, except for the games code claiming the 1.2 value is for the insertion position, or in other words the drop off, and this is the pickup position which is supposed to be 1. It also means we probably hit some kind of hitbox at 1.1, though after scouring the games code I couldn't figure out where anything like that is defined. Its also worth noting how when powered on enabled you can see it still do the full 5 ticks of item spike after the 7 ticks initial extension, yet even though it does 3 more ticks of extension disabled the subsequent item spike is still 5 ticks. All of this to say, its haunted and we should give up on a fruitless battle. While it would have been nice to get this to make sense, we ultimately have all the information we need so I'm just gonna move on from what has proven to be a long and useless tangent.
Ultimately we were able to confirm the games values are accurate as far as wattage goes, just not joules or time. This means those earlier numbers we derived based on our measurements actually shouldn't be used, as they're artificially heightened by the rounding error as calculating the extension power established. So we'll apply our theoretical numbers of 4.2kw and 10.5kw, and then we will just apply them to our empirical speeds, and that should give us the most accurate data. Like most things in life it became very complicated before ultimately returning to simplicity.
At this point we should address the burner, which we promised to circle back to. With what we know now we can estimate its power spike duration, so I'll make another copy of that table here with that included
Item Spike Duration
- Burner Inserter: 5 ticks
- Yellow Inserter: 5 ticks
- Red Inserter: 4 ticks
- Blue Inserter: 1 tick
Cost per item transfer (excluding drain)
- Burner Inserter: 66.9 kJ
- Yellow Inserter: 6.65 kJ
- Red Inserter: 7 kJ
- Blue Inserter: 8.12 kJ
- Green Inserter: 23.2 kJ
- Stack Inserter: 46.4 kJ
That should be everything I wanted to say. I ended up chipping away at this over several sessions so hopefully its coherent and not too rambling. I mainly wanted to make this post to help document some of the process behind these numbers incase it ever needed revisiting, as posting all the information directly to the wiki would obviously be excessive. I'll be uploading a condensed version of the practical info to the wiki, along with updated graphs, under the Inserters page. If anyone has any questions or wants me to look into additional data this is a good place to request that