Simple Transport: Behaviours vs Logistic System

[Draken]

After few hours of playing around with behaviour system I got most 'basic behaviours' (like scouting, mining, deconstruction, etc) set up and working.

The only thing that I cannot, for the love of god do right is just very basic transfer of resouces from point A to point B.

The codex example (pick from A, deliver to B) doesn't really work when I want deliver resouces between two storages.

The transport mode while being part of logistic system also doesn't work. (GoTo and Storage were set, but the bot did nothing)

The bot just picks the load from storage A, and sits next to storage B without delivering the payload, even though storage B is empty, and have no locked slots of different type.

If I turn on logistic system on Storage B, it instantly get full of request orders, even if in logistic system the 'requests' are turned off. And the same bot just sits down.

I'm at a loss - the logistic system works, but it inefficient like hell. The behaviour system doesn't work, even though it should.

Why are the item delivery requests generated, when I toggled request off from the logistic system of storage B?

[Johan 2.0]

Originally posted by Draken:

The transport mode while being part of logistic system also doesn't work. (GoTo and Storage were set, but the bot did nothing)

The bot just picks the load from storage A, and sits next to storage B without delivering the payload, even though storage B is empty, and have no locked slots of different type.

Checklist:

1. Transport Route Setting enabled (the icon should turn into vertical arrows instead of a wifi icon)
   
2. Logistics Enabled for the unit transporting
   
3. GoTo register set to the source of items to collect
   
4. Store register set to the destination to drop off

[Quait]

Make sure that the items are not reserved by a request. (rightclick and cancel order). This reservation blocks any other entity from picking it up.
This infinite blockage happens when you switch a bot to transport mode and its previous job still exists but since it now is in transport mode it will never complete its old job, its reservation on the item it was about to pickup will stay reserved.

Also dont turn on the Logistic Network (dont light up the double arrows button) on Bots that only transport from A to B. if you turn it on the bot will do both jobs, often ignoriering its A to B job completly if alot of requests are in the network.

[Draken]

Thanks Johan,
I did check that/played around a lot before even starting the discussion.
It is like you wrote, but it still doesn't work.

Here is the mule (bot) settings:
https://steamcommunity.com/id/Veriok/screenshot/2037369044905027612/

Input storage settings:
https://steamcommunity.com/id/Veriok/screenshot/2037369044905027348/
(channel 4 also on because thats my storage channel, there is a few linked storages and they deliver their load to the final storage - which is the input one).

Output storage settings:
https://steamcommunity.com/id/Veriok/screenshot/2037369044905027026/

The outcome:
The bot picks from input storage. And idles next to it. Output storage empty, and full of generated requests, even though the only bot on channel 3 is the mule...

[Johan 2.0]

It might be that the orders are all reserved by bots that no longer have access to those networks.
Try selecting the storage - Press F > Orders and then check the box in the bottom left for showing only orders for that unit

[Draken]

[Solved] The issue was with the input storage pointing to the output storage, which keep generating requests (that were impossible to complete) for output storage.

Uhh.

Now my foundries are back online at the meager cost of 10 energy.

[Quait]

yep, a stuck request. when something is not behaving its often a stuck request.

[DevilsHandMeDown]

I had to cancel the orders from the worker, and then go to the storage it was supposed to drop off at and cancel the orders there also. After i cancelled the orders from both sides, the worker was freed from the orders reappearing in their order slots.