Topics and discussion about specific mods
MasterBuilder
Filter Inserter
Posts: 325
Joined: Sun Nov 23, 2014 1:22 am
Contact:

Is there any way to change the stack size?
I'm planning a 90/s science factory and this (rough estimate using a planner) requires 151.3 blue belts of iron plates alone.

Now, I can merge a row of 5 smelters into a single blue belt, but at that rate, I'd need to do that 31 times (30.26 exactly).
Which means I'd need a 1->5 balancer going into the row of 5 smelters, and 5->1 leaving.

31 odd numbered balancers (x2 for both in & out) is both ugly to look at, and takes up a lot of space.

With a stack size of 8, 1->8 & 8->1 balancers are super easy, not ugly to look at, and knocks the total output lanes down to 19.
Give a man fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life.

Smart Inserter
Posts: 1944
Joined: Fri Nov 06, 2015 7:41 pm

MasterBuilder wrote:
Mon Apr 01, 2019 2:20 am
Is there any way to change the stack size?
I'm planning a 90/s science factory and this (rough estimate using a planner) requires 151.3 blue belts of iron plates alone.

Now, I can merge a row of 5 smelters into a single blue belt, but at that rate, I'd need to do that 31 times (30.26 exactly).
Which means I'd need a 1->5 balancer going into the row of 5 smelters, and 5->1 leaving.

31 odd numbered balancers (x2 for both in & out) is both ugly to look at, and takes up a lot of space.

With a stack size of 8, 1->8 & 8->1 balancers are super easy, not ugly to look at, and knocks the total output lanes down to 19.
There is a constant in the code you can change. However be warned that the maths does not work out well in nearly every other case, for a few reasons. 4 and 10 are about the only other viable options. I'd back up your factory first.

MasterBuilder
Filter Inserter
Posts: 325
Joined: Sun Nov 23, 2014 1:22 am
Contact:

Mon Apr 01, 2019 2:26 am
There is a constant in the code you can change. However be warned that the maths does not work out well in nearly every other case, for a few reasons. 4 and 10 are about the only other viable options. I'd back up your factory first.
It's a new save and I'm only experimenting with the logistics of the setup right now.
I found two constants, one at the top of control.lua (local STACK_SIZE = 5) & one in prototypes/shared.lua (DBL.STACK_SIZE = 5). Changed both to 8 and it seems to be working well:
(Changing the first one by itself didn't do anything noticeable so I'm not sure what it affects, the second seemed to change the recipe to 8<->1 so that worked.)

Is there any change you could add this as a "Mod Settings" option? Having to change this each update would get problematic. (Though, if it does cause a math problem, I can understand why you wouldn't want to.)

> However be warned that the maths does not work out well in nearly every other case
What math does not work well? This seems ideal to me. Here's my test case. 360/s in, 45/s compressed out.
Untitled.png (1.72 MiB) Viewed 751 times
Give a man fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life.

Smart Inserter
Posts: 1944
Joined: Fri Nov 06, 2015 7:41 pm

MasterBuilder wrote:
Mon Apr 01, 2019 3:04 am
> However be warned that the maths does not work out well in nearly every other case
What math does not work well? This seems ideal to me. Here's my test case. 360/s in, 45/s compressed out.
Untitled.png
The full answer to that is somewhere in the previous 26 pages, but briefly, if the stack size is not a common factor of 50, 100 and 200 (and every other native stack size) you will lose inventory density. There were also timing issues but I don't remember the detail and they may play out differently now that belt speeds have changed a bit. Short story, I think it always should have been 4, but then they went and made ore stack size 50, so 5 was the best compromise.

mrvn
Smart Inserter
Posts: 4050
Joined: Mon Sep 05, 2016 9:10 am
Contact:

My suggestion goes kind of one step further though. I'm saying that no recipe should be needed for belt boxes. Instead the function that creates belt boxes can take the recipe for splitter, replace the previous splitter with the matching belt box and use that.

Think of it as a default recipe. If no recipe is given for the belt box then it is auto generated. That way existing code keeps the recipe it sets. But new code can decide weather to set a recipe or accept the generated one. Once the library function does that the vanilla tires table can drop the recipe and the integration mod too. Or whatever mod will replace it. That way any change Bob (or other mods) do to the recipe will instantly show up for the belt boxes too without having to modify the integration mod to match.

Smart Inserter
Posts: 1944
Joined: Fri Nov 06, 2015 7:41 pm

mrvn wrote:
Mon Apr 01, 2019 9:31 am
My suggestion goes kind of one step further though.
It usually does.

Repeat: It is up to the author of third-party mod add-ons, or the overhaul mod authors themselves, to change it if they want it changed. Talk to them.

mrvn
Smart Inserter
Posts: 4050
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Mon Apr 01, 2019 9:50 am
mrvn wrote:
Mon Apr 01, 2019 9:31 am
My suggestion goes kind of one step further though.
It usually does.

Repeat: It is up to the author of third-party mod add-ons, or the overhaul mod authors themselves, to change it if they want it changed. Talk to them.
How are they going to change that your API will generate the belt box recipe from the splitter recipe when none is given?

Smart Inserter
Posts: 1944
Joined: Fri Nov 06, 2015 7:41 pm

mrvn wrote:
Mon Apr 01, 2019 10:30 am
How are they going to change that your API will generate the belt box recipe from the splitter recipe when none is given?
Because the API will let you specify whatever recipe you want. See the code in public.lua, further documentation coming Soon.

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

Regarding dynamic recipe generation: it's extremely easy for the mod generating the recipes to base the recipe they pass on their splitter (or whichever entity they deem appropriate). I don't need to do that work for them, since my code to do that would naturally have to be more complicated - I don't necessarily know which splitter is theirs, if they even add one for that tier (there's an optional 'splitter' parameter still in the API call, but it's currently not used - it's just there to maintain compatibility for re-adding the belt style overhaul in the future). Base mod's staying as simple as possible, sorry!

Regarding having a mod setting to change stack sizes: I just realized that there's an 'allowed_values' parameter on integer type settings so it might actually be possible to allow a setting which selects from only the 'safe' values. All of the obvious caveats will apply about changing stack-size on existing saves, I expect increasing density might cause some epic 'spill' conditions. Will test, stay tuned.

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

Yup, it'll work - the devs sneakily fixed a limitation on furnace input stacks in 0.17 so it actually seems to have gotten a lot easier to support variable stack sizes without timing problems or stack size mismatch issues that would prevent the beltbox from functioning in a bunch of edge cases.

Currently accepting opinions on stack sizes which should be options other than 4, 5, and 10 - will get that released after I track down this pesky third-party-loader recipe unlocking bug.

MasterBuilder
Filter Inserter
Posts: 325
Joined: Sun Nov 23, 2014 1:22 am
Contact:

Mon Apr 01, 2019 8:54 am
The full answer to that is somewhere in the previous 26 pages, but briefly, if the stack size is not a common factor of 50, 100 and 200 (and every other native stack size) you will lose inventory density. There were also timing issues but I don't remember the detail and they may play out differently now that belt speeds have changed a bit. Short story, I think it always should have been 4, but then they went and made ore stack size 50, so 5 was the best compromise.
I understand now. Part of the confusion was me using 'stack size' to refer to both the compressed stack value (#items needed to make the compressed stack), and 2: The stack size of the compressed stack.
With a compressed value of 8->1, the stack size of the compressed item becomes 12 which decompresses to 96/100 iron ore, or 48/50 for whichever items use that size.

I honestly don't mind the slight density loss since working with multiples of 8 is so much easier logistically.
I'd still love to have the "Mod Settings" option to change this so updates don't reset things. Please?
Give a man fire and he'll be warm for a day. Set a man on fire and he'll be warm for the rest of his life.

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

MasterBuilder wrote:
Mon Apr 01, 2019 6:42 pm
I honestly don't mind the slight density loss since working with multiples of 8 is so much easier logistically.
I'd still love to have the "Mod Settings" option to change this so updates don't reset things. Please?

McDuff
Fast Inserter
Posts: 219
Joined: Sun Jan 11, 2015 11:09 am
Contact:

I actually think having a slight "stored density loss" is kind of a cool little trade off, but then I also don't super-optimise my rail transport and prefer to massively squeeze belts full of stacks (honestly now not sure I can go back to vanilla without this mod as I've got so used to it).

GrumpyJoe
Filter Inserter
Posts: 361
Joined: Fri Apr 06, 2018 7:10 pm
Contact:

kingarthur wrote:
Sun Mar 31, 2019 3:17 pm

Ya deadlock4pyanodon doesnt update the vanilla stacks. I've messaged crisdec that it needs updated
just found another one, but thats even wierder (maybe not if vanilla sulfur stacks to 50, havn´t played that in a long time)

unstacked sulfur stacks to 500 with pY, sulfur(stack of5) to 10

sorry for the ping if its the same "problem" (or already fixed, server admin is lazy with mod updates)

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

GrumpyJoe wrote:
Wed Apr 03, 2019 5:27 pm
kingarthur wrote:
Sun Mar 31, 2019 3:17 pm

Ya deadlock4pyanodon doesnt update the vanilla stacks. I've messaged crisdec that it needs updated
just found another one, but thats even wierder (maybe not if vanilla sulfur stacks to 50, havn´t played that in a long time)

unstacked sulfur stacks to 500 with pY, sulfur(stack of5) to 10

sorry for the ping if its the same "problem" (or already fixed, server admin is lazy with mod updates)
Yup, that should be corrected in the 2.1.5 version - get that admin to update

eduran
Filter Inserter
Posts: 344
Joined: Fri May 09, 2014 2:52 pm
Contact:

Could you add an optional dependency for ReStack, so DBL adjusts stack sizes after ReStack? Without that, ReStack changes the stack sizes of stacked items to match those of the base items.

Edit: Just found this, so you are already aware of the issue. I hope you change your mind and add the dependency. Otherwise I am going to have to apply the change myself on every mod update

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

Sigh. It's frankly a bit much to declare that your mod is going to edit every item in the game, and any mods whose items should not be edited must have a dependency on your mod and then go back in and undo its changes at the very last possible step in the loading process.

Restack ought to have a mechanism for mods to tell it that their items shouldn't be edited or something like that, so that we don't have to just keep playing the "I'm loading after you so my mess is yours to deal with" game between mod authors.

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

On a completely different note: I'm trying to figure out why the base game still seems to occasionally try to use stacking and unstacking recipes as intermediate recipes for handcrafting under certain situations - I've been able to reproduce it myself by importing a gigantic mod set but I haven't quite pinned it down.

If anyone else is seeing this, let me know - I think we've got a bug in the game to track down.

Smart Inserter
Posts: 1944
Joined: Fri Nov 06, 2015 7:41 pm

eduran wrote:
Thu Apr 04, 2019 8:41 am
Edit: Just found this, so you are already aware of the issue. I hope you change your mind and add the dependency. Otherwise I am going to have to apply the change myself on every mod update
This was ages ago, before I handed the mod over to shane. In those days I did add a dependency for Restack and Regroup, because it was the only way to catch their changes. Restack didn't touch DSB stacks at that time, though, I only did it so that the DSB items matched the changes Restack made to native vanilla stack sizes.

I agree with shane, if some mod is going around altering other mods' data without asking, it is literally their problem to fix.

PS. Mod authors who think it's a good idea to make sweeping changes to vanilla data in data-final-fixes are the worst.

Fast Inserter
Posts: 125
Joined: Thu Feb 08, 2018 8:25 am
Contact:

Sat Apr 06, 2019 3:04 pm
Restack didn't touch DSB stacks at that time, though, I only did it so that the DSB items matched the changes Restack made to native vanilla stack sizes.
This is still the case, I misunderstood one of the bug reports in thinking that it was fiddling with the stacks. Since it's less headache than trying to work around and people keep reporting it, I went ahead and re-added the optdep on ReStack, as well as pinging Optera on discord to see if they're willing to add any ability to integrate with ReStack to make this less painful - maybe we can get rid of this dependency in a couple versions like the bobplates one.

I also added a function to the API to help out any mods which need to know the number of items in a stack - since there's a startup setting to alter it now, other mods might need to know how 'big' a stack is, and digging into the recipes to find that info is a hassle. The 'direct stack smelting' experimental option in https://mods.factorio.com/mod/deadlock-experiments has been updated to use this, and have the recipes adjust to whatever you've set in the base mod's options.

Edited to add: if you use ReStack, those direct smelting speeds will end up wrong, because otherwise the experiments mod would need to run all of its recipe additions after ReStack - which I won't fix, and which is a great demonstration of why it's so bad for ReStack to be waiting until so late in the loading process to do anything at all.

### Who is online

Users browsing this forum: Mernom