Some time ago, I put together a mod that can be used to route items across a complex network of belts & inserters (general logistics for bot haters). It works off of circuit-network signals (inputs are signals repeesenting network topology, supplied items, requested items, and processing triggers, and outputs are signals representing how much ow which type of item needs to be transferred across each link). For some reason, this makes the mod a bit difficult and cumbersome to use. (https://mods.factorio.com/mod/EketechRouting)
So, with a fair amount of additional considerations, I have worked out a way to build a belt-based general logistics system which should be a lot more accessible.
The idea now is to provide buildable components for modular logistics hubs, consisting of:
floor - used to define a logistic hub, both visually and to inform the mod that all components built on top of the floor belong to the hub.
provider/receiver - a chest-type entity used to insert items into a hub or to receive items from other hubs
storage - extra storage space to divert items without a destination to (and to draw items from when new requests are made)
requester - destination to route items to which is configured just like a requester chest (doesn't have to be attached directly to a hub)
Hub Controller - center of the hub, used to trigger internal item transfers (hub storage or input -> hub output). Controllers might also have varying properties that the mod uses to determine maximum size, logistic capacity, and efficiency.
Item transfer would be a simple [but costly and restricted] transfer of objects from Storage or Provider entities to Link or Requester entities based on current routing data (which inserters can then grab from and transfer items to move items toward their destinations). Item transfer would be triggered by inserting or pumping a consumable resource into the hub controller.
The new mod would provide a few selectable complete routing modes which offer various benefits and drawbacks (the behavior which my earlier routing mod defers to combinator logic) Modes in mind would be:
move X items per second (resilient against theft and flow-based)
move X amount of items with minimal over-supply or bufferring (vulnerable to theft and quantity-based)
move X items and don't keep track of in-flight items (resilient against theft and quantity-based, but can buffer a lot)
The plan also calls for having the routing system automatically configure itself - rather than manually defining links, it would derive network topology by scanning belts, inserters, and stops with scheduled trains to determine what each logistics hub is linked to.
Thinking about improving my Routing / Logistics mod
Re: Thinking about improving my Routing / Logistics mod
Maybe post a video on how the mod works and how to use it? And then show how the new mod would differ. I don't even know what the mod does so there's no way I can understand how it should be changed or how to use it. Every description is almost completely non-informative. To help you understand why I can't comprehend your description, some examples:
I have recently done some combinator circuits for 'requesting' from belts and to send trains. But I don't know how this mod would simplify or empower me to do it even better. As it is now it would just make it harder. Combinators are Turing complete and I'm smart, so why should I use your mod? I do want some way to route items before I get the requester logistics chests.
So it's not bots. But you don't really say what it is instead. How does the mod actually control where items go? Does it set filters for inserters? How does it know which inserters will bring the items to a certain chest? Does it follow the belt path to see if it ends at the correct chest? How does it deal with splitters?
It's a controller, but what does it control? Why is it needed? Aren't zones already defining what's inside the 'network' and the chests where things should go and come from?
Seems to answer my question above a little bit but I wouldn't say I'm understanding it anyways. How is it 'costly and restricted'? Is it because it uses belts and those are restricted in their capacity? Or does the mod add additional limitations on how much it can route, a limit below belt throughput? What are the costs? What does 'pumping items into the hub controller' mean? Is it some kind of storage chests? But you already had storage chests that were named so, why can't from trigger when something ends up in those?Eketek wrote: ↑Wed Apr 24, 2019 11:13 pmItem transfer would be a simple [but costly and restricted] transfer of objects from Storage or Provider entities to Link or Requester entities based on current routing data (which inserters can then grab from and transfer items to move items toward their destinations). Item transfer would be triggered by inserting or pumping a consumable resource into the hub controller.
Are you talking about multiplayer PvP? Or what is theft? And how would a system be vulnerable or not against theft? Does the system permanently fail if items are manually taken out of it and requests stop being fulfilled?
Seems you are planning to scan where belts go, but not necessarily? And suddenly you are talking about trains also but don't mention at all how those would be included in zones or how trains would be controlled. And you never mentioned how to manually define a link (or what a link is) but now you are saying that future development means that 'links' would be defined automatically.Eketek wrote: ↑Wed Apr 24, 2019 11:13 pmThe plan also calls for having the routing system automatically configure itself - rather than manually defining links, it would derive network topology by scanning belts, inserters, and stops with scheduled trains to determine what each logistics hub is linked to.
I have recently done some combinator circuits for 'requesting' from belts and to send trains. But I don't know how this mod would simplify or empower me to do it even better. As it is now it would just make it harder. Combinators are Turing complete and I'm smart, so why should I use your mod? I do want some way to route items before I get the requester logistics chests.
Re: Thinking about improving my Routing / Logistics mod
Over the past couple days, I went from thinking about it to starting development (because I want the new mod more than I want the ideas to merely be floated).
The mod (both the previous one and the planned one) is pretty abstract (and a lot of it is in the 'coherent only in my head' phase), so I'll attempt a few clarifications. Loosely speaking, the routing mod (both previous and planned versions) is an attempt to use belts and trains to do what bots do (insert items anywhere, request items anywhere, and let the logistic system move things where they need to go).
The original mod was completely combinator-based. It reads circuit network signals for a network configuration and for logistic requests & supply, and when appropriate triggered, it runs a pathfinding/routing process and outputs a signal at each network link indicating how many items to transfer across the link. A Player-designed combinator setup at each link then captures and holds the routing system's output signals, and uses them to for manipulating items (generally setting filters and tracking amounts transferred).
The output would then have to be captured by combinators and used to control a corresponding logistics system (generally filter inserters).
It worked well and it was even pretty satisfying to see messy mixes of items moving between hubs (both with belt and train transport), but it was incredibly cumbersome, was somewhat reliant on oversized chests (1x1 vanilla chests needed more complex logic), and it required a system-wide reset any time I made an error or if I mistakenly grabbed things off belts (the "theft" problem is Player unexpectedly stealing items from his own logistic system, causing the logistic system to lose track of in-flight items).
If you want a more practical demonstration of what the original mod does, I also put up a few blueprints the mod's thread, along with instructions for how to use those blueprints. (viewtopic.php?f=97&t=57557). The blueprints use a 6x6 warehouse from Pyanadon's mods, but that should be fairly simple to adapt.
The mod I am planning now is intended as a more accessible and reasonable approach. I want to do away with the abstractions (heavy reliance upon combinator logic) in favor of machines which operate directly on items and auto-config by scanning factory components (building on what is probably a lot more familiar).
"Hub Controller" is an arbitrary designation to an assembler-like entity which items are inserted into or fluids are pumped into or used to take power from the power grid for the purpose of triggering or enabling the logistic hub to shift items around. It is also a logical thing to attach a GUI to (for configuration) or to attach circuit wires to for a combinator-based interaction.
The tile-based layout (specifically requiring a special tiles to define the space a logistic hub occupies) is intended for visual configuration - a clear way to indicate that components belonging to a particular logistic hub (since each logistic hub needs to be a separate system). It also helps the mod re-purpose things like chests, and allows for the possibility that hubs may be positioned nearby each other.
I want it to have artificial costs and limitations because the plan calls for teleporting items between chests (intended to eliminate much of the need to mess with combinators and inserter filters) - Costs and restrictions are for preventing the routing mod from turning into an item teleportation mod.
By scanning the factory to determine network topology, it means I want to look for patterns like "Hub Outbound Link > Inserter > Belt > Chest > Inserter > Track > Nearby Train stop > Train Scheduled at that Stop > Other Stop on Train Schedule > Inserter > Belt > Inserter > Other Hub Inbound Link" -- and have it interpreted as a path from one hub to another hub. Also: deriving network topology by scanning the base is going to have to be an exercise in trusting Player to build something that works (AKA: letting you shoot yourself in the foot). I plan to have it scan through splitters and treat them as valid paths (along with any forked paths), but have no plans to attempt sanity checking.
Also, the routing mod idea is mostly conceived as a crazy alternative to bots. Bots will outperform in a lot of cases, but the routing system should do better when long distance and/or large requests are involved (supplying outposts, moving intermediate & waste products between distant factories, and direct routing of ore from mines to smelters).
The mod (both the previous one and the planned one) is pretty abstract (and a lot of it is in the 'coherent only in my head' phase), so I'll attempt a few clarifications. Loosely speaking, the routing mod (both previous and planned versions) is an attempt to use belts and trains to do what bots do (insert items anywhere, request items anywhere, and let the logistic system move things where they need to go).
The original mod was completely combinator-based. It reads circuit network signals for a network configuration and for logistic requests & supply, and when appropriate triggered, it runs a pathfinding/routing process and outputs a signal at each network link indicating how many items to transfer across the link. A Player-designed combinator setup at each link then captures and holds the routing system's output signals, and uses them to for manipulating items (generally setting filters and tracking amounts transferred).
The output would then have to be captured by combinators and used to control a corresponding logistics system (generally filter inserters).
It worked well and it was even pretty satisfying to see messy mixes of items moving between hubs (both with belt and train transport), but it was incredibly cumbersome, was somewhat reliant on oversized chests (1x1 vanilla chests needed more complex logic), and it required a system-wide reset any time I made an error or if I mistakenly grabbed things off belts (the "theft" problem is Player unexpectedly stealing items from his own logistic system, causing the logistic system to lose track of in-flight items).
If you want a more practical demonstration of what the original mod does, I also put up a few blueprints the mod's thread, along with instructions for how to use those blueprints. (viewtopic.php?f=97&t=57557). The blueprints use a 6x6 warehouse from Pyanadon's mods, but that should be fairly simple to adapt.
The mod I am planning now is intended as a more accessible and reasonable approach. I want to do away with the abstractions (heavy reliance upon combinator logic) in favor of machines which operate directly on items and auto-config by scanning factory components (building on what is probably a lot more familiar).
"Hub Controller" is an arbitrary designation to an assembler-like entity which items are inserted into or fluids are pumped into or used to take power from the power grid for the purpose of triggering or enabling the logistic hub to shift items around. It is also a logical thing to attach a GUI to (for configuration) or to attach circuit wires to for a combinator-based interaction.
The tile-based layout (specifically requiring a special tiles to define the space a logistic hub occupies) is intended for visual configuration - a clear way to indicate that components belonging to a particular logistic hub (since each logistic hub needs to be a separate system). It also helps the mod re-purpose things like chests, and allows for the possibility that hubs may be positioned nearby each other.
I want it to have artificial costs and limitations because the plan calls for teleporting items between chests (intended to eliminate much of the need to mess with combinators and inserter filters) - Costs and restrictions are for preventing the routing mod from turning into an item teleportation mod.
By scanning the factory to determine network topology, it means I want to look for patterns like "Hub Outbound Link > Inserter > Belt > Chest > Inserter > Track > Nearby Train stop > Train Scheduled at that Stop > Other Stop on Train Schedule > Inserter > Belt > Inserter > Other Hub Inbound Link" -- and have it interpreted as a path from one hub to another hub. Also: deriving network topology by scanning the base is going to have to be an exercise in trusting Player to build something that works (AKA: letting you shoot yourself in the foot). I plan to have it scan through splitters and treat them as valid paths (along with any forked paths), but have no plans to attempt sanity checking.
Also, the routing mod idea is mostly conceived as a crazy alternative to bots. Bots will outperform in a lot of cases, but the routing system should do better when long distance and/or large requests are involved (supplying outposts, moving intermediate & waste products between distant factories, and direct routing of ore from mines to smelters).
Re: Thinking about improving my Routing / Logistics mod
I'm starting to understand it a bit now.
Why does the plan call for teleportation though? Can't everything be done with filter manipulation (inserters and splitters) and maybe some train control?Eketek wrote: ↑Tue Apr 30, 2019 12:10 amI want it to have artificial costs and limitations because the plan calls for teleporting items between chests (intended to eliminate much of the need to mess with combinators and inserter filters) - Costs and restrictions are for preventing the routing mod from turning into an item teleportation mod.
This part sounds like it would be great as a library mod that other mods can remote call into to get topology graphs for. For doing similar things or exporting for visualisations or other wild ideasEketek wrote: ↑Tue Apr 30, 2019 12:10 amBy scanning the factory to determine network topology, it means I want to look for patterns like "Hub Outbound Link > Inserter > Belt > Chest > Inserter > Track > Nearby Train stop > Train Scheduled at that Stop > Other Stop on Train Schedule > Inserter > Belt > Inserter > Other Hub Inbound Link" -- and have it interpreted as a path from one hub to another hub. Also: deriving network topology by scanning the base is going to have to be an exercise in trusting Player to build something that works (AKA: letting you shoot yourself in the foot). I plan to have it scan through splitters and treat them as valid paths (along with any forked paths), but have no plans to attempt sanity checking.
Re: Thinking about improving my Routing / Logistics mod
Short-distance item teleportation is intended to make the routing system accessible (I would really prefer it be comparable in difficulty to a bot-based logistics setup) and cut down on the logistic hub footprint a bit.
Not having the teleportation is what drove a lot of the difficulty in the previous mod. If you would prefer to use combinators and filter inserters, then previous mod is for you (it is a filter manipulation system that won't even pretend to hold anyone's hand) -- just need to go to the mod thread and press Eketek for details, and perhaps have someone contribute better graphics and order me to post an update (possibly the mod could also use its own warehouse and a way to get a basic blueprint set directly from the mod instead of the forum)
Not having the teleportation is what drove a lot of the difficulty in the previous mod. If you would prefer to use combinators and filter inserters, then previous mod is for you (it is a filter manipulation system that won't even pretend to hold anyone's hand) -- just need to go to the mod thread and press Eketek for details, and perhaps have someone contribute better graphics and order me to post an update (possibly the mod could also use its own warehouse and a way to get a basic blueprint set directly from the mod instead of the forum)