Factorio Forums

Hannu wrote: Thu Jul 08, 2021 1:31 pm

ssilk wrote: Sat Jul 03, 2021 4:52 am 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.

What do you mean with “realistic”? Do you mean some kind of Amazon flying robots, that bring you your orders? And what means efficiency for you, if this would mean, that the game runs with 50% of the not so realistic bots version?

Another example: in the 50th and 60th of last century science fiction said we will have robots in any household that do wishing and cleaning in the whole house and keep the children. What we now have are those super simple roomba’s and what they are all called. They are somehow cheap and simple and because of that, they sell like fresh bread. And this development can be seen everywhere: the more simple, specialized, time saving and cheap something is, the better. Modern engineering is all about that.

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.

Well, arguing with the speed of the game is indeed questionable. on the other hand I think the current implementation is super simple. So simple, that even a simple check for the best route to the target decreases decreases speed of this by much more than 50%.

ssilk wrote: Fri Jul 09, 2021 3:55 am What do you mean with “realistic”? Do you mean some kind of Amazon flying robots, that bring you your orders? And what means efficiency for you, if this would mean, that the game runs with 50% of the not so realistic bots version?

No, I mean more general things. There are no such transport bots in real life but generally for example improving single unit performance by firmware update is always preferred over buying more units or support systems (like roboports). If there were such system tehre would certainly be huge number of configuration options. Bots could be assigned to certain routes, target choosing priorities could be configurable etc. All that would be very interesting challenge in simplified game format. Current system is very stupid. Operation is very much random (based on order of some internal object lists in memory) and configurable parameters do not exist. Only solution is to spam more and more.

They are somehow cheap and simple and because of that, they sell like fresh bread. And this development can be seen everywhere: the more simple, specialized, time saving and cheap something is, the better. Modern engineering is all about that.

Not all about. That is cheap scrap production for masses. But there are much more interesting areas with completely opposite demands. For example industrial machines and control systems. They must be reliable and safe. Buying costs are not important. I think Factorio as game of very special industry and not a simple mass production of cheap scrap. Base story about alone astronaut stranded on strange planet would not fit very well in mass production theme.

Well, arguing with the speed of the game is indeed questionable. on the other hand I think the current implementation is super simple. So simple, that even a simple check for the best route to the target decreases decreases speed of this by much more than 50%.

I do not argue against that. But I argue that there are situations in which 10 times more computing would improve efficiency much more and total effect would be good. Or what is more important, it would save my time in real life if there were less waiting. Two types of bots would give both possibilities without much cost to devs or players. Devs can say that they do not expect it to be economically feasible if they take programming costs and increased sales and customer happiness into account but saying that another clever type of bot would increase CPU load even player decide to not use them is not true.

mmmPI wrote: Thu Jul 08, 2021 7:26 pm 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.

This is economic reason I told in another post. It has nothing to do with CPU. In any case there are ways to overload CPU if there are not artificial restrictions. I had one Civilization like game in Amiga which had artificial limit in number of units and it was much more annoying than playing at 5 fps.

There would also be more "natural" ways to prevent overloads. For example cost or energy consumption could be so large that it would be impossible to overload cpu without mods or cheats. Non linear dependencies would be very effective in this kind of limitations.

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.

It is not needed in entertaining playing. Factorio works very well. But it would give more interesting options to solve logistic puzzles and set own rulesets. In my opinion it would make Factorio much more interesting even overall result would be less production.

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.

You are right. Logistic system should be overhauled. Or there could be another tier in addition to current one. But this hope is too late. The game is ready and it is so popular that future development is less complexity and more eyecandy. Devs deserve success, this is great game, but on the selfish point of view I would like more nerdy games.

Maybe in future someone copy a basic idea from Facorio but make real challenging game for engineers and tech students.

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.

Yes, there are possibilities. But I think it is better to stop in that phase. Just adding numbers until dropping fps begin to annoy is not interesting gaming. I am not competitive player at all. My personal hate against beacons restrict my production to low numbers. And also tendency to make realistic looking rail systems instead of optimal.

I just want one feature, and it would apply to the whole network if enabled (feeding a constant to a roboport, or a GUI toggle on a roboport), and that's "restrict flying to roboport zone". I.e. bots can't fly beyond the construction zone. This would imo solve many issues that can arise with irregular bases. Bots trying to fly through no-mans-land to reach a perimeter, having to constantly turn back, or bots flying over enemies in concave bases (like L shaped for example). Not sure how realistic to implement. Presumably bots would need to find a path on a graph where nodes are every roboport, and take that path. Simple pathfinder in principle, yet magnitudes more work than the current implementation.

I'd still like it though, even if it will never happen

Hannu wrote: Fri Jul 09, 2021 11:08 am Bots could be assigned to certain routes, target choosing priorities could be configurable etc.

Already possible, but a) it’s a mod https://mods.factorio.com/mod/LogiNetChannels b) it works differently as you think.

Because the bots don’t decide how to fly. The logistic network looks “oh, here is a request! Can we provide that request? Yes! Is there a bot, that can do that within my network? Yes! Super! Bot: you go to chest A at xy and pick up z items of w. Then go to chest B at xy an drop it. When ready you let me know.”
Bot: “Ayeaye!”

The bot is super stupid, most things are done by the logistic network controller. This is because if every could control himself this would lead to situations, where a new requester chest is placed, all bots would like to fulfill the request at once, which leads to game getting stuck for a second or so. Having a controller per logistic network allows to handle ten bots per tick (600 per second). That’s the reason, why placing a new requester chest leads to this “snake of robots” coming out of the roboports.

All they can do is go to xy and pick up, go to xy and drop, searching for a loader, if charge is needed and when orders are done search for a roboport to park. Maybe I forgot some things, but that’s basically it.

Now: what to add? What commands should be added to the bots, that a controller can tell them what to do?

All that would be very interesting challenge in simplified game format. Current system is very stupid. Operation is very much random (based on order of some internal object lists in memory)

It looks random, but isn’t. It follows a very simple and clear algorithm.

Only solution is to spam more and more.

No, that is absolutely not right, because there is an optimum of bots in a network. This follows out of what I explained above: the controller assigns only a limited number of bots per second. So there is a natural limit. The second natural limit is, that you can charge only X bots per second in a network. But this subject is already discussed a lot in the last years. The simple conclusion is: bots are extremely useful for peak transport (filling up players inventory, construction) over relatively short distances. Out of that scope you soon begin to find the problems that leads to thinking about needing more control over the bots.

I do not argue against that. But I argue that there are situations in which 10 times more computing would improve efficiency much more and total effect would be good. Or what is more important, it would save my time in real life if there were less waiting.

Aha! That’s the point!

The reason why I explained a bit how the bots work internally is, that with knowledge and careful watching and measuring it is possible to find strategies, which will effectively help to go over these limitations and make things much faster. Some are already mentioned in this thread. But this needs you to change. Not the game.

Two types of bots would give both possibilities without much cost to devs or players. Devs can say that they do not expect it to be economically feasible if they take programming costs and increased sales and customer happiness into account but saying that another clever type of bot would increase CPU load even player decide to not use them is not true.

Well, instead of this theoretical discussion I recommend to make a much more specific suggestion in the suggestion-board, which can be better discussed, because what I also see in this discussion is, that there are different ideas, what “control over bots” should mean.

Molay wrote: Fri Jul 09, 2021 8:30 pm I just want one feature, and it would apply to the whole network if enabled (feeding a constant to a roboport, or a GUI toggle on a roboport), and that's "restrict flying to roboport zone". I.e. bots can't fly beyond the construction zone. This would imo solve many issues that can arise with irregular bases. Bots trying to fly through no-mans-land to reach a perimeter, having to constantly turn back, or bots flying over enemies in concave bases (like L shaped for example). Not sure how realistic to implement. Presumably bots would need to find a path on a graph where nodes are every roboport, and take that path. Simple pathfinder in principle, yet magnitudes more work than the current implementation.

A very good example of what’s not will be possible. This means, that the bots need to constantly look up a table of “restricted areas”. A function takes their coordinates and looks for every tick: am I in a restricted zone?
It cannot be controlled how many restricted zones there are and the algorithm effort is dependent on the number of bots multiplied with the number of zones.

A good new order for the bots is calculated only once (e.g. when a bot needs to go to a coordinate he needs only to calculate the exact vector). He needs to do this only at the begin of a new command. Once and not every tick.

You can argue, that they already do change their coordinates every tick and look up, how many charge is left, yes, but this simple operations runs so fast inside of the cpu, that it will take only a microsecond for 10000 (or so). What runs fast, what not? You need to transfer the code plus as many bots as possible into the internal CPU-cache, then run, and transfer the results back to memory. So if it runs on the Cpu, it’s fast enough. A lookup to the map is not, because the map is BIG.

ssilk wrote: Sat Jul 10, 2021 9:16 am
The bot is super stupid, most things are done by the logistic network controller. This is because if every could control himself this would lead to situations, where a new requester chest is placed, all bots would like to fulfill the request at once, which leads to game getting stuck for a second or so. Having a controller per logistic network allows to handle ten bots per tick (600 per second). That’s the reason, why placing a new requester chest leads to this “snake of robots” coming out of the roboports.

All they can do is go to xy and pick up, go to xy and drop, searching for a loader, if charge is needed and when orders are done search for a roboport to park. Maybe I forgot some things, but that’s basically it.

Thanks, it is nice to know even I have suspected something like that based on behavior.

The reason why I explained a bit how the bots work internally is, that with knowledge and careful watching and measuring it is possible to find strategies, which will effectively help to go over these limitations and make things much faster. Some are already mentioned in this thread. But this needs you to change. Not the game.

I do not use logistic bots except for irregular and/or very low volume transports. My worst problem is very bad performance of personal construction bots and there are no effective ways to improve it except mod bots and charging superfast and energy consumption negligible.

Well, instead of this theoretical discussion I recommend to make a much more specific suggestion in the suggestion-board, which can be better discussed, because what I also see in this discussion is, that there are different ideas, what “control over bots” should mean.

I do not believe that there is any real possibility to change even I do proper suggestion. Mod solution is OK for me. What is wrong with general discussion on this kind of things?

Actually I would prefer instant building of blueprints (as endgame feature which need space science to research). But I am sure that there are massive opposition who think it would be overpowered (even it would be completely voluntary to research and use).

Hannu wrote: Mon Aug 09, 2021 2:44 pm

ssilk wrote: Sat Jul 10, 2021 9:16 am Well, instead of this theoretical discussion I recommend to make a much more specific suggestion in the suggestion-board, which can be better discussed, because what I also see in this discussion is, that there are different ideas, what “control over bots” should mean.

I do not believe that there is any real possibility to change even I do proper suggestion. Mod solution is OK for me. What is wrong with general discussion on this kind of things?

Nothing is wrong with it. This is a general discussion about controlling robots.

Specific discussion about improving robot control is a suggestion. Which is this other board with the name “Suggestions”.

Actually I would prefer instant building of blueprints (as endgame feature which need space science to research). But I am sure that there are massive opposition who think it would be overpowered (even it would be completely voluntary to research and use).

This is a totally different subject, therefore you should make a new thread in the suggestion board. It’s simple!

Hannu wrote: Thu Jul 08, 2021 1:31 pm I do not see any balancing or other gaming issue if end game building of 40000 concrete tiles were (almost) instant.

This is not gonna happen no matter what you do. It is already very much possible to have an ideal setup for this with the current bots. Thousands of tiles is going to take a little while to place. You would need to actually increase the battery capacity of bots and have a very high speed for them, the former which is prohibited by current game balance and the latter only acquirable very late into the game.

Also do keep in mind that task assignment for thousands of entities with a complex bot control system would actually take a lot of resources. It already speaks volumes that the current robot task assigner can only assign maybe a thousand tasks per second. Remember, with these advanced bots, to achieve for example a "shortest path" functionality, you might have to do something as bad as check the distance between every tile, for every item required, for every bot in the system. Assuming some very conservative numbers for a case like this, let's say 1000 tiles, and 2000 bots, 1 trip in each direction, that's 4 million square roots you have to compute. This isn't impossible to compute though and there is of course a lot you could optimize, but this is just one simple case, a tiny fraction of the full program requirements for bots like this. Even this single case would require a lot of time for developing optimizations to reach sufficiently good performance, especially considering that this isn't even nearly the worst case scenario, and all of that is nothing to speak of the complexity that arises from all possible bot behaviors. In a good case you could make it run well on a beefy PC, but in Factorio it's also about keeping the computational requirements low enough for weak PCs.

As for the question of why devs don't make 2 types of bots, dumb ones and smart ones, well, I think it is technically a real possibility, but it is quite a lot of complexity, some of which I mentioned above, and thus a lot of work required, so I suppose it's just that the line was drawn there in the end. Even without it, you still have at the very least decent bots at hand, which probably fulfills the design intent quite nicely. As further pointed out by others, the new suggestion also creates the potential for misuse from players, which is something you really want to avoid as a game designer. Even smart players won't truly understand the repercussions until they've tried it out, and more importantly, designing games is about immersing the player, not making them worry about the computational power of their PC. The feature could maybe make sense, but it was just outside the scope of the game, is how I'm seeing it.

Correction: the “task assignement” can assign many thousands of bots per tick. But the game will become super laggy/sluggish. Same if you place 40000 tiles in a tick.

The bots work as they work also to avoid this and enable a smooth gameplay.

ssilk wrote: Wed Aug 11, 2021 4:20 am Nothing is wrong with it. This is a general discussion about controlling robots.

Specific discussion about improving robot control is a suggestion. Which is this other board with the name “Suggestions”.

My point is more general discussion about how robot system could be improved (in some sense, it is always compromise) or made by other way. I do not think devs have any interest to make this kind of changes if I make detailed suggestions. They may be relatively laborious changes and only small minority of players are interested in this kind of things. Current bots work very well except in very extreme situations. I can also make most of things with modding or commands which is OK because I do not care about achievements or have moral issues with "cheating".

But for example some new developer may read these general discussions and get ideas for another game.

The devs read also the suggestions-board.

We (the forum members) cannot know how an idea for something new becomes a Factorio-reality. (*) That process depends on too many factors. But we surely can improve the chance of happening.

(*) would be quite interesting to hear more about that process.