We need more control over bots

[JackGruff]

This is not a feature suggestion.

I was putting down some roboports in an outpost. The outpost didn't have power. After having put some construction bots in one of the ports, they rushed out to get some trash from me and stuck around as there was no storage. Then they bounced from port to port as the ports ran out of power before heading off to another outpost and getting themselves destroyed in the process.

No doubt many of you have experienced some variation of bots doing what they are told over doing what you want (much like writing software). This makes me feel that there's a missing piece here. It has come up time and time again with many suggestions but from what I've read, they come up with new things you can place in your factory rather than pieces you can assemble into something you want. As the game has progressed, we have gotten more features for the bots but no way to actually make them smarter or customisable.

And I think that's it: what we are missing for bots is what the circuit network is to the rest of the factory.

[Koub]

Every single bit of control will very likely result in overhead, which is something the devs deem undesirable. The bots have so little impact on game performance because they are stupid.
And even that little impact quickly becomes too much.

[JackGruff]

Every single bit of control will very likely result in overhead, which is something the devs deem undesirable. The bots have so little impact on game performance because they are stupid.
And even that little impact quickly becomes too much.

Yes, there will be overhead, so what? What makes bots more deserving of performance than anything else?

[Koub]

The bots are not special. Everything (or almost) in this game is optimized for performance so that one can have tens of thousands of it in a base, without the game struggling to run, even on a modest computer.
I'm not saying I dislike the idea of more "intelligent" or controllable bots, it's just that from what I've seen so far, the devs are not willing to trade complex behaviours (for anything) if the price would be overhead.

[DarkShadow44]

And I think that's it: what we are missing for bots is what the circuit network is to the rest of the factory.

I don't think I can imagine what you mean. How exactly would that look like?

[Krazykrl]

And I think that's it: what we are missing for bots is what the circuit network is to the rest of the factory.

I don't think I can imagine what you mean. How exactly would that look like?

Turing completeness and massive flexibility.

Things like checking for logic and acting on logic for every action that the robot performs. Charging? Lemmie check first. Landing in a roboport? Check logic. Exiting roboport, check logic. Flying to a location, gotta check. Picking up items, checking logic. Finding a path, check logic for any restricted zones or roboport areas, then calculate path. During transit, check logic for any dynamic state changes that may occur. Dropping items needs logic checks. Then the robot becomes available for new scheduling commands if any number of arbitrary control conditions are passed to the robot network.

Currently the robots are dispatched without any logic or checks. And even this simple system requires massive optimization with things like dispatch queues and clever caching methods.

[Qon]

Currently the robots are dispatched without any logic or checks. And even this simple system requires massive optimization with things like dispatch queues and clever caching methods.

What do you think happens to all the current performance optimizations and your UPS in general if a turing complete ruleset was executed before any bot action?

[eradicator]

Currently the robots are dispatched without any logic or checks. And even this simple system requires massive optimization with things like dispatch queues and clever caching methods.

What do you think happens to all the current performance optimizations and your UPS in general if a turing complete ruleset was executed before any bot action?

It's the perfect winning move to end the Bots vs Belts Wars. It'll be a glorious victory .

[Koub]

It's the perfect winning move to end the Bots vs Belts Wars. It'll be a glorious victory .

Actually, from what I've understood, belts have already more or less won the war in all scenarios that are not explicitly in their domain of excellence (short bursts of very high throughput on short-ish distances). The successive optimisations belts have undergone made them extremely competitive UPSwise (when used correctly). I know you already know that, but it's for the broader audience ^^.

[blazespinnaker]

It's the perfect winning move to end the Bots vs Belts Wars. It'll be a glorious victory .

Yes, +1 on OP suggestion.

[Hannu]

What do you think happens to all the current performance optimizations and your UPS in general if a turing complete ruleset was executed before any bot action?

The easiest solution would be two types of bots. Current bots as basic bots and then high tech-bots with sophisticated and preferable programmable logic. Megabase builders could use current UPS-cheap bots and logistic nerds could use smaller numbers of sophisticated bots to achieve complicated functions (or even reasonable basic operation).

[Eketek]

What do you think happens to all the current performance optimizations and your UPS in general if a turing complete ruleset was executed before any bot action?

The easiest solution would be two types of bots. Current bots as basic bots and then high tech-bots with sophisticated and preferable programmable logic. Megabase builders could use current UPS-cheap bots and logistic nerds could use smaller numbers of sophisticated bots to achieve complicated functions (or even reasonable basic operation).

I think that "high-tech" robots would be interesting if a Befunge-like programming language is used for them (program represented as a physical arrangement of objects or signals from circuit-connected objects, program execution accomplished by robots driving around and scanning things for commands).

[netmand]

they rushed out to get some trash from me and stuck around as there was no storage. Then they bounced from port to port as the ports ran out of power before heading off to another outpost and getting themselves destroyed in the process.

For this I always lay down a yellow storage chest first.

But to follow on the stated need for more control; it seems it might be better said to look for a way to segregate and identify logistic networks and have a way to configure a specific network to collect trash items, leaving newly created additional networks, such as ones that are established on outposts, to ignore trash collection. To me this would preserve the overall functionality of the bots without making some complex overhead-heavy new methodology in altering the way bots work.

[MiniHerc]

This is not a feature suggestion.

I was putting down some roboports in an outpost. The outpost didn't have power. After having put some construction bots in one of the ports, they rushed out to get some trash from me and stuck around as there was no storage. Then they bounced from port to port as the ports ran out of power before heading off to another outpost and getting themselves destroyed in the process.

Seems to me that problem would have been solved if bots in unpowered roboports didn't do stuff.

[ssilk]

The easiest solution would be two types of bots. Current bots as basic bots and then high tech-bots with sophisticated and preferable programmable logic. Megabase builders could use current UPS-cheap bots and logistic nerds could use smaller numbers of sophisticated bots to achieve complicated functions (or even reasonable basic operation).

I think that "high-tech" robots would be interesting if a Befunge-like programming language is used for them (program represented as a physical arrangement of objects or signals from circuit-connected objects, program execution accomplished by robots driving around and scanning things for commands).

If this would be enabled, what is then the difference between a computer controlled robot and a computer controlled player with a jet pack?

I mean this: it’s already possible to make a mod, that spawns another player that does more or less clever things.
And it’s also possible (?) to control bots like so.

What new game-play would that enable? That’s the good question here. And I mean: nothing special. The only really interesting thing would be, to let those computer controlled “players” build a factory, like JOSEF in https://alt-f4.blog/ALTF4-39/ . Anything else would be just more comfort for more complexity and less speed.

So, just more control (programmable) over bots without a very good and specific argument why that would enable a better game-play is a “shoot against the wind”. A very specific new ability for the bots to make a specific situation more controllable is on the other hand something, that could be thought about, but also here: there are already some suggestions about more clever routing of bots. Will not implemented, because of the extra CPU it takes for this task.

[Krazykrl]

What new game-play would that enable? That’s the good question here. And I mean: nothing special. The only really interesting thing would be, to let those computer controlled “players” build a factory, like JOSEF in https://alt-f4.blog/ALTF4-39/ . Anything else would be just more comfort for more complexity and less speed.

My suggestion would be to have something like a cargo zeppelin that would dock to specific roboports, these roboports would get their entities changed to a non-logibot/conbot zeppelin charging/landing port when set to a zeppelin landing point. Their great size (probably 8x6 due to roboport's 4x4 size) creates a large perimeter for inserters directly on the zeppelin... or you could have the zeppelins directly swap inventories with the zeppelinport with its own 4x4 footprint.

The idea being a sky taxi for passenger service, maybe with a vehicle grid for perimeter defense, rebuilding, and repair. But with a high electricity cost, and substantially less throughput than belts, rail, or mass logibot. Since the zeppelin should essentially be a huge flying robot with an internal cargo wagon.

[Challenger007]

This is not a feature suggestion.

I was putting down some roboports in an outpost. The outpost didn't have power. After having put some construction bots in one of the ports, they rushed out to get some trash from me and stuck around as there was no storage. Then they bounced from port to port as the ports ran out of power before heading off to another outpost and getting themselves destroyed in the process.

No doubt many of you have experienced some variation of bots doing what they are told over doing what you want (much like writing software). This makes me feel that there's a missing piece here. It has come up time and time again with many suggestions but from what I've read, they come up with new things you can place in your factory rather than pieces you can assemble into something you want. As the game has progressed, we have gotten more features for the bots but no way to actually make them smarter or customisable.

And I think that's it: what we are missing for bots is what the circuit network is to the rest of the factory.

It would be cool if the bots were trainable. This would make the gameplay more interesting.

[Hannu]

What new game-play would that enable? That’s the good question here.

More efficiency and realistic like solutions in logistic problems. Probably nothing for far majority of players. I do no expect this kind of things in Factorio but hope that someone will make more nerdy games with interesting game mechanics without graphical eye candy or other expensive but futile things.

there are already some suggestions about more clever routing of bots. Will not implemented, because of the extra CPU it takes for this task.

That is more realistic, but probably not realistic after all. Like 1:million compared to 1:billion.

I do not believe that CPU explanation. Two types of bots would prevent CPU issues for those who want 100000 stupid CPU efficient bots. Devs just do not think it is worth programming. It is probably true from their point of view but I disagree that. The most clear change would be very significant speed increase of build operations. I do not see any balancing or other gaming issue if end game building of 40000 concrete tiles were (almost) instant. In that phase the most limited resource is my freetime in real life. I do not have enough time and patience to copy enough units and wait they will be build to melt my CPU.

[Qon]

I do not see any balancing or other gaming issue if end game building of 40000 concrete tiles were (almost) instant. In that phase the most limited resource is my freetime in real life. I do not have enough time and patience to copy enough units and wait they will be build to melt my CPU.

/editor

[mmmPI]

I do not believe that CPU explanation. Two types of bots would prevent CPU issues for those who want 100000 stupid CPU efficient bots.

On paper yes, but if you provide the software as a game to a wide audience, risk of "misusage" or at least "not intended" usage of the tools you provide will occur.
The very existence/implementation of item in the game that could, when misused, create an unpleasant experience for a random user is probably something that you want to think about twice as a dev.
There could be complaints from people making their game slow and complaining about the software without questionning/adapting their practices which would give a negative image because the matter would be highly subjective.

I'm not saying everything should be fool-proof or even could be, and i like the idea of "more control over bots" but i don't think it's NEEDED.

Another i think is missing for this to happen is the ability to designate area:

- robotports don't have (configurable) name or ID, only logistic networks have one , and it's (imo) not a feature that has much interaction with the rest of the game (only with inserters ?).

- location/geography even coordinates are not much used in the game, (imo) you are not supposed to be aware of the "grid" as a player, it's not explictly showed to the player as something meaningfull.

Without this it seems to me difficult to implement a logic whose purpose would be to direct bots on a map.

When i try to think of myself enjoying the potential new features i imagine it may be like naming train stations, except a whole lot more numerous in the first case as you'd need to rename all your robotport, or network. In the actual game you don't see the name of the train station in the combinators, i don't see how you can input string of text in a combinator. My limited imagination cannot see the solutions only the problems going in that direction.

The other way would imply doing some geometrical algebra to designate area by their coordinates or something similar to what you do when you use the recursive blueprint mod , in which your order your bots to place blueprint by designating area on the map using their coordinates. I don't think it would make it EASIER to control bots, that's not a way in which a player can easily add a little input to prevent gross inefficiencies from bots as it seems to be the desired objective if we consider more clever bots are NEEDED.

A convenient way would be the ability to select on the map a bunch of bots that are lost as you do in a RTS, and click a robotport in which you want them to move. Then you try to think again to find out a way for it to not happen again. But that's going the opposite direction of making some more nerdy interesting mechanics.

In that phase the most limited resource is my freetime in real life. I do not have enough time and patience to copy enough units and wait they will be build to melt my CPU.

Well you could use the recursive blueprint mod, and set it so that a new area is covered of concrete only when the previous is done. Or that bots copy first the factory, and only when it's done they place the concrete underneath as a background task. Or even a little contraption you blueprint in a corner of an area and it will cover it with concrete over time. There are ways to spent time doing fun things instead of waiting for the bots to complete a task

I think that "high-tech" robots would be interesting if a Befunge-like programming language is used for them (program represented as a physical arrangement of objects or signals from circuit-connected objects, program execution accomplished by robots driving around and scanning things for commands).

Could you elaborate on that ? because the 2nd part your description made me think to the mod AAI programmable vehicule. With the mod you can draw lanes and signals on the floor that are read by the automated vehicules. You can for example "paint" an ore patch with little crosses, then make it so that a vehicule will try to mine only in this area. It doesn't remove the need to designate area on the map to automate things, but it makes it in a different way than with robotport name/ID and coordinates ( at least from a player point of view). I had never heard of befunge before and a quick research made me doubt i could be sure to see the link.