Crafting Speed Affecting Productivity Efficiency
Crafting Speed Affecting Productivity Efficiency
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)
- Attachments
-
- 20190413105658_1.jpg (801.47 KiB) Viewed 11089 times
-
- 20190413105724_1.jpg (794.23 KiB) Viewed 11089 times
Re: Crafting Speed Affecting Productivity Efficiency
You need to specify that this is on .16, I'm not reproducing this on .17
Re: Crafting Speed Affecting Productivity Efficiency
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.
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.
- Attachments
-
- Extra productivity.png (66.06 KiB) Viewed 11070 times
-
- Productivity Test.zip
- (949.04 KiB) Downloaded 128 times
-
- Filter Inserter
- Posts: 770
- Joined: Sun Sep 07, 2014 12:59 pm
- Contact:
Re: Crafting Speed Affecting Productivity Efficiency
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 don't have OCD, I have CDO. It's the same, but with the letters in the correct order.
Re: Crafting Speed Affecting Productivity Efficiency
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
- Filter Inserter
- Posts: 978
- Joined: Sat Apr 09, 2016 8:39 pm
- Contact:
Re: Crafting Speed Affecting Productivity Efficiency
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.Boogieman14 wrote: ↑Sat Apr 13, 2019 9:35 pmI 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.
- 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.
- The assemblers have differing crafting speeds:
- 1.25 * (1.0 - 0.15 - 0.15 - 0.15 - 0.15) = 0.4999… ≡ 4503599627370495/9007199254740992
- 1.25 * (1.0 - 0.15 - 0.15 - 0.15 - 0.15 + (0.5 / 2 * 24)) = 8.0 ≡ 8/1
- The recipe takes 30 ticks to complete at 100% speed; with the assemblers' crafting speeds, each tick, progress of the following fraction is made:
- 0.4999… / 30 = 0.01666… ≡ 300239975158033/18014398509481984
- 8.0 / 30 = 0.2666… ≡ 4803839602528529/18014398509481984
- As a result, each tick, progress of the following fraction is made in the extra productivity bar:
- 0.01666… * 0.4 = 0.00666… ≡ 7686143364045645/1152921504606846976
- 0.2666… * 0.4 = 0.10666… ≡ 7686143364045647/72057594037927936
- Using a simple function written in Common Lisp:the number of ticks required to consume 50 recipes worth of ingredients is:
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)))))
- 3001 ≈ 50.017 seconds
- 188 ≈ 3.133 seconds
- Using another simple function:the number of extra products from each assembler is:
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))))
- 20 + (4.885e-14 ≡ 55/1125899906842624)
- 19 + (0.94666… ≡ 2131703823622041/2251799813685248)
- 20 + (0.00666… ≡ 7686143364101965/1152921504606846976)
- 20 + (0.05333… ≡ 240191980126439/4503599627370496)
As a note, if I run the testing for 5,000 ingredient cycles, I get, as productivity output, and with the extra tick taken:
- 2000 + 0.00666…
- 2000 + 2.776e-13
Re: Crafting Speed Affecting Productivity Efficiency
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.
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.
If you want to get ahold of me I'm almost always on Discord.