Some ideas to change Bots mechanic

[Neotix]

I have few ideas to change bots mechanic because in my opinion actual it's making mess in factory. Bots are flying like insects without any control.

Ideas:

• Bots are built only in Roboport (we have to deliver materials) and are integral part of it. It is impossible to take them into your inventory.
• Roboport can provide only limited amount of bots (tier 1 = 1 stack).
• Destruction or disassembly of the Roboport, causing the loss of his bots.
• Each Roboport has its own bots that fly only within its range and range of connected Roboport.
• Bots can be recharged in connected Roboport.
• Roboport range can be adjusted between 1 and maximum range.
• Roboports are connected only manually and only when their ranges are in contact. Bots outside the range are lost.
• Roboport can be turned On and Off. When it is turned Off, all the bots come back immediately after delivery of cargo and remain inactive.

With that we have full control. We can adjust entire system and bots became the last link in transportation chain like they should.

[Drury]

I don't understand your problem, but those are all horrible suggestions no matter what goal you're following.

[Neotix]

Problem is that we have almost no control over bots and they're flying around like they want.

When you have over 10000 bots flying around entire factory and you want to replace them (higher tiers from mods). Good luck with picking them all.

When you want to build separated storehouses managed by bots, you can't place them near other Roboports because they will auto-link together.

You can't adjust Roboport's range so you can build separated systems in limited area.

[kovarex]

I understand your objections, but these suggested changes are too brutal.

Replacing bots for newer models is now not comfortable because it is just in mod content, but automated way to upgrade the robots would really be Factorio style. I remember the great improvement in open ttd when I could upgrade my trains automatically.

Maybe there might be special version of small roboport (with smaller collision box) that would cover much smaller area, that could be used to make separate areas closer to each other.

I believe that these two changes would solve your problems while not hurting the other usecases.

[EditorRUS]

When you have over 10000 bots flying around entire factory and you want to replace them (higher tiers from mods). Good luck with picking them all.

In this case you can use console.

[ssilk]

Problem is that we have almost no control over bots and they're flying around like they want.

That's in my opinion the intended way. It is fascinating to look the bots unloading at train stations.
Yes I want to have something which tells the bots: stop transportation, go to the next roboport, so that I've a limited control.

When you have over 10000 bots flying around entire factory and you want to replace them (higher tiers from mods). Good luck with picking them all.

Then it is for me the question, why do you have 10,000 of bots?? And why over the whole factory? Why not splitted into smaller parts?
I cannot say how it is played correctly, but I mean that if it is only 10% true, this is the wrong way.

I have in my really big factory about 600 bots in the central area and only 300 are always flying around. The rest of transportation is done by transport-belts, or other stuff. When all 600 are out, this really begins to get a mess, but until then no problem.

[just_dont]

Out of the whole list, I like the idea of bots belonging (but NOT bound) to one specific roboport. This could be the cornerstone of having some simple manual bot overrides, which I'd very much like to have (like the "stop doing things and return back" command).
On an unrelated note, I'd want a manual on/off switch on ALL buildings that do any work.

Also, the roboports' linking issue. Auto-linking based on coverage isn't quite good. Perhaps, linking should be manually adjustable? I.e. like we already do with wires:
1) Roboports are linked initially based on their coverage;
2) You can shift-click to "unlink" a specific roboport;
3) You can then use some item (probably non-expendable even) to configure linking manually -- by clicking on 'ports in pairs.

Other ideas -- indeed, are way too brutal. Especially about binding bots to a single roboport. That would make them lose more than 50% of their current utility value.

[Neotix]

I understand your objections, but these suggested changes are too brutal.

I know but it show what i would like to achieve. I'm not opposite to other methods.

Replacing bots for newer models is now not comfortable because it is just in mod content, but automated way to upgrade the robots would really be Factorio style. I remember the great improvement in open ttd when I could upgrade my trains automatically.

It's not only about replacing. Sometimes i want to move some bots from one section to another. Catching them while flying is a nightmare.

Maybe there might be special version of small roboport (with smaller collision box) that would cover much smaller area, that could be used to make separate areas closer to each other.

New Roboport version is unnecessary in my opinion. Just add option to adjust range (i think it's not big problem) in the actual one and option to setup connection between them. Now i can easily control electric network (Shift key), logistic network (2 different wires) but not Roboports network. Instead of new Roboport i would like to have recharging pole (1x1).

In this case you can use console.

I can use also other cheats but it's not a solution.

It is fascinating to look the bots unloading at train stations.

I agree but we should have some options to control them. I'm not telling to control everything because it would be annoying, but some limited control should be implemented.

Then it is for me the question, why do you have 10,000 of bots??

It was example to show the point.

I cannot say how it is played correctly, but I mean that if it is only 10% true, this is the wrong way.

In my opinion it shouldn't be Right or Wrong way. Everybody should be able to play like they want and if someone decide to not use trains and transport everything by bots, than why not? Game should provide simple mechanics to support that. Factorio is that kind of game where all should be adjustable, expandable and controllable in comfortable way.

[ssilk]

Well, there are some ideas. I like this unlinking just_dont and Neotix mentioned (see also this https://forums.factorio.com/forum/vie ... 59&p=16736 )
But I would like also smaller areas between bigger ones (like here https://forums.factorio.com/forum/vie ... ion#p18749 ). And I currently think removing this connections by hand is a very big cludder.

Lets think for a moment: Assumed a roboport has a "color" (red, blue, yellow), then it belongs to one of three "logistic areas" and they aren't connected. With only three colors nearly all types of overlapping can be set up. If we then have also smaller roboports, I think every situation can be handled. By cutting the connections between the roboports this is not so sure and it is not so easy! And with this red/blue/yellow the areas can overlap! We can exchange between the zones - however this might work, if a logistic chest is in two zones is a completely different question, but there are several ways. Why not?

[bulldog98]

Lets think for a moment: Assumed a roboport has a "color" (red, blue, yellow), then it belongs to one of three "logistic areas" and they aren't connected. With only three colors nearly all types of overlapping can be set up. If we then have also smaller roboports, I think every situation can be handled. By cutting the connections between the roboports this is not so sure and it is not so easy! And with this red/blue/yellow the areas can overlap! We can exchange between the zones - however this might work, if a logistic chest is in two zones is a completely different question, but there are several ways. Why not?

This sound awesome, cause it would make all the above problems disappear.

[slay_mithos]

In my opinion it shouldn't be Right or Wrong way. Everybody should be able to play like they want and if someone decide to not use trains and transport everything by bots, than why not? Game should provide simple mechanics to support that. Factorio is that kind of game where all should be adjustable, expandable and controllable in comfortable way.

isn't it exactly the definition of mods?
The game provides a solid base and possibilities, and you customize your experience with mods to adapt it to your specifics.

[Plop and run]

With only three colors nearly all types of overlapping can be set up.

Why not make it 4 and have a fool-proof guarantee that every possibility is covered? (there is even a theorem about it.) I'm sorry, it may sound like a small detail, but I can't understand where did the 3 come from. It is not the first one I encounter, too.

[ssilk]

Well 3 or 4...
- we have the "no roboport-area" as the "fourth color".
- we don't need to follow the theorem, cause the areas can and should overlap.
- I thought 4 will give a real cludder when you overlap 4 levels in one area and have this area as "exchange" area, I mean 3 is barely, but still handleable, 4 might be a problem.

... but this may be proved by the devs.

[Nahon]

What I'd most like to see in the bots' behavior is to figure out their paths in a smarter way. As it is stated in the wiki, you will lose your bots if they run out of charge and there's no roboport in the vicinity, so one should avoid building the roboport system ("chain") in a U shape. But there are circumstances you can't achieve this, and there could be various reasons why you want the distant ends of the U shape connected and thus making it two distinct systems not possible.

What I'd suggest is that there could be a precalculation checking if the robot can make the travel it's facing or not. If it can't, it should charge itself on the way before making the trip through the no-coverage area or if this is not possible, go on a non-straight path.

I don't see a problem with losing a bot here or there but when there are large bodies of water that you can't do anything about you'll lose tons of bots and you don't have anything in your disposal to avoid it. (And there's not only chest-to-chest tasks for the bots, you have the logistics slots as well! And I forget about them too often... )


One other thing that bugs me is that you can't control what storage chests will store what items and often times the bots choose far away chests needlessly (or I think needlessly as I understand why they make that longer trip very well). This is true for construction bots as well (ie. when deconstructing stuff). I couldn't figure out a good way for this but one could be if you were able to allocate spaces in storage chests or storage chests as a whole to one item, and when an item of that kind would be stored, bots would choose the closest chest for them and not one of the "general" chests. This way you'd have some control of where you want to store stuff, but I don't think this was the best approach on this problem.

For example, I like to build my defenses from blueprints and often times it takes way too long for the bots to get there even if they're fully advanced. Usually I extend my borders by building a new line of defense and then removing the old one. If I created a storage chest and assigned it for turrets and walls, I could make it sure my bots won't travel that much building and removing stuff and when my next expansion will happen, the resources will be relatively close. Now they fly to the heart of the base where the first few chest was plopped down ages before.

[ssilk]

#1: This is told to be on the devs todo list.

#2: How the bots choose a chest: Dunno... But when they have chosen, the bots try to fill only one item into a chest. This works really: I first place every new item into a passive provider. Then I take one or more items from that chest and place it in one or more storage chests and then I exchange the passive with the active provider. The result is, that the storage chests are filled with only that item...

[Nahon]

#1: This is told to be on the devs todo list.

I didn't know, that's good news.

#2: How the bots choose a chest: Dunno... But when they have chosen, the bots try to fill only one item into a chest. This works really: I first place every new item into a passive provider. Then I take one or more items from that chest and place it in one or more storage chests and then I exchange the passive with the active provider. The result is, that the storage chests are filled with only that item...

This is true. What I wanted to suggest is, however, to make the player able to decentralize the storage of certain items as needed, to make the player able to make multiple, (relatively) small stashes of the selected items based on distance (because I can't think of any other factor that can be taken into account when - for example - automatic disassembly takes place by construction bots), when you otherwise don't have the control over the items.

For most of the cases, I agree that one item per storage chest is a good approach of the item distribution. But there are cases where you don't want this because of various reasons (it takes too much drone time and you're low on them, or you need the items in a timely fashion etc.) and this is something I think is relatively easy to achieve (it's a combination of toolbar item locking and the smart inserter filter, depending on if we talk about chest-wide or per-slot setting) and gives some amount of control, without eliminating the need to set it up and figure it out properly.