Crafting Speed Affecting Productivity Efficiency

[sectenor]

I discovered this while playing modded Factorio (Bob's et al) where the effect of the bug gets laughable (I maxxed it out at creating 93 steel gears from a single steel plate even though the productivity modifier on the assembler was only 260%), but I believe that the bug exists in Vanilla as well. I reproduced with an assembling machine 3 surrounded by normal beacons and using only vanilla tier modules to illustrate though. In my first attached screenshot, there is an assembling machine with 4 productivity module 3s granting +60% productivity. I hand fed this building 10 steel plates and it produced 16 gears, but oddly has a little bit of leftover productivity (I suspect that this may have something to do with the 1.25 crafting speed of the assembler). In my second screenshot, I added 12 beacons all with speed module 3s and hand fed the assembler 10 steel gears again. This time, there is even more of the unexpected leftover productivity. (no screenshot, but I also tried this on an assembling machine 2 with 2 productivity 3 modules; 10 plates in, 13 gears out, no incorrect leftover productivity)

[Ultros]

You need to specify that this is on .16, I'm not reproducing this on .17

[DaleStan]

I can repro it in 0.17 vanilla. I've attached a save game. Both assemblers have 100 iron plate. Turn on the switch. The speed boosted assembler will produce up to 70.1 gears, while the productivity-only assembler will produce far closer to 70.

For extra fun and games, the over-production of the speed-boosted assembler varies slightly depending on how long you wait between loading the game and turning on the switch. When the speed-boosted assembler stops, I've seen productivity bar widths at several different values from 1 pixel to 30. (Out of 287; I'm running at 125% GUI scale.) I've attached one instance where I saw 28 pixels of excess productivity in the speed-boosted assembler.

The productivity-only assembler always (though I checked this less often) had a one pixel-wide productivity bar.

[lvllord]

You need to specify that this is on .16, I'm not reproducing this on .17

From the screenshots it is 0.17 because of the hotbar.

[Boogieman14]

I seem to recall seeing a discussion like this a few years ago, also concerning Bob's modded modules. It's probably simple rounding errors (even in vanilla) that get magnified by the extreme increases Bob's modules give you.

[sectenor]

0.17.16 to be specific. I updated to 0.17.25 earlier today and am still seeing it. Yeah, with bob's mods magnifies the effect significantly. But as I mentioned in the post, I suspect that it has something to do with any time that a building speed's crafting speed is greater than 1.

[TruePikachu]

I seem to recall seeing a discussion like this a few years ago, also concerning Bob's modded modules. It's probably simple rounding errors (even in vanilla) that get magnified by the extreme increases Bob's modules give you.

I'll do the math here, on the Vanilla case. We'll assume IEEE754 double-precision floats for all numbers, with the exact rational result also given. System A has only productivity modules, while B is also beaconed by twelve Speed3 beacons.

1. Both assemblers have the same +40% productivity bonus; this means that every tick, the productivity bar will increase at (0.1 + 0.1 + 0.1 + 0.1) = 0.4 ≡ 3602879701896397/9007199254740992 times the rate of the normal bar.
2. The assemblers have differing crafting speeds:
   1. 1.25 * (1.0 - 0.15 - 0.15 - 0.15 - 0.15) = 0.4999… ≡ 4503599627370495/9007199254740992
   2. 1.25 * (1.0 - 0.15 - 0.15 - 0.15 - 0.15 + (0.5 / 2 * 24)) = 8.0 ≡ 8/1
   Note that A is just under 0.5 crafting speed, but the error from the 0.15 terms (which can't be represented exactly under IEEE754) becomes insignificant when the added speed from beacons come into play.
3. The recipe takes 30 ticks to complete at 100% speed; with the assemblers' crafting speeds, each tick, progress of the following fraction is made:
   1. 0.4999… / 30 = 0.01666… ≡ 300239975158033/18014398509481984
   2. 8.0 / 30 = 0.2666… ≡ 4803839602528529/18014398509481984
4. As a result, each tick, progress of the following fraction is made in the extra productivity bar:
   1. 0.01666… * 0.4 = 0.00666… ≡ 7686143364045645/1152921504606846976
   2. 0.2666… * 0.4 = 0.10666… ≡ 7686143364045647/72057594037927936
5. Using a simple function written in Common Lisp:

   Code: Select all

   (defun craft-time-for-n-crafts (n rational-progress-per-tick)
     (let ((progress-per-tick (coerce rational-progress-per-tick 'double-float))
           (current-progress 0.0d0)
           (current-time 0))
       (loop
         (when (zerop n)
           (return current-time))
         (incf current-time)
         (incf current-progress progress-per-tick)
         (when (>= current-progress 1.0d0)
           (decf current-progress)
           (decf n)))))

   the number of ticks required to consume 50 recipes worth of ingredients is:
   1. 3001 ≈ 50.017 seconds
   2. 188 ≈ 3.133 seconds
6. Using another simple function:

   Code: Select all

   (defun craft-results-for-n-ticks (n rational-progress-per-tick)
     (loop :repeat n
           :with result = 0
           :for current-progress = 0.0d0 :then (+ current-progress (coerce rational-progress-per-tick 'double-float))
           :do (when (>= current-progress 1.0d0)
                 (incf result)
                 (decf current-progress))
           :finally (return (values result current-progress))))

   the number of extra products from each assembler is:
   1. 20 + (4.885e-14 ≡ 55/1125899906842624)
   2. 19 + (0.94666… ≡ 2131703823622041/2251799813685248)
   Running for an extra tick (to remove off-by-one errors) yields:
   1. 20 + (0.00666… ≡ 7686143364101965/1152921504606846976)
   2. 20 + (0.05333… ≡ 240191980126439/4503599627370496)

There are probably some operation ordering differences, so these numbers might not reflect exactly what the game produces. However, it's likely that a large source of the error comes from the productivity bar increasing at a greater rate when speed boosts are in effect -- in particular, it's increasing slightly more than 10% an operation every tick on the boosted machine, while the slower machine can increase it in smaller increments but takes longer doing so.

As a note, if I run the testing for 5,000 ingredient cycles, I get, as productivity output, and with the extra tick taken:

1. 2000 + 0.00666…
2. 2000 + 2.776e-13

So, while things might become uneven in the short term, it appears you'd still be getting approximately the same number of products out in the long term, with or without the speed boost, under Vanilla module conditions. Do note, though, that if the amount of time it takes to craft gets well below one tick, the amount of progress made (on both normal and productivity bars) will be well above 100%, but since only one crafting operation can be completed per tick, the extra normal progress will be wasted while the extra productivity progress probably won't. This might be the actual underlying issue.

[Rseding91]

Thanks for the report however this isn't likely to ever be fixed. When a machine produces >= 100% progress per tick it simply breaks down and things stop working according to the numbers.

I don't want to change assembling machines to support producing > 1 crafts per tick because it would add a lot of overhead to every assembling machine even when they didn't do that.