[MOD] Deadlock's Stacking Beltboxes & Compact Loaders

[mrvn]

I'm running the Beltboxes in batch mode. This is great for filling belts equally.

But for a while now I have 2 stacks of iron plates in my inventory. I can't unstack them. And every place I looked they always have a multiple of 4 stacks. Well, somewhere 2 stacks of iron plates must exist but no way to find them. Or maybe the aliens destroyed them.

I think it would be great if there was one recipe to unstack batches of stacks in belt boxes and another recipe to unstack single stacks by hand.

It's a bunch of extra recipe bloat to split hand recipes from machine ones, but it's doable - though I'm not really sure if the extra complexity is worth solving this one little annoyance.

Is the total number of recipes causing the game to slow down noticeable?

I would mark the batch unstack recipes as invisible and only show the non-batched recipes. So for the user there should be no visible bloat. They will only see the single unstack recipe and the beltboxes will only use the batched recipes.

[chrisdec]

hi,
i would like to know iff this mod is compatible with deadlock's industrial revolution

[billbo99]

Deadlock loaders work without issue, the belt boxes have some support (Ingots can be stacked for example). You would have to use deadlock's public API in your own mod if you want to stack ores, as he didnt want to the ores stacked.

[chrisdec]

Deadlock loaders work without issue, the belt boxes have some support (Ingots can be stacked for example). You would have to use deadlock's public API in your own mod if you want to stack ores, as he didnt want to the ores stacked.

well im getting an error when deadlock I.R. and Beltboxes mod's are activated

[mrvn]

Deadlock loaders work without issue, the belt boxes have some support (Ingots can be stacked for example). You would have to use deadlock's public API in your own mod if you want to stack ores, as he didnt want to the ores stacked.

well im getting an error when deadlock I.R. and Beltboxes mod's are activated

IR has a hidden depends on the minimum version of Beltboxes that's supported. So it definetly is and won't let you use older Beltboxes that are incompatible. And I've been playing with them for some time.

What kind of error do you get?

[chrisdec]

Deadlock loaders work without issue, the belt boxes have some support (Ingots can be stacked for example). You would have to use deadlock's public API in your own mod if you want to stack ores, as he didnt want to the ores stacked.

well im getting an error when deadlock I.R. and Beltboxes mod's are activated

IR has a hidden depends on the minimum version of Beltboxes that's supported. So it definetly is and won't let you use older Beltboxes that are incompatible. And I've been playing with them for some time.

What kind of error do you get?

im using the latest version from beltbox mod
i'll re activate it tomorrow and post a picture on the error i get

[chrisdec]

@mrvn,
this is the error im talking about

https://i.imgur.com/tyguL0e.jpg

[valneq]

Are Industrial Revolution and Deadlock's Stacking Beltboxes & Compact Loaders the only two mods that are active when this error occurs?
If no, please post a list of all mods that are active.

[chrisdec]

Are Industrial Revolution and Deadlock's Stacking Beltboxes & Compact Loaders the only two mods that are active when this error occurs?
If no, please post a list of all mods that are active.

i have a bunch off mods active
ill make a list off my mods tomorrow

[orzelek]

Are Industrial Revolution and Deadlock's Stacking Beltboxes & Compact Loaders the only two mods that are active when this error occurs?
If no, please post a list of all mods that are active.

i have a bunch off mods active
ill make a list off my mods tomorrow

This is a way in which IR reports incompatibility with other mods. You might want to disable mods you have in groups to figure out which one of them is causing this specifically and try to ask it's autor for a fix (aka IR compatibility).

[chrisdec]

Are Industrial Revolution and Deadlock's Stacking Beltboxes & Compact Loaders the only two mods that are active when this error occurs?
If no, please post a list of all mods that are active.

i have a bunch off mods active
ill make a list off my mods tomorrow

This is a way in which IR reports incompatibility with other mods. You might want to disable mods you have in groups to figure out which one of them is causing this specifically and try to ask it's autor for a fix (aka IR compatibility).

its this mod that triggers the error

https://mods.factorio.com/mod/specializ ... processing

[billbo99]

My tentative plan for when we get the high res base game icons is to set up some kind of automated way to generate stacked images from a base image, which if that worked out I'd provide to mod developers who want a quick path to make stacked icons without fiddling pixel-by-pixel in an image editor (and possibly support for variations of icons which have those). Assuming that, the warning about the performance hurt of generated icons might get more visible; probably not removing the feature entirely, but I definitely don't want to encourage its use due to the performance implications.

You can do this sort of thing easily in Python with a library like PIL or Pillow

Can you PM me some sample python code on how you would merge a factorio stock icon image 3x times with a slight shift ?

I am trying to use Pillow, the 'offset' command moves the image, but the graphics wrap around to the other side of the screen.

[chrisdec]

will there be an 0.18 update?

[billbo99]

A few of us have been looking, but we found that the direction/rotation of the loaders gets messed up when loading a save from a 0.17 to 0.18.

I have started to look at a migration script to auto-correct the "direction/rotation".

[Deadlock989]

Can you PM me some sample python code on how you would merge a factorio stock icon image 3x times with a slight shift ?

I am trying to use Pillow, the 'offset' command moves the image, but the graphics wrap around to the other side of the screen.

Like this:

Code: Select all

import os
from PIL import Image
from pathlib import Path

def create_newimage(output, input_64):
  i_64 = Image.open(input_64)
  i_64 = i_64.resize((56,56), Image.LANCZOS)
  newimage = Image.new('RGBA', (64, 64), color = (0,0,0,0))
  newimage.paste(i_64, (4,8), i_64)
  newimage.paste(i_64, (4,4), i_64)
  newimage.paste(i_64, (4,0), i_64)
  newimage.save(output)

finput = "./input/"
foutput = "./output/"

for dirpath, dirs, files in os.walk(finput):
    for filename in files:
        print(filename)
        create_newimage(foutput+filename, finput+filename)

It works, but in many cases it's ugly as sin. I did the original set with Photoshop macros and then edited some of the layers and icons by hand.

The above assumes a 64x64 image as input, but in 0.18.0 we have oddly upscaled 4 level mipmapped icons at 120x64 instead, seemingly generated from the original 32x32 versions. For the new mipmap format I would start with the leftmost 64x64 section of the stock icons and create the new 64x64 icon first, then downsize them from there. I haven't explored that yet but this is what I was using before to make 4-level mipmapped icons from simple 64x64 input:

Code: Select all

from PIL import Image
import os
from pathlib import Path

def create_mipmap(output, input_64):
  i_64 = Image.open(input_64)
  i_32 = i_64.resize((32,32),Image.LANCZOS)
  i_16 = i_64.resize((16,16),Image.LANCZOS)
  i_8 = i_64.resize((8,8),Image.LANCZOS)
  mipmap = Image.new('RGBA', (120, 64), color = (0,0,0,0))
  mipmap.paste(i_64, (0,0))
  mipmap.paste(i_32, (64,0))
  mipmap.paste(i_16, (64+32,0))
  mipmap.paste(i_8, (64+32+16,0))
  mipmap.save(output)
  

finput = "./input/"
foutput = "./output/"

for dirpath, dirs, files in os.walk(finput):
    for filename in files:
        print(filename)
        create_mipmap(foutput+filename, finput+filename)

0.18.1 seems to have properly shafted 1x1 loaders, at least as far as migrations are concerned. I don't have any interest in sorting that out, glad that someone else is looking at it.

[billbo99]

posila in 0.18.2 has attempted to fix the migration of "loader" to "loader-1x1" so that the correct direction and roation is kept.

viewtopic.php?p=476023

But I am getting some weird behaviour with the belts
-- the red box shows the belts on the output not joining to their next section correctly
-- the green box shows the loaders are not putting the items into the box they are getting from the spitters
-- on the right hand side .. loader to loader .. appears to be messed up too

Screenshot_1.png (1.64 MiB) Viewed 5575 times

[Deadlock989]

My guess would be that the transport lines are broken when the 0.17 loader entity is being migrated to a 0.18 loader-1x1 entity, and that posila has added a special case to migrations which mends the transport line for loader-to-belt and belt-to-loader but for not for any other kind of belt entity, like loader-to-loader or splitter-to-loader. We saw similar weirdness within 0.17 when the mod was removed from an existing save and orphaned bits of transport line were left adjacent to each other.

*shrug* RIP loaders.

[shanemadden]

My guess would be that the transport lines are broken when the 0.17 loader entity is being migrated to a 0.18 loader-1x1 entity, and that posila has added a special case to migrations which mends the transport line for loader-to-belt and belt-to-loader but for not for any other kind of belt entity, like loader-to-loader or splitter-to-loader. We saw similar weirdness within 0.17 when the mod was removed from an existing save and orphaned bits of transport line were left adjacent to each other.

*shrug* RIP loaders.

Back to the bug report line we wearily go;

Since we're here, just wanted to say a personal thanks again for all your passionate work on your mods for these years; watching the ringer you've gone through over IR from afar has been tough. You're appreciated, even though I know how easy it is to more than undo that positive with all of the negative. Thanks <3

[Deadlock989]

You're welcome. I thought about inflicting IR on you but decided that would be a cruel payment for looking after DSB so well.

It seems we don't really need to worry about mipmaps - posila confirmed that generating them as hardcoded sprites gives a pretty marginal benefit. So the Python script method above could be adequate if you did ever want to drop support for the multilayer method - maybe change the spacing, maybe add some outlines or drop shadow or some way to stop the three layers mushing into each other, thata would look OK - and there's no real need to worry about producing mipmapped stacked icons. I know people want compositing and image manipulation stuff built into the Factorio sprite loader but I don't think that's a reasonable ask for software that's a game, not an image editor, especially when modders can just do it themselves with tools they share amongst themselves.

As for whether 1x1 loader migration is permanently fucked or not, he's still working on it. If it's never fixed, I guess there are options:

1. Migrate them anyway and plaster warnings everywhere.

2. Start a completely new version of the mod, DSB2, so that people can only start new 0.18+ games with it. Maybe an opportunity to start fresh and get rid of all that garbled hand-holding I tried to do, and get rid of the multilayer icons.

3. Go outside and look at flowers and shit.

Personally I'm sticking with 3 but happy with whatever you want to do.

[darkfrei]

Why not normal 1x2 loaders?