Factorio Forums

I'm sorry, if this kind of suggestion has been made before. I have used the search, but due to my poor English, I may have been used the wrong keywords.

TL;DR

Nowadays, there are logistic systems like many types of automated guided vehicles (AGV).

What ?

I am thinking of an AGV like this ...


This would be an intermediate transport system for medium sized material flow bound to special lanes. Its like a small sized railway system ( AGV 1x1 tiles, curves 1x1 tiles!) with a inbuilt "pull logic".

Each AGV is dedicated to a single input station and one or more output stations.

An input station consists of a loader, a stack of empty crates and a parking area. 2x2 tiles in size. Additional AGV can be parked there, too (underground ?)

An output station consists of an unloader and a storage for empty crates. An output station can directed to several input stations. But an AGVs can only handle a single route.

During being idle the AGV waits loaded with a crate loaded with goods at its input station (and it is recharging its batteries).

If an dedicated output station signals getting lower than a set minimum threshold, the goods are transported to the output station in need.
On arrival the crate is left there and an empty crate is carried "home".

A crate can only hold a small amount of goods. E.g. 4 stacks.
At the input station you can define a ratio of multiple goods ( not bound to stacks but limited by the capacity of the crates). E.g. 60 gears, 30 iron plates and 120 copper cables.

The AGV can only drive on special paved ways. You can define such a lane as one direction only or both directions. In the case of both directions for a single lane you may need a few evasive bays, if several AGVs are using the same way (e.g. several AGVs are dedicated to the same loading station or the road network consists of crossings).

Unlike trains, the AGVs do not need any signals: If a two directional way is already in use in the opposite direction, the AGV waits in the closest bidirectional double lane or evasive bay. In the case of AGVs driving in the same direction, they can follow each other with a minimum distance.

Why ?

I think, we could use a little bit more variety of logistic systems : Belts, trains and robots do not fit for all purposes.

Belts are good for mass products on short or medium distances. But belts don't have any logic than the "push logic" unless you make use of a large array of signal circuits.

Trains are good for very long distances. But they are too big for distances between production lines.

Logistic robots are good for small amounts of goods on short distance. But unless you mass produce these robots, they can only handle small amounts of goods. They make the setup of the factory too easy, too (IMHO).

There is a gap between these three options to transport material. An AGV ( like I have described above) would fit well to close the gap :

You can handle bigger amounts of materials than robots. They use partly the pull logic of the robots. But you need to setup the threshold values and need to think of the roads for the AGVs.

For the production of not automatically used products without the need of mass production (e.g. new assembly machines, new trains), a different kind of logistic system would be very useful ... IMHO.

We have AAI for it https://mods.factorio.com/query/Aai?version=0.16
Also logistic carts https://mods.factorio.com/mod/logicarts

darkfrei wrote: ↑Tue Nov 27, 2018 11:29 am We have AAI for it.

Also logistic carts

Hmmm. I have read the description / wiki of both mods and I will give them a try.

But as far as I have understood the descriptions ...

Both mods lack an inbuilt pull logic.

I could set up a pull logic by hand using the circuit network. But I would have to rebuild the circuit for every output station. This would be like adding a couple of circuits for every logistic chest in a robot network. Not a very clever way to handle a simple problem.

In a logistic system with simplified AGVs I have in mind you would do the following ...

1. Place the input station(s)
2. Place the output station(s)
3. Lay out the path between these stations
4. Add one or more AGV to every input station
5. Add a couple of crates to every input station
6. Add a single crate to every output station
7. Input station : Fill out a form to define the goods for packing a crate. And determine the linked output station(s)
8. Output station : Fill out a form to define the threshold to signal a low storage

That's all.
No comparators.
No fragile signal cables.
No train signals.
And most important : No extra material on route to the output station than the requested amount ( see Kanban )

Tairon96 wrote: ↑Tue Nov 27, 2018 6:05 pm

1. Place the input station(s)
2. Place the output station(s)
3. Lay out the path between these stations
4. Add one or more AGV to every input station
5. Add a couple of crates to every input station
6. Add a single crate to every output station
7. Input station : Fill out a form to define the goods for packing a crate. And determine the linked output station(s)
8. Output station : Fill out a form to define the threshold to signal a low storage

That's all.

Passive provider chest, requester chest, logistic bots? The roboport area must be small and without touching of global logistic network. All this collision checking need too much performance, on each tick, 60 times / second.

darkfrei wrote: ↑Tue Nov 27, 2018 6:31 pm

Tairon96 wrote: ↑Tue Nov 27, 2018 6:05 pm

1. Place the input station(s)
2. Place the output station(s)
3. Lay out the path between these stations
4. Add one or more AGV to every input station
5. Add a couple of crates to every input station
6. Add a single crate to every output station
7. Input station : Fill out a form to define the goods for packing a crate. And determine the linked output station(s)
8. Output station : Fill out a form to define the threshold to signal a low storage

That's all.

Passive provider chest, requester chest, logistic bots? The roboport area must be small and without touching of global logistic network. All this collision checking need too much performance, on each tick, 60 times / second.

Huh ? Collision checking ? I have described the building process of a AGV network. During operation there is very little collision detection needed :

Only if a paved road is changed, an alternative route needs to be found.(like the railway)

If a player or alien is idling on the route (or someone risks a parking ticket for his tank) , there might be a "collision" (like the railway but without a crash since the AGV is stopping before the obstacle).

If there are multiple AGVs using the same road, there is only a check in the case of junctions or crossings. (like automatically placed chain signals at the entrance of junctions and normal signals everywhere else).

In the case of the logistic network provided by flying robots, there is no collision ... but "you" have to check, if a flying robot is in attack range of an alien. Since you need more robots to transport the same amount of goods, there needs to be more checks. So ... nothing is gained or lost.
___

As I have described in my opening post, I would like to have an AGV network integrated in my main factory complex. It doesn't make much sense to keep specialized production lines for rare products far away from the center of your factory, does it? So ... you can't separate the robot network in this case.

I am sorry, but I don't know how to explain my struggling with the robot network better than to say, "it feels a bit boring to be reduced to just check from time to time if there are enough robots in the hangars."

With AGV networks, you need to check, if there are enough AGVs, too. But you also have to check the threshold values, the extra number of crates, optimize the path, test if a single input station can provide enough material at peak times .... or the production is delayed because the AGVs are slower moving, they can't fly the bee line, their handling depends on crates etc.

If you extend the production line, you need to add additional paths like laying out new belt lines plus a way back. Perhaps struggling here and there with existing belt lines or railway tracks or machines or other obstacles.

In my opinion, Factorio's main part is to design a futuristic factory layout.
With AGVs you are working on the layout.
With flying robots ... you are only counting the robots.

Don't get me wrong : I like the idea of robots flying in my factory. But I think their purpose is delivering only very small amounts of goods.

Hello,

i also feel bots are somewhat cheating the game and take out some nice puzzels and thinkings…..

I have tested the Logicarts (LC) when it come out and it works just fine for as intended.

I build a small special production area for all LC thingys.

I find the overhead not very big, also because the LC are very good steerable without any combinatory logic.
The load / unload stations are easily blueprint able

I use the LC :

• Far away (small) uranium ore fields where I don’t want to place a special sulfuric-acid infrastructure (either train-station/pipe string), so I placed at the uranium-ore station a sulfuric-acid –barreling and have some LC driving from and too (barrels full/empty and the uranium-ore)
• Some test at a LC-no-stoppable-army
• Currently I have a LC-operation with very low volume items for the extended-space-mod, where some LC circling the various assembler stocking all and get the endproduct

I like the LC very much, because no need for long belt contraptions and no need for bots-networks
As for me the LC-mod fits very well between bots and belt/train infrastructure

One of the player here has gone into the very depth of using LC to the extremes

See also in the threat here :
viewtopic.php?f=190&t=61053&p=372036&hi ... rt#p372036

I support this suggestion with both hands!

The current implementation of transport bots disbalances the game and looks, dare I say it, absurd. No technology in the world allows for flying robots to deliver heavy loads inside real-world factories. On the other hand, many heavy-industry facilities utilize robo-caries like the ones described in the post.

@Tairon96 is right that the proposed system AGVs with roads would require very little CPU power, and possibly save some drawing power because there gonna be much fewer AGVs than flying bots.

voddan wrote: ↑Fri Nov 30, 2018 12:40 pm@Tairon96 is right that the proposed system AGVs with roads would require very little CPU power, and possibly save some drawing power because there gonna be much fewer AGVs than flying bots.

Every single stack need more CPU.
One robot with collision needs 1000 time more CPU than one robot without collision, also "flying" robots.

darkfrei wrote: ↑Fri Nov 30, 2018 1:16 pm [...]
Every single stack need more CPU.
One robot with collision needs 1000 time more CPU than one robot without collision, also "flying" robots.

I like your guessing numbers. Perhaps I should ask you about the lottery results for the next weekend?
___

Seriously, can you explain me the difference between checking "flying robot in attack range" and "ground bound robot in collision range" ?

No ? There is no real difference !

The collision range is only smaller than the attack range of the aliens. The collision range might be a square ( bounding box) around the ground bound robot instead of a circle around the alien. But the shape of the bounding box is almost irrelevant due to the small dimensions and being a square instead of a rectangle.
___

We have hundreds of aliens on a map. For every one there might be a chance, it is already close enough to attack something. If you have a few thousand flying robots, there are a few thousand more possible fast moving targets to attack. Due to the fast moving, the checks needs to have done quite often.

If you would have a few hundred ground bound robots more (or replacing a good portion of the flyers), moving at walking speed, the number of checks would only increase a bit ... and due to the slow speed, the checks would need to be done only now and then.
___

As a side effect, the reduced number of moving object (a single AGV could replace several flying robots), the number of moving sprites would be reduced, too.
___

If you have already problems with your fps rate, perhaps you should lower the number of your flying robots and support the idea of driving robots to replace your airborne armada ?

If you don't like the idea of AGVs, I can live with that. But please don't throw in some random numbers without any facts supporting them.

Tairon96 wrote: ↑Fri Nov 30, 2018 11:50 pm I like your guessing numbers. Perhaps I should ask you about the lottery results for the next weekend?

No, but I can say which lottery have better chance. If one of them has about 1000 times better chance then play with it and don't play with another.

Tairon96 wrote: ↑Fri Nov 30, 2018 11:50 pm We have hundreds of aliens on a map. For every one there might be a chance, it is already close enough to attack something. If you have a few thousand flying robots, there are a few thousand more possible fast moving targets to attack. Due to the fast moving, the checks needs to have done quite often.

You are right, aliens are need a lot of CPU usage. So one big biter needs less CPU than hundert of small biters, about 100 times!

I've tryed to make this mod in 2017: viewtopic.php?t=43293

Why are we discussing CPU usage BEFORE we discuss the details of AGVs and their impact on the game balance? Shouldn't we concentrate on the game aspects and let the developer team invent the optimizations that allow for it to run efficiently. I am sure that if AGVs are a core part of the game (not a mod), the developers will find a way to run them efficiently just like the did with trains.

The questions I would like to see a discussion on:
- How early in the game should AGVs be available?
- How AGVs will change the layout of factories?
- Will AGVs stimulate players to build concrete roads between factory sections?
- Will there be a need for "central buss" of items with AGVs?
- How will road intersections work? Could we use signals for that?
- Will AGVs need provider chests and inserters for pooling/putting items, or will they work with any building automatically
- How exactly the path-finding algorithm should work?
- Will path-finding break if all factory is covered in concrete?
- Should players be able to sit on a moving AGV (like they can stand on a moving belt)?
- and many others

voddan wrote: ↑Sat Dec 01, 2018 10:55 am Why are we discussing CPU usage BEFORE we discuss the details of AGVs and their impact on the game balance? Shouldn't we concentrate on the game aspects and let the developer team invent the optimizations that allow for it to run efficiently. I am sure that if AGVs are a core part of the game (not a mod), the developers will find a way to run them efficiently just like the did with trains.

The questions I would like to see a discussion on:
- How early in the game should AGVs be available?
- How AGVs will change the layout of factories?
- Will AGVs stimulate players to build concrete roads between factory sections?
- Will there be a need for "central buss" of items with AGVs?
- How will road intersections work? Could we use signals for that?
- Will AGVs need provider chests and inserters for pooling/putting items, or will they work with any building automatically
- How exactly the path-finding algorithm should work?
- Will path-finding break if all factory is covered in concrete?
- Should players be able to sit on a moving AGV (like they can stand on a moving belt)?
- and many others

From my point of view :

The AGVs could use the same routing / path finding algorithm of the train network. They should not be able to move freely over any concrete slab. In fact, they should only drive on special lanes. These lanes are concrete slabs (perhaps with inbuilt induction cables to guide the AGVs). But from the game mechanics, these slabs would behave like tracks.

AGVs should not be able to drive over belts. For crossings, you would need underground belts.

AGVs could need a special train signal for a safe crossing of railway tracks. Or they would be limited to be on one side of the railway. Dunno.

IMHO, the AGVs could be as early as the flying robots now ... and the flying logistic robots should be moved a little bit to the end of the research tree since they are some kind of solution fixers for a too chaotic factory complex (if the belt crossings are getting too complicated and the other option would only be to rebuild the complete factory)

AGVs would automatically stop in front of the player. Don't know, if the player should be able to ride a AGV. Doesn't make much sense, since the AGVs are only moving with walking speed.
___

___

The link between the AGV and other transport systems could be made in several ways.

• An inserter could pick up goods from a bypassing belt
• A belt pointing towards an AGV input station would not need an inserter. In the input station, there is an inserter integrated to get the goods in the crates.
• At an output station, there would be one or two dedicated outputs to connect to the belts without an additional inserter. The output station has an inbuilt inserter too.
• An inserter to get goods into a cargo wagon or out of a cargo wagon might be a good idea.

___

About the layout changes:

There would be only a single lane (one tile wide) needed for a route with only one AGV and without any connections to other AGV routes.

If there are a few AGVs using the same route, you would need to build a couple evasive bays. So mostly it would be a two directional lane one tile wide with a few one directional lanes passing each other.

If you have several AGVs using the same route or if you have several AGV routes crossing each other, you might need a two tiles wide "street" with two paths in opposite directions.

But I doubt it would make much sense to add more than these two tiles wide streets. Since the transport capacity of a single AGV is limited, you still would build belts for mass products. The intention is to have a transport system for rare products.
___

Perhaps, I should make a pictures about the AGV system I have in mind (input/output stations, lanes, AGV, user interface for setting up, etc). This could be useful.
__

As a nice side effect

We could have recipes for products that are much more complicated / needed more intermediate products. And it would be possible to have several assembly machines ONLY recipes for products: No manual crafting of late game products.

It seems you just want another (cheaper, weaker?) railway system. Is it worth it?

It would be worth it if it could do 2 things:
1. Move cargo over medium distances better then belts.
2. Would need less space for loading/unloading + infrastructure then trains.

Sad_Brother wrote: ↑Sun Dec 02, 2018 11:13 pm It seems you just want another (cheaper, weaker?) railway system. Is it worth it?

No, I don't want a cheaper or weaker railway system.

My main concerns are ...

• Smaller "tracks" for a transport system within a factory. Especially the railway curves and the bulky stations do not fit well between production lines.
• An integrated pull logic controlling prepacked composition of goods without the need to build additional bulky circuit networks.
• To compensate these benefits the transport speed and the transport capacity should be limited.

As I have mentioned before I don't like the flying logistic robots very much. But the overhead to direct material to a rarely used assembly machine is too much in Factorio.

In RL you could use a Kanban system of the simplest form to request goods: A paper form filled out at the requesting machine send to the preproduction machines starting the production process

Electric engine assembly: "Need 20 iron pipes, 10 gears, 10 steel bars, 20 green circuits and 3 barrels of lubricant oil."

In RL the same simple Kanban system would be used to direct the crate loaded with material through the labyrinth of other machines: The sheet of paper would be attached to the crate.

In Factorio there is no way to direct material by using the belt lines. You are not able to attach a barcode to a crate that is passing barcode scanners at splitters.

I miss this touch of automation: The player requests at one end of the factory a special product ... and at the other end of the factory the assembly machines come to life for this particular order ... and the more and more assembled product finds its way through the factory complex to the last assembly machine finishing the production ... and delivering it to the player.

First try to show a layout with an AGV transport.


(Click to enlarge)

It is not completely reasonable yet ... just playing with the shapes to showcase some possible links to some other game objects.

The description of the shown details will be added later.

As a start ...
(The directional arrows should only be shown using the Alt button for extra information)

A3 : Belts can transport material directly into an input station

B2 : A filtering inserter can grab material from an belt to fill an input station. Other inserters can fill input stations, too.

B3-C4 : An input station. Blinking yellow to indicate a special status (here: a AGV is entering the input station). It has four possible entries for goods and two possible entries for AGVs (here only one AGV entrance is used)

B4-B5 : An AGV enters an input station. The green light shows it is operating (no errors, not waiting for a free lane etc). The colour of the AGVs (here red) should be selectable like the colour of the trains.

D7-D8 : Another operational AGV. Note: AGV don't have a front. They can drive in all four directions without turning. To indicate the actual direction a small yellow arrow lamp is lit.

F5-G5 : A railway crossing for AGVs. There are at least two signals needed : One for the AGVs (H4) and one for the trains (H6).

F7-G12 : A locomotive waiting in a railway station. It is not waiting at the railway crossing. The signals are separate. See below.

F14-G19 : An artillery wagon being loaded by two fast inserters

G5-H5 : Another AGV. It is securely using the railway crossing.

H4 : An AGV signal for AGV / railway crossing. You need one for one directional AGV lanes and two signals for bi-directional lanes. Green : The crossing is reserved for the AGVs. Yellow : No reservations made. Red : Train has reserved the crossing.

H6 : An train signal for AGV / railway crossing. Red : The crossing is reserved for AGVs. Green : A train can pass. In the case a train is going to pass the crossing will be reserved for it and the AGV signals will switch to red. You will need one train signal for every direction.

H7 : A normal railway station with a locomotive waiting.

H8 : A speed inserter to feed the locomotive with fuel from the output station next to it.

H15-H16 : Two speed inserters are loading an artillery wagon

I7-J8 : An output station. It has four possible exits for material and two possible entries for AGVs. Here no exit is used. The inserters can grab material from every tile. Both entries for AGVs are active. Here, one is connected as entrance only and the other is connected as exit only. Green light shows the station is operating and no goods are needed yet.

I15-J16 : Another output station. None of the belt exits is in use. And only one AGV entrance is used bi-directional. The red light indicates that the station is out of materials. A yellow light would be shown, if the station is operating and its supplies are running below the threshold values.

L13 : An AGV waiting in an evasive bay. The red light show that its way is blocked. It is tinted black to make a visual difference for different goods.

L14-M14 : An AGV passing the waiting AGV from L13

... to be continued.

Tairon96 wrote: ↑Mon Dec 03, 2018 2:19 am [My main concerns are ...

• Smaller "tracks" for a transport system within a factory. Especially the railway curves and the bulky stations do not fit well between production lines.
• An integrated pull logic controlling prepacked composition of goods without the need to build additional bulky circuit networks.
• To compensate these benefits the transport speed and the transport capacity should be limited.

...

• leave more space so transport line could fit
• make your own logic instead of waiting for it to be made for you
• use benefits of speed and capacity...

Remember: This game is not for factory been made.
This game is for factory been made by you.
Best wishes!

Tairon96 wrote: ↑Mon Dec 03, 2018 1:32 pm First try to show a layout with an AGV transport.

Did you make this graphics? It looks fine!

Tairon96 wrote: ↑Mon Dec 03, 2018 1:32 pm First try to show a layout with an AGV transport.

as far as i can see this is possible with the logistic-cart mod

nosports wrote: ↑Mon Dec 03, 2018 4:28 pm

Tairon96 wrote: ↑Mon Dec 03, 2018 1:32 pm First try to show a layout with an AGV transport.

as far as i can see this is possible with the logistic-cart mod

I have not been finished yet : Examples for the input forms are still missing. In such a form of an input station you enter the threshold for the connected output stations (like the selection of train stations in a locomotive) and the composition of a crate.

An early game example could be :

At the input station "Ammunition Production"
* Crate contents :
> 50 standard firearms magazines
* Own max storage
> 100 clips
* Connected output stations and thresholds
> "Northwest turret" 20 clips
> "Northeast turret" 25 clips
> "Southwest turret" 10 clips
> "Southeast turret" 10 clips
> "Power plant turrets" 30 clips
> "Remote ore patch turrets" 25 clips

Add a few empty crates to the input station plus one empty crate for each output station and add one or more AGVs to the input station.

At the start, all output stations would signal they are low on ammo. Therefore all stations get a delivery of a crate with 50 clips. At the output station "Power plant turrets" there are in this example two turrets connected via belt or directly standing next to the output station. Since a single turret can load 10 clips, the storage of the output station will already fall below the threshold of 30 clips. Immediately a second crate with another 50 clips will be sent.

If the turrets start fighting back the insectoid neighbors, the output station in question will notice a low storage and order a new crate to restock its supplies.

There is no need for long belts full of ammunition consuming a big chunk of your iron.

If you notice a turret running out of ammo, the threshold for its output station might be too low.

If you progress further in military science, you only need to switch the supply chain to the input station and adjust the contents of the crate to armour piercing ammunition. The output stations will order the new ammo while the turrets will consume the standard ammunition until it's empty and the better ammo has reached the head of the queue of the feeding belts.

I have taken a look at the logistic carts mod. Although I have not been able to get into the depths of it ... I can say, I have not been able to find any kind of pull logic. It's only push logic like the belts.