Factorio Forums

slippycheeze wrote: Fri Aug 16, 2019 6:57 pm

Deadlock989 wrote: Fri Aug 16, 2019 3:07 pm

Zyrconia wrote: Fri Aug 16, 2019 2:07 pmThanks for the answer. That setup should work!

I mean feeding 5 belts in like this was awkward: https://i.imgur.com/ZihiJBS.gif

It would be - 5-way balancers aren't ever going to win any beauty contests.

But there's no reason you have to feed in 5 belts unless you are going for complete maximal efficiency at all costs and you want that fully compressed fully stacked belt. I've built a megabase that used buses with 4 lanes of belts, each fed by 4 sources, using the 5x stack setting, and there were no issues at all with running that. It just means there are some gaps on the bus when it's running at full speed, which is basically never. It's still a 16x bus that looks like a 4x bus.

Alternatively, use the 4x setting. The mod was originally set to 4x but because vanilla ores stack to 50 and 50 isn't divisible by 4, the default was made 5x.

Or use 4x and install some other mod that changes ore stacks to 100.

...or or, just feed them in sequentially so that you gradually increase density as you move along, rather than having all the compression devices horizontally aligned. The inverse of your output filters, even.

mrvn wrote: Mon Sep 09, 2019 2:09 pm A while back ores icons got extended to a random icon from a set to break up the monotomy of ores on belts.

I noticed though that stacks of ores only have one icon. It would look better if the stacks would generate a set of stacks from the set of original icons so they get the same uneven look on belts.

Note: I don't know if manually provided icons for stacks can use the randomize feature. If not add that to the request please.

Deadlock989 wrote: Mon Sep 09, 2019 2:54 pm

mrvn wrote: Mon Sep 09, 2019 2:09 pm A while back ores icons got extended to a random icon from a set to break up the monotomy of ores on belts.

I noticed though that stacks of ores only have one icon. It would look better if the stacks would generate a set of stacks from the set of original icons so they get the same uneven look on belts.

Note: I don't know if manually provided icons for stacks can use the randomize feature. If not add that to the request please.

Last time I talked to shane about it, we planned to give all the stacked icons a refresh, but only when Wube release the full set of 64x64 icons. No ETA on that but we know that 1.0 is getting nearer month by month, so it'll be some random day between tomorrow and Christmas 2020 by my guess.

Don't want to speak for shane but he might want to have a go at ores in the meantime. For that matter, if anyone else thinks they could produce fully mipmapped stacked ore icons, in 4 variants each, from the base game icons, for each of the four vanilla ores, at least as a temporary stopgap until we get all of the high res icons, they could have a go? But it's shane's call to make whether they'd be included. So that's 16 icons in four different resolutions each, in the correct "diminishing squares" mipmap format. I think I put a mipmap parameter into DCM, don't remember what we did for DSB, but we didn't add randomisation support at that time, certainly.

That said, "randomised" icons don't necessarily have to be mipmapped though, to be honest I have a hard time spotting the difference between a baked-in mipmapped version and the default interpolation the renderer does without pre-supplied mipmaps. IR's random ores aren't mipmapped for example, I set it all up, tested, could see no visual difference. My guess is that mipmapping works best for icons that carry symbolic meaning, like assemblers and power poles, not blobs of ore.

API-provided stack icons from mods could also use the feature, sure, for any arbitrary item. I tried it with plates. It looked horrifying in a way that ores totally don't. Might involve an extra parameter in the API calls, but no sense in overthinking until anyone actually has the assets to use it with. I haven't even done random stacked ores for IR, because in IR you can't stack ores, just like DSB 1.0.0 was originally set up.

Loaders have also had some extra graphical structure support added since we last requested it, things that were originally refused (a year ago? don't remember) like the ability to set render layer, back_patch etc. and that should/could help with some of the issues from back in the day, so I would ideally like to give at least the loaders and maybe the beltboxes a bit of a touch-up as well, using some of the tricks I picked up in the meantime.

So it's all wanted and doable, but I think we both just lack the time right now.

mrvn wrote: Mon Sep 09, 2019 3:40 pmTo be clear: I was talking primarily about the generated icons when no better icons are provided. The ones where you simply stack 5 original icons on top of each other.

That part would be algorithmical so no need to wait for the base game at all.

mrvn wrote: Mon Sep 09, 2019 2:09 pm A while back ores icons got extended to a random icon from a set to break up the monotomy of ores on belts.

I noticed though that stacks of ores only have one icon. It would look better if the stacks would generate a set of stacks from the set of original icons so they get the same uneven look on belts.

Note: I don't know if manually provided icons for stacks can use the randomize feature. If not add that to the request please.

MasterBuilder wrote: Mon Sep 09, 2019 10:13 pmI too got annoyed by the lack of variance on the ores. I made a quick mod over the weekend: https://mods.factorio.com/mod/Prettier-Stacked-Ores
It's just the original ore [mipmap] icons with a wooden chest beneath them.

Nothing fancy, but it gives them variance & keeps them visually distinct.

marcelgrilo wrote: Fri Sep 20, 2019 9:29 pm it would be nice if we could connecct the loaders with wires and have the same behaviour as the filter inserters

BlindPumkin wrote: Sun Oct 06, 2019 2:06 am Love the idea. Not sure how to get it working.

Adding the loader to the belt causes belt to stop.

Any guidance anyone?

Deadlock989 wrote: Mon Sep 09, 2019 3:46 pm

mrvn wrote: Mon Sep 09, 2019 3:40 pmTo be clear: I was talking primarily about the generated icons when no better icons are provided. The ones where you simply stack 5 original icons on top of each other.

That part would be algorithmical so no need to wait for the base game at all.

Oh. No chance then We even talked about taking that feature out. I don't think entirely seriously. It should never have been in the mod, is my view.

shanemadden wrote: Mon Oct 07, 2019 5:01 pmMy 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.

Deadlock989 wrote: Tue Oct 08, 2019 9:33 am

shanemadden wrote: Mon Oct 07, 2019 5:01 pmMy 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, the question is, whether distributing a Python script along with the mod would be a straightforward enough proposition for non-Python modders, or straightforward enough to make it worth the effort ... It would have to have some wrinkle in it for dealing with the mipmapped versions as well (currently only ores, but we don't know what's coming in the icon refresh, maybe all icons will be mipmapped, no-one outside of Wube knows).

Alternatively if you enjoy passing notes under a door to an eldritch horror from another dimension, ImageMagick scripts are good at this sort of thing as well.

Then there's Photoshop batch scripts, but that's commercial software (my legit version is from 2003).

When I did the original 32x32 icons for DSB, about half of them were only automated in Photoshop, the remainder were tweaked manually in some way, usually minor but not always. Some things just don't look like anything using that method, e.g. batteries.

DraLUSAD wrote: Tue Oct 29, 2019 7:33 am

Here is a bug I found when laying down a saved blueprint, it seems that loaders facing east to store something, it faces the other way when laying down the blueprint (most notably, when placing one down in editor)

mrvn wrote: Mon Oct 28, 2019 11:26 am 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.

mrvn wrote: Tue Oct 29, 2019 5:30 pm Despite multiple reports according to Deadlock this bug does not exist and it's you doing something wrong or having broken mods do something wrong.

If you want your blueprints to place loaders right you have to disable the snapping in the mod options. It's the snapping code that turns those loaders around the wrong way. The drawback is that manually palcing loaders won't automatically switch between loading and unloading for you. You have to often place and rotate (50% of the time basically).

Magnetix wrote: Wed Oct 30, 2019 10:10 pm I apologize in advance if these issues have already been discussed...

I have an issue in the tech tree when using bob's mod... The Tier 1 (White) compact loader will not work until the Tier 2 (Yellow) compact loader is researched. I suppose this is a trivial issue however it would be nice to be able to unlock the stacking function once the white one is researched.

Also, I was curious if there are any plans to include extended bob's items to the list of compacting items? I find that capacitors are in extremely high demand like resistors and am forced to use multiple belts in the old school bus configuration to keep up with the demand.

Many thanks for your mod, it makes the game a LOT more fun for me to play!

-Magnetix

shanemadden wrote: Fri Nov 01, 2019 11:27 pm

mrvn wrote: Tue Oct 29, 2019 5:30 pm Despite multiple reports according to Deadlock this bug does not exist and it's you doing something wrong or having broken mods do something wrong.

If you want your blueprints to place loaders right you have to disable the snapping in the mod options. It's the snapping code that turns those loaders around the wrong way. The drawback is that manually palcing loaders won't automatically switch between loading and unloading for you. You have to often place and rotate (50% of the time basically).

As I think I've asked before, give me a blueprint string and combination of mods and settings that reproduces this and I'll fix it; every test I've done builds properly in situations like this, and every time I've found an issue it's another mod's snapping stuff that's screwing up.

2692.136 Script @__deadlock-beltboxes-loaders__/control.lua:78: on_built_entity({
  created_entity = {
    __self = "userdata"
  },
  item = {
    __self = "userdata"
  },
  name = 6,
  player_index = 1,
  stack = {
    __self = "userdata"
  },
  tick = 25439
})
2692.136 Script @__deadlock-beltboxes-loaders__/control.lua:80: entity type = loader
2692.137 Script @__deadlock-beltboxes-loaders__/control.lua:81: entity direction = 4
2692.137 Script @__deadlock-beltboxes-loaders__/control.lua:87: entity loader_type = output
2692.137 Script @__deadlock-beltboxes-loaders__/control.lua:99: there's a belt facing toward the belt-side of the loader, so we want to be in input mode

2703.452 Script @__deadlock-beltboxes-loaders__/control.lua:78: on_built_entity({
  created_entity = {
    __self = "userdata"
  },
  name = 6,
  player_index = 1,
  stack = {
    __self = "userdata"
  },
  tick = 26118
})
2703.453 Script @__deadlock-beltboxes-loaders__/control.lua:80: entity type = entity-ghost
2703.453 Script @__deadlock-beltboxes-loaders__/control.lua:81: entity direction = 0
2703.453 Script @__deadlock-beltboxes-loaders__/control.lua:84: invalid
2703.485 Script @__Bluebuild__/control.lua:124: calling ghost.revive()
2703.486 Script @__Bluebuild__/control.lua:138: rasing on_put_item
2703.486 Script @__Bluebuild__/control.lua:140: raising on_built_entity
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:78: on_built_entity({
  created_entity = {
    __self = "userdata"
  },
  mod_name = "Bluebuild",
  name = 6,
  player_index = 1,
  revive = true,
  tick = 26120
})
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:80: entity type = loader
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:81: entity direction = 0
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:87: entity loader_type = input
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:112: there's a loadable entity on the belt end but not on the loader end, flip around and go into input mode to load it up
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:117: not facing belt

2692.137 Script @__deadlock-beltboxes-loaders__/control.lua:81: entity direction = 4
2692.137 Script @__deadlock-beltboxes-loaders__/control.lua:87: entity loader_type = output

2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:81: entity direction = 0
2703.487 Script @__deadlock-beltboxes-loaders__/control.lua:87: entity loader_type = input