[MOD] Deadlock's Stacking Beltboxes & Compact Loaders

Topics and discussion about specific mods
Zyrconia
Fast Inserter
Fast Inserter
Posts: 220
Joined: Fri Dec 02, 2016 8:16 am
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by Zyrconia »

This is a great mod! Mixes up things and makes the experience fresh!

Plus, I no longer know how to do optimal trains stations. I'm experimenting with little one vagon "dart" trains, with 2 on the same line to try to keep throughput high.

Has anyone figured out a train setup that best takes advantage of this mod?

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

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by mrvn »

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 pm
Thanks 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. :)
Why even pay for the splitters? Simply place 5 belt boxes in a line with (un)loaders. The middle box goes straight to the belt. The others side feed the middle belt. Then turn on the mod option to work in batches so both sides of the belt are used equally.

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

Request: Generated stacks of ores should use multiple icons

Post by mrvn »

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.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1982
Joined: Fri Nov 06, 2015 7:41 pm

Re: Request: Generated stacks of ores should use multiple icons

Post by Deadlock989 »

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
Smart Inserter
Smart Inserter
Posts: 4284
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: Request: Generated stacks of ores should use multiple icons

Post by mrvn »

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.
To 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.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1982
Joined: Fri Nov 06, 2015 7:41 pm

Re: Request: Generated stacks of ores should use multiple icons

Post by Deadlock989 »

mrvn wrote:
Mon Sep 09, 2019 3:40 pm
To 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.

User avatar
MasterBuilder
Filter Inserter
Filter Inserter
Posts: 331
Joined: Sun Nov 23, 2014 1:22 am
Contact:

Re: Request: Generated stacks of ores should use multiple icons

Post by MasterBuilder »

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.
I 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.

Edit: If you grabbed version 1.0.0, I ooped when I split it from another mod. Updated version [1.0.1] tested and working.
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.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1982
Joined: Fri Nov 06, 2015 7:41 pm

Re: Request: Generated stacks of ores should use multiple icons

Post by Deadlock989 »

MasterBuilder wrote:
Mon Sep 09, 2019 10:13 pm
I 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.
Unless you have Crating Machine installed as well, which does pretty much the same thing to represent crates. So almost no way of telling crated ore and stacked ore apart.

Probably not an issue though as I don't think many people, if anyone, uses them both at once.

marcelgrilo
Inserter
Inserter
Posts: 21
Joined: Tue Jun 21, 2016 9:30 pm
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by marcelgrilo »

it would be nice if we could connecct the loaders with wires and have the same behaviour as the filter inserters

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1982
Joined: Fri Nov 06, 2015 7:41 pm

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by Deadlock989 »

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
It would. But there's no support in the game engine for it and loaders are not part of the vanilla game so it's never going to happen.

Use the Miniloaders mod if you want high throughput boxes that can connect to the circuit network.

BlindPumkin
Manual Inserter
Manual Inserter
Posts: 4
Joined: Mon Jun 27, 2016 10:48 pm
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by BlindPumkin »

Love the idea. Not sure how to get it working.

Adding the loader to the belt causes belt to stop.

Any guidance anyone?

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

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by shanemadden »

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?
Can you post a screenshot of your configuration? Note that the arrow on the top of the loader indicates which direction it's loading items; you should be able to see the little bit of belt poking out of the loader which shows which direction it's loading as well. Press the key you have bound to rotate an entity, R by default, to change which direction it loads (in the same way as underground belts) - the loader snapping settings in mod options should help them place a little more naturally once you get used to it.
Deadlock989 wrote:
Mon Sep 09, 2019 3:46 pm
mrvn wrote:
Mon Sep 09, 2019 3:40 pm
To 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.
Yup, this - while it's convenient for mod developers to be able to have the mod render the stacked icons automatically, it's bad for graphical rendering performance at runtime and generally shouldn't be used in 'released' mods; the mod currently warns of this in the log file, but that's seldom looked at.

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.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1982
Joined: Fri Nov 06, 2015 7:41 pm

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by Deadlock989 »

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

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

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by mrvn »

Deadlock989 wrote:
Tue Oct 08, 2019 9:33 am
shanemadden wrote:
Mon Oct 07, 2019 5:01 pm
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, 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.
This is something the game should simply allow to do or even do automatically. The game can just take the stack of icons, render it once and save it as a single icon in it's cache. Factorio is about automation. Having to manually run some python or imagemagic script every time a mod changes it's icons is not automation.

Scripts generated icons also break the look&feel with mods replacing icons in other mods. Suddenly the stacked icon looks nothing like the unstacked icon. Now you need another compat mod to replace the stacked icons to make it look right again.

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

Please add recipe to unstack single stacks per hand

Post by 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.

DraLUSAD
Inserter
Inserter
Posts: 31
Joined: Mon Jul 07, 2014 12:00 am
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by DraLUSAD »

Image

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
Smart Inserter
Smart Inserter
Posts: 4284
Joined: Mon Sep 05, 2016 9:10 am
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by mrvn »

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

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)
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
Manual Inserter
Manual Inserter
Posts: 1
Joined: Wed Oct 30, 2019 9:58 pm
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by Magnetix »

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
Fast Inserter
Fast Inserter
Posts: 127
Joined: Thu Feb 08, 2018 8:25 am
Contact:

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by shanemadden »

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.
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.
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.
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
Can you clarify what you mean by not working - maybe the lack of beltbox compression recipes at this level?

The compression for items added by Bob's items is provided by third-party integration mods - https://mods.factorio.com/mod/deadlock- ... ating-bobs would be the place to add additional items for stacking :)

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

Re: [MOD 0.17] Deadlock's Stacking Beltboxes & Compact Loaders

Post by mrvn »

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.
Lets boil this down to the very minimum:

1) Modlist: deadlock-beltboxes-loaders_2.2.2.zip, Bluebuild_1.2.0.zip

Both inventory and belt snapping set to true.

Note: Bluebuild calls ghost.revive() and then triggers on_built_entity. There is no rotation going on in the mod.

2) Start scenario/sandbox

Bluebuild needs a character to work so:

/c game.player.create_character()

3) Build this by hand:
Build by hand
Build by hand
beltbox1.png (39.67 KiB) Viewed 761 times
4) cut & paste the loader

- press ctrl-x to activate cut mode
- select just the loader
- place ghost of loader right back
Ghost build loader
Ghost build loader
beltbox2.png (22.12 KiB) Viewed 761 times
I've added some log() lines to both mods to show what's going on. Mostly just turned the comments in the source into log().

Now here is what happens when you place the loader manually:

Code: Select all

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
And what happens when you place the ghost:

Code: Select all

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
Note: Bluebuild sets event.revive and not event.revived like some other mods so the "I better do nothing" test fails. Bluebuild (and every other mod) probabyl shouldn't call on_built_entity but script_raised_revive now that that exists. Luckily it doesn't so I can demonstrate the bug in Deadlocks loaders and beltboxes with it.

Now to explain why this is going wrong: The loader entity has both a direction (N,S,W,E) and a loader_type (input/output). A manually placed loader is always in output mode (so far, hopefully that may change in the future) as can be seen in the log:

Code: Select all

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
The loader is facing the wooden-chest and the belt is going into the loader. So the control.lua correctly switches it to input mode.

Next when the ghost is placed this looks differently:

Code: Select all

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
Both the direction and the loader type are reversed. Because, well, it seems that for "input" ty0pe loaders the direction of the entity is reversed in the game.

The control.lua then sees that the loader is facing away from the wooden-chest (which is wrong as it's an input type facing the chest) and turns it around. It also switches the mode to what it things is "input" mode. But the entity already is in "input" mode so gets switched to "output" mode. In the end the loaders is both facing the wrong way and going the wrong direction.

I have no idea why the direction of loaders is reversed when they have "input" type but that's how it is. So the control.lua should not ignore the loader_type of the entity. Once that is taken in consideration the snapping code can do the right thing.


In conclusion:

Any mod that revives loader ghosts and calls on_built_entity without even.revived=true will trigger this bug with "input" type loaders. Event.revived is a custom flag invented by some other mod and not part of the API. Not every mod adds that unofficial flag and as seen
in bluebuild there seems to be a competing event.revive=true flag. I believe both of them are obsolete since the official API has:

script_raised_built A static event mods can use to tell other mods they built something with a script.
script_raised_destroy A static event mods can use to tell other mods they destroyed something with a script.
script_raised_revive A static event mods can use to tell other mods they revived something with a script.

The bug should still be fixed because in the future it might be possible to place "input" type loaders directly and enough mods do call on_built_entity to matter.

Post Reply

Return to “Mods”

Who is online

Users browsing this forum: No registered users