[MOD] Deadlock's Stacking Beltboxes & Compact Loaders

[shanemadden]

After I gave it a little more thought, it might be nice to keep two separate options (belt snapping and inventory snapping, with both "ends" of inventory snapping collapsed into the same option so there aren't three?), which would allow for the flow of "build everything in order and it's all facing correctly":

gif

With inventory snapping enabled that last loader will be in input mode and need manually rotated, which might seem unintuitive to players touching loaders for the first time. But that's not terribly important to me, as this flow is less switching with the toolbar anyway, and will work just fine with inventory snapping active:

gif

In any case, here's an update to that diff to use a facing-away belt as a hint to stay in output mode. Thanks a lot for integrating this feature!

Code: Select all

@@ -34,6 +34,17 @@
     end
     return false
 end
+-- is any entity in the list that's belt-ish facing toward the loader
+function are_belt_facing(entities, direction)
+    for _,entity in pairs(entities) do
+        if (entity.type == "transport-belt" or
+            entity.type == "underground-belt" or
+            entity.type == "splitter") and
+            entity.direction == direction
+        then return true end
+    end
+    return false
+end

 -- if there's a loadable thing behind but not ahead, turn around
 -- if there's a loadable thing ahead but not behind, turn around and switch mode
@@ -44,12 +55,18 @@
     if event.revived then return end
     local snap2back = settings.get_player_settings(game.players[event.player_index])["deadlock-loaders-snap-to-back"].value
     local snap2front = settings.get_player_settings(game.players[event.player_index])["deadlock-loaders-snap-to-front"].value
+    -- needs a setting
+    local snap2belt = true
     -- no need to check anything if all configs are off
-    if not snap2back and not snap2front then return end
+    if not snap2back and not snap2front and not snap2belt then return end
     -- check neighbours and snap if necessary
     local belt_end = get_neighbour_entities(built, built.direction)
     local loading_end = get_neighbour_entities(built, opposite[built.direction])
-    if snap2back and not are_loadable(belt_end) and are_loadable(loading_end) then
+    if snap2belt and are_belt_facing(belt_end, opposite[built.direction]) then
+        built.rotate( {by_player = event.player_index} )
+    elseif snap2belt and are_belt_facing(belt_end, built.direction) then
+        -- there's a belt facing away from the belt-end, do nothing and skip any potential inventory snapping
+    elseif snap2back and not are_loadable(belt_end) and are_loadable(loading_end) then
         built.rotate( {by_player = event.player_index} )
     elseif snap2front and are_loadable(belt_end) and not are_loadable(loading_end) then
         built.direction = opposite[built.direction]

[blendi_93]

entity.map_color of loaders dont match color of belt, underground_belts and splitter.

for example red belts splitter and underground_belts displayed yellow on map.

mod-list:
base
deadlocks-compact-loaders

[Deadlock989]

entity.map_color of loaders dont match color of belt, underground_belts and splitter.

This is more-or-less intended. For reasons. It could be better but it's about 9000th on the list of things in my life which need sorting out.

[Deadlock989]

After I gave it a little more thought, it might be nice to keep two separate options (belt snapping and inventory snapping, with both "ends" of inventory snapping collapsed into the same option so there aren't three?), which would allow for the flow of "build everything in order and it's all facing correctly":

I've collapsed the previous snap-to-inventory stuff into one option and added a new one for considering "indicating" belts.

I made one more addition to your changes, which follows the snap-to-belt logic for adjacent belts in the case where the loader is placed backwards next to an inventory:

Code: Select all

-- if there's a belt behind, follow the direction of the belt
-- else if there's a belt ahead, stop
-- else if there's a loadable thing behind but not ahead, turn around
-- else if there's a loadable thing ahead but not behind, turn around and switch mode
script.on_event(defines.events.on_built_entity, function(event)
	local built = event.created_entity
	if not built or not built.valid or not string.find(built.name, "deadlock-loader", 1, true) then return end
	-- is this a fake player build event from Nanobots / Bluebuild?
	if event.revived then return end
    local snap2inv = settings.get_player_settings(game.players[event.player_index])["deadlock-loaders-snap-to-inventories"].value
    local snap2belt = settings.get_player_settings(game.players[event.player_index])["deadlock-loaders-snap-to-belts"].value
	-- no need to check anything if all configs are off
	if not snap2inv and not snap2belt then return end
	-- check neighbours and snap if necessary
    local belt_end = get_neighbour_entities(built, built.direction)
    local loading_end = get_neighbour_entities(built, opposite[built.direction])
    -- belt detection by shanemadden
    if snap2belt and are_belt_facing(belt_end, opposite[built.direction]) then
        built.rotate( {by_player = event.player_index} )
    elseif snap2belt and are_belt_facing(belt_end, built.direction) then
        return
    -- no belts detected, check for adjacent inventories
    elseif snap2inv and not are_loadable(belt_end) and are_loadable(loading_end) then
        built.rotate( {by_player = event.player_index} )
    elseif snap2inv and are_loadable(belt_end) and not are_loadable(loading_end) then
        built.direction = opposite[built.direction]
        if not snap2belt or not are_belt_facing(loading_end, built.direction) then
            built.rotate( {by_player = event.player_index} )
        end
    end
end)

Will publish this when the broken icons are fixed with 0.16.38's release.

[shanemadden]

Will publish this when the broken icons are fixed with 0.16.38's release.

Looks great - thanks again!

[mrvn]

After I gave it a little more thought, it might be nice to keep two separate options (belt snapping and inventory snapping, with both "ends" of inventory snapping collapsed into the same option so there aren't three?), which would allow for the flow of "build everything in order and it's all facing correctly":

gif

With inventory snapping enabled that last loader will be in input mode and need manually rotated, which might seem unintuitive to players touching loaders for the first time. But that's not terribly important to me, as this flow is less switching with the toolbar anyway, and will work just fine with inventory snapping active:

gif

In any case, here's an update to that diff to use a facing-away belt as a hint to stay in output mode. Thanks a lot for integrating this feature!

Last I checked the logic is that the items flow in the direction the belt is running. In your gif you rotate the loader by 180° and then place it with the belt flowing into the stacker. Simply skip the rotating and it should work right already with less key presses. Loaders could use a mini tutorial to explain the snapping. Once you know to look at the belt direction and not where the loader end is it becomes simple.

[Deadlock989]

---------------------------------------------------------------------------------------------------
Version: 1.5.4
Date: 25. 04. 2018
Changes:
- Snapping improved, takes cues from adjacent belts when setting input/output mode (code by shanemadden).
- Snapping settings changed. Former snap-to-inventory settings merged. New belt snapping has a new setting.
- Entity description informs newbies about input/output mode rotation.
- Note to translators: entity description and settings labels and descriptions have changed.
---------------------------------------------------------------------------------------------------

[shanemadden]

Last I checked the logic is that the items flow in the direction the belt is running. In your gif you rotate the loader by 180° and then place it with the belt flowing into the stacker. Simply skip the rotating and it should work right already with less key presses. Loaders could use a mini tutorial to explain the snapping. Once you know to look at the belt direction and not where the loader end is it becomes simple.

That gets the input side facing correctly without rotation (wouldn't have worked in my gif since I had inventory snapping disabled), but on the output side the loader will also snap to input mode with loader-end inventory snapping enabled - I'm guessing you're running with the belt-end snapping on and the loader-end snapping off? You may have just made the case for keeping three options.

[Shadowaves]

Thanks for the notes, I'm on it

[Anson]

Suggestion - corner loader - 90 degrees output relative to input

Already works that way except for the gfx.
Personally I would have expected for sideloading a loader to behave like an underground belt and only load one side of the belt.

1. no, it doesn't (output from sides to both lanes of the output)
2. no, it does (sideloading somehow/sometimes, but not deterministic like undergrounds)

a bit more detail ... just tested again :

1. you can have a loader with three inputs and one output, but the loader won't accept full throughput from all three sides and properly output to one side. also the input "from the back" has to be a container where it takes the items while the inputs from the sides have to be belts, and the output has to be a belt too. (to have a chest at the output of the loader, the other three sides have to be belts)

2. the loader accepts full input from its backside and outputs full throughput to the front, and this is the normal use of loaders. but when belts aim at the sides of the loader, it accepts "random" inputs and inserts them onto the output partially like i would expect some kind of "sideloading with priority" to work. to test this, build the following setup and rotate the marked belt. as a result, the iron plates are sideloaded onto the output belt's right lane in one of four seemingly random ways (thus rotate that tile 4 times, watch, rotate again 4 times, watch, repeat). sometimes both lanes of the iron belt are sideloaded onto the output belt with priority over the input from the chest, sometimes only the left incoming lane and sometimes only the right incoming lane is sideloaded, and sometimes even no iron plates are sideloaded at all (which would mean priority for items from the chest).

3. and finally rotating the blue ouput belt twice will cause the loader to snap (NOT having touched, rotated or newly built the loader!) so that it takes items from the output belt and from both side belts and inserts them into the chest. and rotating two more times will make the loader snap again to working like before in the screenshot.
as a side effect, i found that ANY method of interrupting the constant flow of items (either rotating the side belts, or rotating the output belt, maybe also disabling the chest, etc) causes different sideloading behavior. reason is probably a different timing and different offsets of the lanes after resuming work.

btw: as far as i remember, this complex strange behavior is very similar or almost exactly how Klonan's Belt Buffer behaves (a 2x1 item, like loader->chest->unloader, with new graphics).

in this screen, both copper lanes and one iron lane (all on yellow belts) are sideloaded to the blue output belt

SideloadingLoaders.PNG (224.84 KiB) Viewed 7315 times

I don't get it. ... What's the problem?

your setup shows how to connect two loaders to one chest/stacker, building a 90 degree angle at the chest/stacker.
my post was about connecting two or more belts/chests/stackers to one loader, with 90 degree angles at the loader.
intended goal was to be able to build a setup like yours with a width of only 2 instead of 3+, squeezing loader->stacker->unloader into 2x2 tiles instead of 1x3 tiles.

[Deadlock989]

btw: as far as i remember, this complex strange behavior is very similar or almost exactly how Klonan's Belt Buffer behaves (a 2x1 item, like loader->chest->unloader, with new graphics).

Because KBB places hidden shrunken loaders at either end of the container, so it is literally the same behaviour.

[mrvn]

Suggestion - corner loader - 90 degrees output relative to input

Already works that way except for the gfx.
Personally I would have expected for sideloading a loader to behave like an underground belt and only load one side of the belt.

1. no, it doesn't (output from sides to both lanes of the output)
2. no, it does (sideloading somehow/sometimes, but not deterministic like undergrounds)

a bit more detail ... just tested again :

1. you can have a loader with three inputs and one output, but the loader won't accept full throughput from all three sides and properly output to one side. also the input "from the back" has to be a container where it takes the items while the inputs from the sides have to be belts, and the output has to be a belt too. (to have a chest at the output of the loader, the other three sides have to be belts)

2. the loader accepts full input from its backside and outputs full throughput to the front, and this is the normal use of loaders. but when belts aim at the sides of the loader, it accepts "random" inputs and inserts them onto the output partially like i would expect some kind of "sideloading with priority" to work. to test this, build the following setup and rotate the marked belt. as a result, the iron plates are sideloaded onto the output belt's right lane in one of four seemingly random ways (thus rotate that tile 4 times, watch, rotate again 4 times, watch, repeat). sometimes both lanes of the iron belt are sideloaded onto the output belt with priority over the input from the chest, sometimes only the left incoming lane and sometimes only the right incoming lane is sideloaded, and sometimes even no iron plates are sideloaded at all (which would mean priority for items from the chest).

3. and finally rotating the blue ouput belt twice will cause the loader to snap (NOT having touched, rotated or newly built the loader!) so that it takes items from the output belt and from both side belts and inserts them into the chest. and rotating two more times will make the loader snap again to working like before in the screenshot.
as a side effect, i found that ANY method of interrupting the constant flow of items (either rotating the side belts, or rotating the output belt, maybe also disabling the chest, etc) causes different sideloading behavior. reason is probably a different timing and different offsets of the lanes after resuming work.

btw: as far as i remember, this complex strange behavior is very similar or almost exactly how Klonan's Belt Buffer behaves (a 2x1 item, like loader->chest->unloader, with new graphics).

SideloadingLoaders.PNG

I don't get it. ... What's the problem?

your setup shows how to connect two loaders to one chest/stacker, building a 90 degree angle at the chest/stacker.
my post was about connecting two or more belts/chests/stackers to one loader, with 90 degree angles at the loader.
intended goal was to be able to build a setup like yours with a width of only 2 instead of 3+, squeezing loader->stacker->unloader into 2x2 tiles instead of 1x3 tiles.

Your example is an unloader, not a loader (even though that's the same entity).

What I though was that you mend a loader going into a chest that you feed with one belt from the side. That already works.

In your example the unloader will take items from any of the 3 sources and output it to the belt. I would expect random timing differences to give random results just like you experienced.

[Deadlock989]

Deadlock's Stacking Beltboxes version: 1.5.4
Date: 04. 05. 2018
Changes:
- The map/minimap colour for beltboxes now defaults to the same as any other vanilla machine entity (dull blue).
- Maps in existing save games won't update until the chunk is re-charted (by radar, by building in the chunk, or with the command).
- Tiered map colours are now handled by the companion mod, Deadlock's Compact Loaders.

Deadlock's Compact Loaders version: 1.5.5
Date: 04. 05. 2018
Changes:
- The map/minimap colour for compact loaders now defaults to the same as vanilla loaders (dull blue).
- As an alternative, a new config setting has been provided, off by default. Belts, splitters, undergrounds, compact loaders and stacking beltboxes appear on maps with various shades of the respective belt tier's colour.
- Maps in existing save games won't update until the chunk is re-charted (by radar, by building in the chunk, or with the command).
- Note to translators: there is a new config option, nothing else has changed.

[Shadowaves]

Thanks for the notes, translation updated

[Deadlock989]

DSB version: 1.5.5 and DCL version 1.5.6
Date: 06. 05. 2018

Inter-mod support:
- Factorio base 0.16.36 (0.16 stable) is now the minimum requirement.
- For Bob's Logistics support, Bob's Logistics 0.16.22 is now the minimum requirement.

Reason for this: it was previously BL 0.16.17 but something changed/broke between then and the most recent version of BL, which has been stable for a month. For some reason people are trying to use the most recent version of DCL with older versions of BL and that's throwing errors to do with the tier 0 loaders, I can't retroactively change anything so have to force the versions.

[Shadowaves]

Any changes in the .cfg files ?

[Deadlock989]

Any changes in the .cfg files ?

Nope, not this time. I don't plan on any more changes until maybe 0.17.

[shanemadden]

The minimap color option is a great idea, thanks a lot for adding that!

After giving mrvn's use case/expected behavior some thought, I think I have one more improvement for belt-snapping mode, if you're up for another tweak. I think it makes it a little more consistent feeling - this way, both belt-snapping and inventory-snapping settings will cause the loader to react to entities on both the belt end and the loader end, and the "place everything without rotation" case is fixed for belt snapping.

The change only affects these two cases, where there's a belt on the loading end (and nothing relevant on the belt end):

If facing toward, flip orientation and go into input mode

If facing away, flip orientation but stay in output mode

I figure these belong as a "last resort" after the other checks:

Code: Select all

@@ -76,5 +76,11 @@
         if not snap2belt or not are_belt_facing(loading_end, built.direction) then
             built.rotate( {by_player = event.player_index} )
         end
+    -- no inventories, check for inventory-end belts
+    elseif snap2belt and are_belt_facing(loading_end, built.direction) then
+        built.direction = opposite[built.direction]
+        built.rotate( {by_player = event.player_index} )
+    elseif snap2belt and are_belt_facing(loading_end, opposite[built.direction]) then
+        built.direction = opposite[built.direction]
     end
 end)

Thanks again!

[mrvn]

Isn't that already what belt snapping is?

[Deadlock989]

Isn't that already what belt snapping is?

No, the existing belt snapping only switches mode to follow belt direction when the loader is placed the right way round. This is the other case where the loader is accidentally placed backwards and there's no inventory to snap to.

After giving mrvn's use case/expected behavior some thought, I think I have one more improvement for belt-snapping mode, if you're up for another tweak.

Seems logical. I've added it.

I really want to stop updating these mods, at least until we know what 0.17 is bringing to belts and loading (if anything). I've put this last tweak in but will hold off for a day or two in case there's anything else, then I'll do the definitive 0.16 upload.

There is a request on the mod portal to add a tier 0 beltbox, sorry, don't want to. The 0.17/1.0 version of stacking beltboxes (if there is any need for one) will allow other modders to easily create their own tiers of beltbox if they want to, the way it works for loaders at the moment.