[MOD] Deadlock's Stacking Beltboxes & Compact Loaders

[Arch-kain]

This case (I guess)

that it only returns to the correct direction if you go yellow > red > yellow?

In fact, there : Image 1 >upgrade> Image 2 >downgrade> Image 1
(Sorry, I'm not really good in english, it seemed easier to say that like that )

[Deadlock989]

This case (I guess)

that it only returns to the correct direction if you go yellow > red > yellow?

In fact, there : Image 1 >upgrade> Image 2 >downgrade> Image 1
(Sorry, I'm not really good in english, it seemed easier to say that like that )

Your English is fine, better than fine.

Will look into this later. Right now I'm in post-honeymoon glow and it's 34 degrees ... Gut instinct says it's one of three things, two of which I should be able to sort out.

[Deadlock989]

Advanced notice

Just a reminder about plans for the future.

I'm not making any significant changes to the 0.16 versions of these mods. When Factorio 0.17/1.0 comes (Christmas?), it will either have some kind of belt stacking or not - probably not but you never know. If it does, mission accomplished. If it doesn't, I'll be making some changes.

DSB and DCL will become one mod. There will be an option to turn loaders off if you prefer another loader mod. It will probably have a new mod portal entry to avoid problems for people that might want to stay on 0.16.

There will no longer be any explicit hard-coded support for specific mods, i.e. Bob's, Xander etc. But the not-really-an-API support will be expanded and will cover both beltboxes and loaders. It means that specifying additional tiers of belt or changing existing tiers will become the responsibility of those other mods, or third party add-ons - DCL already has this though I'm not aware of anyone that's using it yet.

My aim is that existing 0.16 saves will be migrated, and also that any existing third party mods will not have to change any code, but they will have to add a bit of code to enable tier 4, 5 etc. belts if the supported mod has them (i.e. Bob's, but not Py's, etc.) But no promises. The good news is that you will only have to do it once for both beltboxes and loaders, so we're talking about maybe adding one additional function call per mod at most.

[Deadlock989]

This case (I guess)

that it only returns to the correct direction if you go yellow > red > yellow?

In fact, there : Image 1 >upgrade> Image 2 >downgrade> Image 1
(Sorry, I'm not really good in english, it seemed easier to say that like that )

Have investigated this briefly and I think it's the same problem that cropped up with Bluebuild and Nanobots. In certain circumstances, Upgrade Planner fires a player build event when it replaces one entity with another. This means that in the case of Compact Loaders, the game is led to believe that a player is manually putting the upgraded loader down themselves, so it naturally runs the snapping code. But really, this is more like laying a blueprint i.e. the loader already has a predetermined input/output mode, so (IMHO) it should be a robot build event or no event, though I can grudgingly see the arguments for having it as a player build event as well, it's not clear cut. However in testing, this only seems to happen around half the time - if you upgrade a whole bank of loaders not all of them get switched wrongly - and I can't work out why at first glance.

As a workaround, if you use shift-select with the upgrade planner, it will send robots to do the upgrading, which doesn't suffer from this interaction. However this will only work if you have bots available (i.e. in range of a ground-based logistics network with construction bots and loaders available, or a portable roboport).

I don't think I can work around this but I will have another look later. If not, I'll have to ask Klonan if he will use the "revived = true" flag that Nanobots and Bluebuild have started using.

[Deadlock989]

Regarding the above, in the meantime, you can alter Upgrade Planner yourself to fix the problem, by changing line 809 of control.lua from:

Code: Select all

script.raise_event(defines.events.on_built_entity,{player_index = player.index, created_entity = new_item, stack = player.cursor_stack})

to:

Code: Select all

script.raise_event(defines.events.on_built_entity,{player_index = player.index, created_entity = new_item, stack = player.cursor_stack, revived = true})

[anishin5]

@Deadlock989
Firstly, thank you much for your awesome mods.
I've suggestion for DSB. Probably, it's mentioned already (but I can't find it).
My idea is to add 'adaptive recipes' to DSB (as it is done in DCL). With mods which overhaul everything (Bob's especially) original recipes of stacking beltboxes is too cheap.
So mimicry ones from other components (like underground belts) will help to keep balance in game. (BTW, I'm exited about DCL recipes with Bob's Logistics).

That's all. Thank you for your work!

[andre2]

Is there any chance that beltboxes and loaders can work with the mod upgrade planner?
That would be like ultra useful.

For example I clonk down my blueprints for smelting with crushed ore from the Pyanodon mod. The blueprints have the basic yellow stuff.
On upgradnig to red belt, the loaders and boxes have to be changed manually.

[Deadlock989]

@Deadlock989
Firstly, thank you much for your awesome mods.
I've suggestion for DSB. Probably, it's mentioned already (but I can't find it).
My idea is to add 'adaptive recipes' to DSB (as it is done in DCL). With mods which overhaul everything (Bob's especially) original recipes of stacking beltboxes is too cheap.
So mimicry ones from other components (like underground belts) will help to keep balance in game. (BTW, I'm exited about DCL recipes with Bob's Logistics).

You're welcome.

It's a good idea and makes sense. But I'm moving away from explicitly supporting any of these big overhaul mods, it's too much effort to keep up with them, especially the ones I don't play myself. In future versions (0.17 onwards) there won't be any direct support for any particular mod, just a better sort-of-API to make it as easy as possible for them (or third party "helper" mods) to extend DSB.

Is there any chance that beltboxes and loaders can work with the mod upgrade planner?
That would be like ultra useful.

For example I clonk down my blueprints for smelting with crushed ore from the Pyanodon mod. The blueprints have the basic yellow stuff.
On upgradnig to red belt, the loaders and boxes have to be changed manually.

Apart from the snapping issue with loaders reported a few posts above (and the fix given), I don't have any other issues with Upgrade Planner. Upgrading and downgrading beltboxes seems to work fine for me, both when band-selecting entities in the world and when upgrading a blueprint item. If you're still having difficulties then you should report it to the Upgrade Planner dev - there's nothing unusual about the beltbox entities.

[mrvn]

Is there any chance that beltboxes and loaders can work with the mod upgrade planner?
That would be like ultra useful.

For example I clonk down my blueprints for smelting with crushed ore from the Pyanodon mod. The blueprints have the basic yellow stuff.
On upgradnig to red belt, the loaders and boxes have to be changed manually.

Turn of both snapping options in the per player mod settings. They are totally buggy. After that updating and blueprinting works.

[Deadlock989]

Turn of both snapping options in the per player mod settings. They are totally buggy. After that updating and blueprinting works.

They are not "totally buggy", they work exactly as intended. Inter-mod conflicts are to be expected. There are no issues between Upgrade Planner and DSB at all, and I've given a fix for Upgrade Planner's interaction with DCL above as well as reporting it to Upgrade Planner's dev.

Please don't trash my mods in public without a good reason.

[varaco]

I read there may be problems if you change the stack size in the code, is that still the case? What about 10x stacking?

[Deadlock989]

I read there may be problems if you change the stack size in the code, is that still the case? What about 10x stacking?

I read it now, however I see there could be problems with changing the value. Has anyone tried to increase it?

Like I said before - the only tested alternative value was 4. Upward increases weren't tested, this isn't really an official feature. My gut instinct is that it should work OK - meaning that the boxes should adjust their speeds automatically etc. But it will become unusable pretty quickly if you increase it too much - even 10 would probably start creating jams and all sorts, and vanilla loaders will start doing odd things with the lanes they output on etc. The other issue is that the stacking size needs to be a factor of 50, 100 and 200, which doesn't leave you many options. Any non-factor, e.g. 7, will result in wasted inventory space across the whole game.

[Grize]

Hi me again,
You should be overthing it again... that it is impossible to chance the direction of a placed loader snapping would be true... but i have something else in mind now.
There is something else what i am missing when i play. And this little thing can maybe do more than this.
When i place a loader near an assemblermachine then i must use an other loader or an inserter to put the things to an Box or another machine so taht the output go to an input loader. That needs 2x1 tiles of place. So its my wish that you can eventualy add an additional loader to your mod.
But now comes some that you can do to with it. When you construct this loader as a pice of 1x1 tiles as the same of the other loaders or if you have problems with it as a pice of 1x2 tiles as the same vanilla loader, then its would be for my opinion a simple to think of it as an construction that has 2 sides with the loader logic: OUt and IN. In case of change the direction the game will, when i see it by other loaders, change the sprite and the loader logic from OUT to an Belt our from a Belt to IN. But with the new loader it may be that you can do more: OUT - IN ; IN - OUT and Belt to IN ; Belt from OUT ; IN from Belt and OUT to Belt. The additional options could be an ON or OFF state in the loaderlogic for the side where the Belt would be or not. I down't know if you can understand this but it will be a great think if it will work correctly. We could use it as a single loader as bevor, as a loader to do out- an input of thinks in the same direction and time and it will solve the problems with incorrect placed Loaders.

[Deadlock989]

Hi me again,
You should be overthing it again... that it is impossible to chance the direction of a placed loader snapping would be true... but i have something else in mind now.
There is something else what i am missing when i play. And this little thing can maybe do more than this.
When i place a loader near an assemblermachine then i must use an other loader or an inserter to put the things to an Box or another machine so taht the output go to an input loader. That needs 2x1 tiles of place. So its my wish that you can eventualy add an additional loader to your mod.
But now comes some that you can do to with it. When you construct this loader as a pice of 1x1 tiles as the same of the other loaders or if you have problems with it as a pice of 1x2 tiles as the same vanilla loader, then its would be for my opinion a simple to think of it as an construction that has 2 sides with the loader logic: OUt and IN. In case of change the direction the game will, when i see it by other loaders, change the sprite and the loader logic from OUT to an Belt our from a Belt to IN. But with the new loader it may be that you can do more: OUT - IN ; IN - OUT and Belt to IN ; Belt from OUT ; IN from Belt and OUT to Belt. The additional options could be an ON or OFF state in the loaderlogic for the side where the Belt would be or not. I down't know if you can understand this but it will be a great think if it will work correctly. We could use it as a single loader as bevor, as a loader to do out- an input of thinks in the same direction and time and it will solve the problems with incorrect placed Loaders.

This is a little hard to follow but I think you're asking for a loader which can do inventory-to-inventory as well as inventory-to-belt. I can't do this unfortunately. DCL loaders are a simple modification of the vanilla loaders, and vanilla loaders are hardcoded to work from inventory-to-belt or belt-to-inventory. There's no way to change that (without killing UPS).

I recommend that you try the mod Miniloaders, which uses trickery (invisible inserters) to simulate loading, and I believe they work well from inventory-to-inventory.

Or just use stack inserters.

[mrvn]

A inventory-inventory loader that's just 2 loaders could be useful though. Could be easier to place since both sides will always be towards an inventory and rotating it would reverse both loaders.

[Tyarns]

Hey Deadlock, I want to add some support for your mod "Compact Loaders." You made it really easy to create new loaders based on your mod, which I appreciate! My only problem is that the color scheme doesn't match my belts. I made a mod which you may not be a fan of haha. https://mods.factorio.com/mod/UltimateBelts What would be the easiest way for me to get the loaders to appear black? Is this something you could help me out with? I could probably figure something out using GIMP, but photoshop isn't my forte and would take me a long time. I have some people that would really appreciate having the faster loaders

[Deadlock989]

Hey Deadlock, I want to add some support for your mod "Compact Loaders." You made it really easy to create new loaders based on your mod, which I appreciate! My only problem is that the color scheme doesn't match my belts. I made a mod which you may not be a fan of haha. https://mods.factorio.com/mod/UltimateBelts What would be the easiest way for me to get the loaders to appear black? Is this something you could help me out with? I could probably figure something out using GIMP, but photoshop isn't my forte and would take me a long time. I have some people that would really appreciate having the faster loaders

The DCL entity graphics are in two layers - the "base" (hr-loader-base.png), which is mid-grey with a faint hint of blue, and the stripes (hr-loader-mask.png) on top. The stripes are white by default and are then tinted depending on the tier colour. The base is never tinted, it's always the same.

It would be possible to get the game to tint the base layer as well so that it appears black, but it wouldn't look especially good (IMO). However it could be fairly easily added to the exposed functions in future, if there was a demand for it. Alternatively I could provide hooks for overriding the base graphic used for a specific loader tier, and your mod would then supply a darker base .png. I wouldn't get around to this until 0.17 is in experimental though.

Alternatively you could make a darker version with GIMP or whatever and then manually override the graphics yourself. The original graphic was made in Blender, it would be easy to make a darker version (but IMO a literally black one would look poor) - but you could achieve pretty much the same effect by playing with contrast in your graphics editor of choice.

Edited to add, you'd also need to override the icons, which are auto-generated in the same way, with a base and a tinted stripe on top.

[Tyarns]

Thanks for the extra info!

However it could be fairly easily added to the exposed functions in future, if there was a demand for it. Alternatively I could provide hooks for overriding the base graphic used for a specific loader tier, and your mod would then supply a darker base .png. I wouldn't get around to this until 0.17 is in experimental though.

This would be my preferred way to do it, I like that you've separated the graphics. That makes it fairly easy to make matching graphics for the base. Tinting the base may work just as easily though. I'm not sure what would be easier for you to implement. I'll have to play around with it a little bit to see if I can come up with something I like. I think I can make it look good, but maybe not. Thanks for your helpful reply!

[Deadlock989]

This would be my preferred way to do it, I like that you've separated the graphics. That makes it fairly easy to make matching graphics for the base. Tinting the base may work just as easily though. I'm not sure what would be easier for you to implement. I'll have to play around with it a little bit to see if I can come up with something I like. I think I can make it look good, but maybe not. Thanks for your helpful reply!

Let me know how you get on, and if it works out then I'll look at adding optional overrides for both base and overlay graphics, and an optional base tint as well. This will be part of the 0.17/1.0 overhaul where DCL and DSB get merged and you just specify a "tier of gear" all at once.

[Thales7]

https://mods.factorio.com/mod/underground-pipe-pack
This mod create a underground pipe that connect 2 undergrounds pipes without on-ground part (underground junction).
I suggest (Whit permission and help of this mod creator) create a same system to underground belt.