Bots that are aware of their charge level and plan accordingly.

[mrvn]

3) In my case the bot searches in a radius of 80% fuel from the point where it is down to 20%. Note that this might find a roboport that is 160% fuel from the source. So this will sometimes pick a roboport to recharge that is out of reach and get there very slowly. Just like it does now. Hopefully the roboport it finds is nearer or at an angle so the bot cuts the corner and has a shorter distance to travel. But this will preserve cases where bots can currently reach the target very slowly by crossing a void.

Question: would it not be better to search in a radius of 20% fuel from the 20% point?

Anything in a 20% radius would be reachable for sure. But what if there isn't any such roboport?

But maybe there is a roboport 50% back the way you "came" so you can actually reach it with ~30% fuel charge and then try again. The 80% radius is just because at that point you will find the source roboport because that is how far away it is. Unless the bot isn't at a roboport to start with, then it might have to look further. I sure hope bots have a way of searching roboports by distance and don't have to check all to see which is closest.

It would be best if you find a roboport that is less than 100% fuel distance from the source. You would search for that differently. Start at the point that's 100% fuel towards the target and then search backwards along the way for a roboport that's within the 100% fuel radius and closest to the target. Or take the one that is least off course. But that would be a big change in the code and who knows what performance change that would bring.

So, no, lets keep it at the 20% point and searching just like bots do now. Just getting that minimal change into the game would be a big win.

[FuryoftheStars]

3) In my case the bot searches in a radius of 80% fuel from the point where it is down to 20%. Note that this might find a roboport that is 160% fuel from the source. So this will sometimes pick a roboport to recharge that is out of reach and get there very slowly. Just like it does now. Hopefully the roboport it finds is nearer or at an angle so the bot cuts the corner and has a shorter distance to travel. But this will preserve cases where bots can currently reach the target very slowly by crossing a void.

Question: would it not be better to search in a radius of 20% fuel from the 20% point?

Anything in a 20% radius would be reachable for sure. But what if there isn't any such roboport?

But maybe there is a roboport 50% back the way you "came" so you can actually reach it with ~30% fuel charge and then try again. The 80% radius is just because at that point you will find the source roboport because that is how far away it is. Unless the bot isn't at a roboport to start with, then it might have to look further. I sure hope bots have a way of searching roboports by distance and don't have to check all to see which is closest.

It would be best if you find a roboport that is less than 100% fuel distance from the source. You would search for that differently. Start at the point that's 100% fuel towards the target and then search backwards along the way for a roboport that's within the 100% fuel radius and closest to the target. Or take the one that is least off course. But that would be a big change in the code and who knows what performance change that would bring.

So, no, lets keep it at the 20% point and searching just like bots do now. Just getting that minimal change into the game would be a big win.

Sorry, my thought would be search the 20% radius, then increase in steps if none found, but I suppose this would just increase CPU cycles on consecutive searches, though it would cut out the idea of searching the larger range at first and then having to run distance checks on all found roboports, which, based on images I've seen of other people's setups, could be a lot.

Either way, regardless, yes, I agree that it should conduct the search from the 20% point the same way as it does now.

[mrvn]

Sorry, my thought would be search the 20% radius, then increase in steps if none found, but I suppose this would just increase CPU cycles on consecutive searches, though it would cut out the idea of searching the larger range at first and then having to run distance checks on all found roboports, which, based on images I've seen of other people's setups, could be a lot.

Either way, regardless, yes, I agree that it should conduct the search from the 20% point the same way as it does now.

Hopefully there is a data structure in place so that there isn't much searching going on to find the nearest roboport(s). Roboports are rather sparsely placed and don't change that often that you could record the nearest few roboports in every chunk, e.g. all roboports where the chunk is inside the logistic/construction zone. This will be useful when the player enters a chunk or when a ghost is placed anyway. And then for the bot to find the nearest roboport it just has to check the few listed roboport for the chunk. You probably want something a bit smarter to deal with roboports with different ranges in mods but you get the idea.

You certainly don't want to have to check every tile in a 20% or 80% or even more radius to see if it contains a roboport. You could search the tiles in a spiral to find the closest but it would still be a massive task.

[BicycleEater]

OK, I love this suggestion.
It has the potential to solve some really annoying problems, and doesn't really threaten the use of belts, as it addresses situations faced by bots going super long distances, not those going short intra-factory hops. It fixes a problem I face far more with construction bots than with logistics. I also agree that it would add minimal time cost to drone calculation.

In terms of the problem where the closest roboport is the one it is already at, this is a rare case, so some special code could be used.
I think there are a few ways of solving it:

• To exclude the current roboport from the search for nearby roboports - this may solve it in some cases, but doesn't really help that much.

• To do a different search, say looking for the roboport closest to the destination that is within range. This isn't neceserily helpful, as that might still be the current roboport. This might also be pretty expensive, as there are few optimisations available.

• To make the drone look further along its path - say in increments of 20% of range, until it finds a different roboport. This is slow to perform, but guarantees results, and only needs doing when a drone would otherwise be stuck, which is rare anyway (this is my favourite).

• To make the drone just go straight to its destination, running out of power part way and ignoring it.

To avoid the performance problems people are complaining about when the target is moving, I would suggest that these calculations get done only when the drone takes off, and the normal drone handling happens from there - if the target runs away, the drone recharges when it reaches 20% charge, unless it was already aiming to recharge.

[mrvn]

OK, I love this suggestion.
It has the potential to solve some really annoying problems, and doesn't really threaten the use of belts, as it addresses situations faced by bots going super long distances, not those going short intra-factory hops. It fixes a problem I face far more with construction bots than with logistics. I also agree that it would add minimal time cost to drone calculation.

In terms of the problem where the closest roboport is the one it is already at, this is a rare case, so some special code could be used.
I think there are a few ways of solving it:

• To exclude the current roboport from the search for nearby roboports - this may solve it in some cases, but doesn't really help that much.

• To do a different search, say looking for the roboport closest to the destination that is within range. This isn't neceserily helpful, as that might still be the current roboport. This might also be pretty expensive, as there are few optimisations available.

• To make the drone look further along its path - say in increments of 20% of range, until it finds a different roboport. This is slow to perform, but guarantees results, and only needs doing when a drone would otherwise be stuck, which is rare anyway (this is my favourite).

• To make the drone just go straight to its destination, running out of power part way and ignoring it.

To avoid the performance problems people are complaining about when the target is moving, I would suggest that these calculations get done only when the drone takes off, and the normal drone handling happens from there - if the target runs away, the drone recharges when it reaches 20% charge, unless it was already aiming to recharge.

First for the moving targets: Yes, this calculation should be done only once when the drone leaves, as proposed. There is no difference for this proposal for a moving or stationary target. Doing this every tick, or every time the target moved would be insanely costly.

As for the case of the bot picking its source as recharging target:

As a first iteration this should raise an alert and let the bot try to reach the target like it does now. This would be a minimal code change.

As a second iteration maybe the search for the next roboport could be changed to ignore all roboports that aren't closer to the target. The alert if it hits (and ignores) the current roboport should be kept. If no roboport is found or it is further than the target itself then keep going to the traget directly. Better to get there slowly than not at all.

A third iteration could pick the next roboport smartly. One with the least amount of deviation from the course. It might be better to target a roboport at 50% charge distance than one at 90% charge distance that is far of course. But again, big code change, so not holding out for that.

Please lets concentrate of the simplest fix first.

[BicycleEater]

Please lets concentrate of the simplest fix first.

Yes absolutely - the originally proposed change would be a really big improvement, and the rest is just dealing with edge cases on that.

As for the case of the bot picking its source as recharging target:

As a first iteration this should raise an alert and let the bot try to reach the target like it does now. This would be a minimal code change.

As a second iteration maybe the search for the next roboport could be changed to ignore all roboports that aren't closer to the target. The alert if it hits (and ignores) the current roboport should be kept. If no roboport is found or it is further than the target itself then keep going to the traget directly. Better to get there slowly than not at all.

A third iteration could pick the next roboport smartly. One with the least amount of deviation from the course. It might be better to target a roboport at 50% charge distance than one at 90% charge distance that is far of course. But again, big code change, so not holding out for that.

Raising an alert would be a good simple helper - it wouldn't fix the problem, but would alleviate player frustration.
Searching for "a roboport closer to the target" might be very expensive if the game engine isn't optimised to provide that information - it might involve searching all roboports or similar.
Picking a roboport smartly would also have this problem.
The reason I selected my prefered option was that it could use already existing code with (hopefully) relatively minimal changes, as the only roboport search it would need to perform is the one it can do right now anyway. If this search is fast and easily used (two big assumptions), then looking further along the path for a roboport to charge at would always get it closer, even if doing so slowly, and would roughly minimise time spent crawling - this would hopefully involve fairly minimal code changes... hopefully. My preferred option was only selected to try and minimise the additional code required by needing little more than a while loop around the "find a roboport to charge at" code.
To illustrate, the original suggestion changes the code to be:

Code: Select all

When setting off from a roboport:
	if target dist > range*0.8
		target_pos = position + 0.8*range
		port = find_closest_roboport(target_pos)
		robot.trying_to_charge = true
		robot.charge_destination = port

My edit is:

Code: Select all

When setting off from a roboport:
	if target dist > range*0.8
		proportion = 80%
		do
			target_pos = position + proportion*range
			port = find_closest_roboport(target_pos)
			proportion +=20%
		while(port == departing_port && range*(proportion-20%)<target dist); 
		// honestly the "-20%" is in theory unessesary, but is there to preserve the check
		
		if(port == departing_port) 
			send alert, or if possible go straight to target, or something
		else
			robot.trying_to_charge = true
			robot.charge_destination = port

Note that this requires no different a set of calls, so should (in theory - haha), be an easy thing to switch to.
With this approach, the search must always find a roboport, as there will always be a roboport close enough to the target for the target to be in range (unless modded roboports provide a range larger than the drones can travel - that would be complex, and I guess then you really would just go straight to target, or just send an alert - or crash and give a bug report to the mod owner. I don't care to be honest).

One concern I have about "raising an alert" is that it sounds like the kind of thing that might be surprisingly hard to do from within the code - like you'd be on the wrong level. I might be wrong, but it worries me. I'm also concerned about having "go straight to target despite running out of charge" as a fallback, as it would involve having additional state in the robots, which could get very difficult to manage intelligently - the advantage of the original suggestion (and to a lesser extent my add-on) is that it involves no additional state or computation, so everything can be done by changing a few functions, rather than a massive re-factor.

[mrvn]

If you don't want to add a new "go there anyway" state then as you say a roboport must be in range of the target so you could always set that as recharge target.

I would really love to get the alert though.

[BicycleEater]

as you say a roboport must be in range of the target so you could always set that as recharge target

Ah, in almost all cases - there is the potential for a mod to create a really inefficient robot going from a super wide-range roboport to a very remote target. Then the bot literally cannot reach the target without crawling at least some of the way.
But to be honest I don't mind that case being somewhat broken, because the mod has clearly created a situation in which the game assumptions break down.
(I've modded this game enough to know that there is at least 1 mod which breaks any given assumption).

[ssilk]

PS: coordinates are int and speed and charge doubles, right?

AFAIK both must be double, because you can place entities very precise.

And now I have been in holidays and time to read all again. And I admit, I have posted some stupid stuff.

But I found the gap.

I played a bit around with pen and paper and for me this algorithm looks like it can really work, but sometimes — for the player out of nothing — it makes really horrible stupid things. E.g. it could be everything works well, then she/he places a new chest at a point where already 10 chests had been placed. Or just a new roboport. And this was one tile too much distance, now another roboport is more near to the target, and now the new path is through biter-land.

The player cannot foresee that. At least on my paper I wasn’t able to see, which path the bot will take. The player needs to measure out, what happens. But it’s not possible to see with the naked eye what will happen, when I put this roboport there.

And that’s the point. So stupid this current behavior of the bots currently is: it is very foreseeable. This proposal creates bots behavior, which is not foreseeable. Which is not good.

Well, we can discuss what “foreseeable behavior” means. For me it’s “I look at things and know what might happen”. Try it out with pen and paper as me, I was really surprised what routes the bots take.

[mrvn]

PS: coordinates are int and speed and charge doubles, right?

AFAIK both must be double, because you can place entities very precise.

And now I have been in holidays and time to read all again. And I admit, I have posted some stupid stuff.

But I found the gap.

I played a bit around with pen and paper and for me this algorithm looks like it can really work, but sometimes — for the player out of nothing — it makes really horrible stupid things. E.g. it could be everything works well, then she/he places a new chest at a point where already 10 chests had been placed. Or just a new roboport. And this was one tile too much distance, now another roboport is more near to the target, and now the new path is through biter-land.

The player cannot foresee that. At least on my paper I wasn’t able to see, which path the bot will take. The player needs to measure out, what happens. But it’s not possible to see with the naked eye what will happen, when I put this roboport there.

And that’s the point. So stupid this current behavior of the bots currently is: it is very foreseeable. This proposal creates bots behavior, which is not foreseeable. Which is not good.

Well, we can discuss what “foreseeable behavior” means. For me it’s “I look at things and know what might happen”. Try it out with pen and paper as me, I was really surprised what routes the bots take.

You must still be missing something.

You say the current behavior is forseeable. So you know which bot will go which way. Where it will run out of fuel. Which roboport it will choose to recharge. And the whole path is known.

Assuming you aren't actively placing roboports to mess with it this algorithm only changes one thing: It cuts the corner of the path to recharge. So instead of going A to out-of-fuel to B it goes directly A to B. It only takes the out-of-fuel point out of the equation. So since A and B are known by you the path with the new algorithm remains known. The proposed algorithm does not change what roboport to pick for B as it uses the exact same function and data (just earlier in time) to find B.

And even when you do place roboports you just have to remember that the new way chooses the next bit of the path a bit earlier. As in you already know which bots are on their way to recharge and will ignore your new roboport till they have recharged. Nothing unpredictable there.

Placing a new chest also changes nothing. The bot currently will fly till it is 1 tile from the new chest, run out of fuel, pick a roboport to recharge and go there. The proposed algorithm picks the same roboport to recharge and just goes there straight instead of zig-zag.

It is true that this direct course might lead the bot into alien territory. But that is totally forseeable, assuming the old course was forseeable. Just take the out-of-fuel point out of the path and you have the new path.

Note: The proposed algorithm should actually save bots in a lot of cases. I would say it's more likely to save bots than harm them with the new paths. Assume the blue area in the OP is alien infested territory. Currently the bots will venture into the alien territory and get shot down. With the proposed algorithm they would go from roboport to roboport around the aliens and only skirt the edges a bit. Doesn't always work but anything that currently doesn't cut directly across the aliens will go around it more than before.

[BicycleEater]

Note: The proposed algorithm should actually save bots in a lot of cases. I would say it's more likely to save bots than harm them with the new paths. Assume the blue area in the OP is alien infested territory. Currently the bots will venture into the alien territory and get shot down. With the proposed algorithm they would go from roboport to roboport around the aliens and only skirt the edges a bit. Doesn't always work but anything that currently doesn't cut directly across the aliens will go around it more than before.

Completely agree with that.
To be honest I find the current behaviour very unintuitive, as I naturally plan the inter-roboport routes, but forget about the bots just randomly wandering in the vague direction of the target, no matter what lies in their way.

[ssilk]

Assuming you aren't actively placing roboports to mess with it this algorithm [...]

And even when you do place roboports you just have to remember that the new way chooses the next bit of the path a bit earlier.
As in you already know which bots are on their way to recharge and will ignore your new roboport till they have recharged. Nothing unpredictable there.

You always place new roboports. And one "badly placed" can send your robots to hell, because they now take the "shorter" path over the biters. You can't see it beforehand, because you're on the other side of this gap in your base and think to a completly different problem. And you don't see that change immediately, because they change their path with the next transport.

But OK, I admit that would be easy to fix by either removing that roboport or placing another roboport, that "shows the right way".

Maybe I used the wrong word. Instead of "unpredictable" use "immediately understand what will happen when I do this".

Hm. This changed setup has something of laying out breadcrumbs for ants and they follow that new path only after they have eaten the old breadcrumbs.

Placing a new chest also changes nothing. The bot currently will fly till it is 1 tile from the new chest, run out of fuel, pick a roboport to recharge and go there. The proposed algorithm picks the same roboport to recharge and just goes there straight instead of zig-zag.

It looks easy, but it isn't.
The robots come, pick up the items and fly to the next roboport. Assume you have laid out two storage chests. The storage chest 1 is more near to roboport A, storage chest 2 it more near to roboport B. Unforseeable - as human you cannot see, which roboport is more near when the distance is - let's say - more than 10 tiles. You need some new tool, something that let you see the diffference, that you will see, which is the next roboport for chest 2.

And this goes further: Assume chest 1 and 2 are currently next roboport is A. Now you're placing roboport B and now this is the same situation, that 1 flies to A and 2 flies to B. Not very predictable, especially with larger distances you miss, that there is an already existing path.

The current algorithm to calculate the nearest distance to a roboport takes the number of robots waiting for recharge into account. The distance rises with the number of robots waiting. So with more and more robots, this will make everything unforeseeable. Well. Not that it changes much compared to now. Just want to say that again and to make it complete: As you currently can easy predict in which direction robots fly, when targeting to a new destination, this new behaviour will change that.

I don't say it's bad or good. I cannot tell, if it is better. This is too complex (*), we cannot overlook the change. We need to try it out, need to switch between both behaviours. Test it. I will not further discuss this, because without any evidence this discussion makes no more sense.

Note: The proposed algorithm should actually save bots in a lot of cases. I would say it's more likely to save bots than harm them with the new paths. Assume the blue area in the OP is alien infested territory. Currently the bots will venture into the alien territory and get shot down. With the proposed algorithm they would go from roboport to roboport around the aliens and only skirt the edges a bit. Doesn't always work but anything that currently doesn't cut directly across the aliens will go around it more than before.

I'm not against this suggestion, not saying it's a bad idea! I say t's not completely thought through yet (because it's complex behaviour, which can't be thought through). I repeat: It can't be thought through, because you replace one complex behaviour with another even more complex. We need to try it out.

And with this suggestion I thought when trying it out on paper: I specially miss that I can clearly see, which path is now shorter if I place this roboport, especially with longer distances. Currently this is a no-brainer (="more foreseeable", sorry for not using the right word for this, i have no better, maybe "easier to understand what will happen"). But of course it lacks some kind of more control, because it's just not possible to make a path around a lake or biter manifestation. I take this thought again into the race: There is no need to completely change the algorithm. All what's needed is that I as player can say "No, don't take this way, take this".

(BTW I made a suggestion into that direction: viewtopic.php?p=573680#p573680 at the end "A better idea?". )

So to conclude a bit after this long post: With this new behaviour this looks somehow easier, but it isn't when you look one level deeper. Or a bit simpler: You will not be able to tell me which path a robot will take, when you look at one of my maps. And of course you can't tell it now. But when I compare both systems, I would say - as far as I can tell with my paper drawings - the current is more predictable.

As said, I mean you need something that displays this, which depends also from how many robots are currently flying around. But I have no good idea how to display that, because you always need two points (source and destination) and how occupied the roboports are.



(*) With "complex" I mean that the system you are looking into influences it's own behaviour.
I don't mean complicated. That's different.
Complicated: The one way streets in Rome.
Complex: If the one way streets in Rome change at any time because of too much traffic.

The system incfluences it's own behavior, this is here the case, because the number of bots waiting at a roboport influences the calculated distance of the roboports. It's a known fact of complex systems, that you can't know, how they behave. You can only change something and look how the system reacts to this change; and try to simplify the complexity, so that the complex system becomes just a complicated, see for example https://improvingwetware.com/2019/03/17 ... hodologies

[BicycleEater]

...

Yeah, what you are saying makes a lot of sense, my only objection is that I don't tend to plan my bot routes out, I just expect them to work, which they mostly do, with a few exceptions, all of which are due to me assuming that they'll follow the trail of roboports rather than bee-lining it. I get that bee-lining is more easily worked out on paper, but to me following the breadcrumbs seems more... natural.
It would be the behaviour I would assume the bots would take if I didn't actually know how they worked.
I think the difference between 'predictable' and 'intuitive' has also caused some misunderstandings. To clarify, 'predictable' means that someone sitting down could work out what exactly will happen, and I agree that the current system is very predictable. 'Intuitive' means that - roughly speaking - things happen how one might naively expect. This is more a new-player thing, and specifically doesn't require you to work out exactly what will happen.
I think intuitive is more important in this instance, as you very seldom watch exactly what a robot is doing as it takes off. What you do watch is them getting stuck in a lake.
I do value the predictability of Factorio, but the current system isn't predictable anyway, as any unknowns in the proposed system would be unknown in the current system (as the robots would visit all the same ports), and since the proposed system is still calculable, with largely the same methods, I feel the tradeoff is worth it.

In that way, while the change makes the behaviour more complex, I think it would make it more intuitive. I understand that this is very subjective though, and completely agree that actual experimentation is needed. The problem is that the game engine really doesn't support this kind of thing at the minute, so my attempts to build an exploratory mod were ultimately doomed (or would take waaaaay more effort than I'm willing to expend).

I don't think the proposed changes are the best possible solution to robot routing - I'd far rather have a route planner, or even a way of specifying robot highways.
However, they do solve the very common problem of all your robots getting stuck over a lake, and so not being able to deliver nuclear fuel rods, a fact you find out only after the power dies.
That kind of thing annoys everyone who plays with bots, and this proposal has relatively little performance impact, and hopefully little dev time required, as the change is code-wise simple.

[ssilk]

In that way, while the change makes the behaviour more complex, I think it would make it more intuitive. I understand that this is very subjective though, and completely agree that actual experimentation is needed. The problem is that the game engine really doesn't support this kind of thing at the minute, so my attempts to build an exploratory mod were ultimately doomed (or would take waaaaay more effort than I'm willing to expend).

Like the differentiation you made between intuitive and complex. Yeah, this is more complex and might be eventually more intuitive. Which is - when it is really like so - a good thing, because that improves the gameplay in a way, that Factorio likes to go. But - as you might know - intuition is, what is a bad adviser when we speak about complex problems. You really need to test it.

And speaking of tests means here to write a mod, that may handle this. I mean it's eventually quite simple to test with a mod:
- you need to configure, that a robot is in the recharge-mode (searching for a roboport).
- But it should not find the current roboport it is coming from.

The first is simple, just some config of the prototype, the second might be simulated by having thousands of robots waiting for recharge at the first roboport. It makes the distance so big, that it take automatically the next roboport.

This would be just enough to make first tests with it.

I don't think the proposed changes are the best possible solution to robot routing - I'd far rather have a route planner, or even a way of specifying robot highways.
However, they do solve the very common problem of all your robots getting stuck over a lake, and so not being able to deliver nuclear fuel rods, a fact you find out only after the power dies.
That kind of thing annoys everyone who plays with bots, and this proposal has relatively little performance impact, and hopefully little dev time required, as the change is code-wise simple.

But that wrong-delivery-over-a-lake-problem is a much more simple problem, than the solution proposed here. To solve that problem we can do other things, like having a fourth transport system that delivers efficient small amounts over longs distances. (I think there was also the idea of using rockets for that, but I didn't find the thread for that).

[mrvn]

Assuming you aren't actively placing roboports to mess with it this algorithm [...]

And even when you do place roboports you just have to remember that the new way chooses the next bit of the path a bit earlier.
As in you already know which bots are on their way to recharge and will ignore your new roboport till they have recharged. Nothing unpredictable there.

You always place new roboports. And one "badly placed" can send your robots to hell, because they now take the "shorter" path over the biters. You can't see it beforehand, because you're on the other side of this gap in your base and think to a completly different problem. And you don't see that change immediately, because they change their path with the next transport.

But OK, I admit that would be easy to fix by either removing that roboport or placing another roboport, that "shows the right way".

Maybe I used the wrong word. Instead of "unpredictable" use "immediately understand what will happen when I do this".

Hm. This changed setup has something of laying out breadcrumbs for ants and they follow that new path only after they have eaten the old breadcrumbs.

Yes, the proposed algorithm adds a bit of a delay for a new roboport to get used for charging, one recharge cycle at most.

From my experience the current bot behavior isn't predictable already. You never know where bots come from to pick something up and where they will deliver it changes a lot too. Even if you know all your belt production is way down south and bots will therefore come from the south and not fly over aliens as you expand north there might be some belts in a storage chest in the west and suddenly 1000 bots fly over an alien nest an die one after the other till the storage chest is empty.

If you have a convex logistic network with aliens in the caves then bots die. I think we just have to accept that and move on.

Placing a new chest also changes nothing. The bot currently will fly till it is 1 tile from the new chest, run out of fuel, pick a roboport to recharge and go there. The proposed algorithm picks the same roboport to recharge and just goes there straight instead of zig-zag.

It looks easy, but it isn't.
The robots come, pick up the items and fly to the next roboport. Assume you have laid out two storage chests. The storage chest 1 is more near to roboport A, storage chest 2 it more near to roboport B. Unforseeable - as human you cannot see, which roboport is more near when the distance is - let's say - more than 10 tiles. You need some new tool, something that let you see the diffference, that you will see, which is the next roboport for chest 2.

And this goes further: Assume chest 1 and 2 are currently next roboport is A. Now you're placing roboport B and now this is the same situation, that 1 flies to A and 2 flies to B. Not very predictable, especially with larger distances you miss, that there is an already existing path.

The current algorithm to calculate the nearest distance to a roboport takes the number of robots waiting for recharge into account. The distance rises with the number of robots waiting. So with more and more robots, this will make everything unforeseeable. Well. Not that it changes much compared to now. Just want to say that again and to make it complete: As you currently can easy predict in which direction robots fly, when targeting to a new destination, this new behaviour will change that.

I don't say it's bad or good. I cannot tell, if it is better. This is too complex (*), we cannot overlook the change. We need to try it out, need to switch between both behaviours. Test it. I will not further discuss this, because without any evidence this discussion makes no more sense.

Except the old algorithm would have the bots already fly to A and B and you said that is predictable. That makes the new behavior, which picks identical roboports to recharge, just as predictable.

The only point I see in there is about number of bots waiting to recharge. I don't know how that methods works apart from not very well in my opinion. But with the bots picking a recharge port earlier this will have more of a delay. And if only bots already at the roboport count then a lot of bots could target a roboport early because it is currently free only to end up with a huge waiting queue. On the other hand if the number of bots targeting the roboport is counted then it shouldn't change much.

But it's a complex system with lots of parts interacting. Predicting the emergent behavior is practically impossible. As you say "We need to try it out".

And with this suggestion I thought when trying it out on paper: I specially miss that I can clearly see, which path is now shorter if I place this roboport, especially with longer distances. Currently this is a no-brainer (="more foreseeable", sorry for not using the right word for this, i have no better, maybe "easier to understand what will happen"). But of course it lacks some kind of more control, because it's just not possible to make a path around a lake or biter manifestation. I take this thought again into the race: There is no need to completely change the algorithm. All what's needed is that I as player can say "No, don't take this way, take this".

I don't get how you can say this. If as you say the current behavior is a no-brainer then just draw in the current behavior. Now take all points where the robot runs out of fuel and instead of going zig-zag take the third side of the triangle and go directly. For me removing those out-of-fuel points on the path is a no-brainer both to calculate and to predict. So I simply fail to understand how you can say the proposed algorithm would be unpredictable. It's just a shortening of the path the bot would take now. That's kind of the point of the algorithm. It's doesn't change the points the robot picks or how. It just skips a few stupid points on the way.

[BicycleEater]

...

Like the differentiation you made between intuitive and complex. Yeah, this is more complex and might be eventually more intuitive. Which is - when it is really like so - a good thing, because that improves the gameplay in a way, that Factorio likes to go. But - as you might know - intuition is, what is a bad adviser when we speak about complex problems. You really need to test it.

Fair enough, it's just that it caught me by surprise when I first hit the bots-going-over-lake issue, it felt weird that the bots wouldn't 'just' follow the roboports.
I know how it works now, but it still catches me off guard.

And speaking of tests means here to write a mod, that may handle this. I mean it's eventually quite simple to test with a mod:
- you need to configure, that a robot is in the recharge-mode (searching for a roboport).
- But it should not find the current roboport it is coming from.

The first is simple, just some config of the prototype, the second might be simulated by having thousands of robots waiting for recharge at the first roboport. It makes the distance so big, that it take automatically the next roboport.

This would be just enough to make first tests with it.

That's true, but what I was really looking for was seeing if I could emulate the behaviour with a mod, which is, as far as I can tell, impossible.

But that wrong-delivery-over-a-lake-problem is a much more simple problem, than the solution proposed here. To solve that problem we can do other things, like having a fourth transport system that delivers efficient small amounts over longs distances. (I think there was also the idea of using rockets for that, but I didn't find the thread for that).

My point was that this solves the problem for all problems like that with drones, and is the system I use by default for small scale transport. It's also the system I use to build, etc. Making the robot networks more reliable in remote cases does that in one swoop, and I suspect requires minimal engine changes.
A new transport system requires quite a lot of work for the devs, where the entire point of this suggestion is to be minimalistic and confined, so that the devs can implement it without as much trouble.
Sure a fourth transport system would be cool, but it would be a whole new system in the game. Its also hard to set up any other transport system to go a huge distance to my nuclear reactor setup, whereas the entire point of robots is to be low-volume easy-to-use, which is exactly what I wanted in this situation.
The problem is that I usually just expect the logistic network to work, without needing to really pay much attention - which is kinda how it should be.

[mrvn]

But that wrong-delivery-over-a-lake-problem is a much more simple problem, than the solution proposed here. To solve that problem we can do other things, like having a fourth transport system that delivers efficient small amounts over longs distances. (I think there was also the idea of using rockets for that, but I didn't find the thread for that).

I have an open feature request to allow rockets to land on a silo. This would allow mods to add rockets as transport system.

[ssilk]

You never know where bots come from to pick something up and where they will deliver it changes a lot too.

This is not correct. When you watch single bots over longs distances, when there is not much traffic, then they will go always the same path. As with this suggestion, the current behaviour is quite simple to predict.

In the current system this changes with growing traffic. When more bots charge at one roboport a bot will suddenly take a different roboport. The same is it with this suggestion, with the difference, that it is much more unpredictable, because the bots can spread much more over the ports, because once a bot took a new path it can end completely unpredictable in nirwana (dead end, no path out). This unpredictable dead ends cannot happen in this way with the current system.

Even if you know all your belt production is way down south and bots will therefore come from the south and not fly over aliens as you expand north there might be some belts in a storage chest in the west and suddenly 1000 bots fly over an alien nest an die one after the other till the storage chest is empty.

One can argue, that this behaviour is a (evil ) part of the game. But there is a simple rule: Avoid concave networks, if you want to use bots safely. But that's not my opinion. My opinion is that the current system works very well for how less CPU-cycles are used to make it more or less intelligent. But it has some quirks and we don't need to fix the whole system to fix these 2 or 3 sometimes annoying problems.

In other words: This suggestion will make the system not simpler (see down why). This suggestion makes it even more complex to handle.

If you have a convex logistic network with aliens in the caves then bots die. I think we just have to accept that and move on.

We already had arguments (*) in older suggestion threads, that one just needs to avoid convex networks (bases). This is in most cases relatively simple. In some not. Then it can be seen as a kind of puzzle. Sometimes I like it, sometimes not. The point is: is can be predicted.

The only point I see in there is about number of bots waiting to recharge. I don't know how that methods works apart from not very well in my opinion. But with the bots picking a recharge port earlier this will have more of a delay. And if only bots already at the roboport count then a lot of bots could target a roboport early because it is currently free only to end up with a huge waiting queue. On the other hand if the number of bots targeting the roboport is counted then it shouldn't change much.

Currently the robot is counted, when it arrives at the roboport. You cannot "make a reservation"! Because things can change: E.g. an empty robot is on the way home to the next roboport. But before it arrives it gets new orders. One case of many.

As you say "We need to try it out".

But still not giving up, eh?

And with this suggestion I thought when trying it out on paper: I specially miss that I can clearly see, which path is now shorter if I place this roboport, especially with longer distances. Currently this is a no-brainer (="more foreseeable", sorry for not using the right word for this, i have no better, maybe "easier to understand what will happen"). But of course it lacks some kind of more control, because it's just not possible to make a path around a lake or biter manifestation. I take this thought again into the race: There is no need to completely change the algorithm. All what's needed is that I as player can say "No, don't take this way, take this".

I don't get how you can say this. If as you say the current behavior is a no-brainer then just draw in the current behavior.

Hm. I didn't explain that well. What I meant is: Less complex -> less brain needed. Not that it is "obviously" so simple, that one must understand the superiority of this suggestion.

Now take all points where the robot runs out of fuel and instead of going zig-zag take the third side of the triangle and go directly. For me removing those out-of-fuel points on the path is a no-brainer

But you're looking again only to this one aspect of their behaviour: Bots do stupid things, because they go straight and need to refuel in zigzag.

Did you think for example about what will happen when the bots are upgraded by research and suddenly go faster, so that they now can fly longer. With that the this system of "make a path for your bots via roboports" changes from one moment to the other to bullshit. Bots will suddenly make completely new paths.

And suddenly your formerly well designed path around of your "convex edge" is useless, just because you researched an upgrade for robots.

... and complexity means, there might be much more of those cases; we cannot know what they are and how many.

BTW: The current system will also change with more bot-speed, but not in a way, that is so unpredictable. AFAIK nobody has ever complained about it. But I can guarantee you, with this proposed system they will.

[... That is a no-brainer ...] both to calculate and to predict.

No, not even close.

So I simply fail to understand how you can say the proposed algorithm would be unpredictable. It's just a shortening of the path the bot would take now. That's kind of the point of the algorithm. It's doesn't change the points the robot picks or how. It just skips a few stupid points on the way.

I keep on it unless you explain me the opposite: This suggestion replaces an already complex system, with one that is one or two categories more complex. You might not see that yet. But you can trust me; seeing such things is part of my daily job as developer. Most times I just ask then simple questions like: what will happen when you do this and that at the same time And then they see this ain't gonna work.

Off-topic:
Reducing complexity to see how a system works is a super important part of such a design process, and wube's developer, especially Kovarex, is a master in this. Also the reason why I still like to be kind of "main moderator" for ideas&suggestions. Because people tend to make complex things, because they think doing many things at once is simpler. But that is only true, if look for one aspect and often they forget to look at the whole story.


(*) Threads about convex networks
viewtopic.php?f=71&t=41428&p=386401&hil ... ex#p386401
viewtopic.php?f=6&t=12859&p=126490&hilit=convex#p126490
viewtopic.php?f=6&t=28614&p=182162&hilit=convex#p182162

[BicycleEater]

I've tried to avoid getting into this as an argument, as you said, its not very helpful, what we really need is a word from the devs on this suggestion, as it is much more viable than most others - I'd love to see at least an attempt, even if it turns out to be too problematic in ways I can't see.

In the current system this changes with growing traffic. When more bots charge at one roboport a bot will suddenly take a different roboport. The same is it with this suggestion, with the difference, that it is much more unpredictable, because the bots can spread much more over the ports, because once a bot took a new path it can end completely unpredictable in nirwana (dead end, no path out). This unpredictable dead ends cannot happen in this way with the current system.

How can the bots spread out more than currently? I don't see how that applies. I can see how they'd spread out more quickly than currently, as they'd be taking shortcuts, but that doesn't change the extend to which the bots spread out amongst roboports. Also, them spreading out is pretty much a good thing. The only situation where it would spread out more is when robots are 'stuck', and then spreading out is the only way to get to the target anyway.

But there is a simple rule: Avoid concave networks, if you want to use bots safely. But that's not my opinion. My opinion is that the current system works very well for how less CPU-cycles are used to make it more or less intelligent. But it has some quirks and we don't need to fix the whole system to fix these 2 or 3 sometimes annoying problems.

The point of the suggestion is that it doesn't alter that much, it doesn't cost any more CPU cycles (in theory), and produces better behaviour in most cases it applies in. I don't see how this criticism applies.

In other words: This suggestion will make the system not simpler (see down why). This suggestion makes it even more complex to handle.

For who, and in what way? You are using the 'complexity' of the system as a cover-all criticism for improving it. Nobody ever said it would be simpler to analyse, it was only pointed out that it was easier for the player to use, producing fewer obscure problems.

We already had arguments (*) in older suggestion threads, that one just needs to avoid convex networks (bases). This is in most cases relatively simple. In some not. Then it can be seen as a kind of puzzle. Sometimes I like it, sometimes not. The point is: is can be predicted.

But this system can be predicted. I mean a wiki page would suffice for anyone who wants the details, but in most cases it would just work, and do so with far fewer players wondering "why did all my drones just die?"
As far as I can tell it isn't a fun puzzle, its just an annoying limitation of your primary late game building system.

As you say "We need to try it out".

But still not giving up, eh?

Its a really good change, it makes sense, and I think it has a decent chance to be implemented - at least more than most robot routing improvements.
I will still support this, as I don't see any really meaningful objections to the changes.

Now take all points where the robot runs out of fuel and instead of going zig-zag take the third side of the triangle and go directly. For me removing those out-of-fuel points on the path is a no-brainer

But you're looking again only to this one aspect of their behaviour: Bots do stupid things, because they go straight and need to refuel in zigzag.

This is the only aspect of behaviour being looked at because this is the only aspect of behaviour that is relevant. Its like the whole point of the change...
And yeah, "Bots do stupid things" is a bad thing, and what the suggestion is trying to change.

Did you think for example about what will happen when the bots are upgraded by research and suddenly go faster, so that they now can fly longer. With that the this system of "make a path for your bots via roboports" changes from one moment to the other to bullshit. Bots will suddenly make completely new paths.

Yeah, the path isn't pre-planned, only instantaneous - no bot would have a route, only a roboport its trying to recharge at. Upgrading the bots would result in the current recharges being a little wasteful, but would still work perfectly well.
Do you think this is another "path finding for bots" suggestion, because its really not. It is basically doing nothing more than corner cutting. Those corners remain just as cut at higher speeds.

And suddenly your formerly well designed path around of your "convex edge" is useless, just because you researched an upgrade for robots.

... and complexity means, there might be much more of those cases; we cannot know what they are and how many.

There isn't a path around the edge. Only a roboport to recharge at...
And complexity doesn't mean that - it makes a system hard to analyse, and may require approximations, but we can certainly constrain potential problems.

BTW: The current system will also change with more bot-speed, but not in a way, that is so unpredictable. AFAIK nobody has ever complained about it. But I can guarantee you, with this proposed system they will.

No, no it will not. It will not need any special handlers for bot-speed that I can think of. The pre-calculated stuff is still just as calculated.

[... That is a no-brainer ...] both to calculate and to predict.

No, not even close.

How so?

I keep on it unless you explain me the opposite: This suggestion replaces an already complex system, with one that is one or two categories more complex. You might not see that yet. But you can trust me; seeing such things is part of my daily job as developer. Most times I just ask then simple questions like: what will happen when you do this and that at the same time And then they see this ain't gonna work.

I do plenty of dev stuff as well, and this is not noticeably more complex. The system looks ahead, and sets a flag and a pointer, and leaves. Then, if anything changes further down the line, it does whatever it would do now. That is all.
The prediction is only done when a bot finishes charging, or when it first sets off.
I challenge you to think of any single situation where the result isn't pretty much obvious - or if it isn't, the result is just as non-obvious right now.

Off-topic:
Reducing complexity to see how a system works is a super important part of such a design process, and wube's developer, especially Kovarex, is a master in this. Also the reason why I still like to be kind of "main moderator" for ideas&suggestions. Because people tend to make complex things, because they think doing many things at once is simpler. But that is only true, if look for one aspect and often they forget to look at the whole story.

Yeah, it is important, but it isn't the only thing that is important, and again, this system doesn't add anything which isn't already there.

I really don't understand your position on this, so to make sure we are on the same page, could you explain what the proposed system does which is so complex, and a situation where the game wouldn't fall back to the current entity handling?
I can see concerns around testing it thoroughly, but it is certainly doable.

My understanding is:
The only change this suggestion involves is that when and only when a bot leaves a roboport or finishes charging, it will find the direction and distance to the target, if the distance is within 80% of range, then nothing special happens. Otherwise, it will ask the roboport network for the best roboport from 80% charge dist in that direction, set the bot.isRecharging = true, bot.chargingRoboport = roboport, and that is it.
From that point onwards, everything happens as it does in base-game.


When considering the mass action of drones, I believe this change will do almost nothing, except for making the drones waste less time.
The obvious edge case is when a drone finds its departure roboport as the closest, but this issue has been addressed multiple times, and any of those solutions is fine.

[mrvn]

Now take all points where the robot runs out of fuel and instead of going zig-zag take the third side of the triangle and go directly. For me removing those out-of-fuel points on the path is a no-brainer

But you're looking again only to this one aspect of their behaviour: Bots do stupid things, because they go straight and need to refuel in zigzag.

Did you think for example about what will happen when the bots are upgraded by research and suddenly go faster, so that they now can fly longer. With that the this system of "make a path for your bots via roboports" changes from one moment to the other to bullshit. Bots will suddenly make completely new paths.

And suddenly your formerly well designed path around of your "convex edge" is useless, just because you researched an upgrade for robots.

... and complexity means, there might be much more of those cases; we cannot know what they are and how many.

BTW: The current system will also change with more bot-speed, but not in a way, that is so unpredictable. AFAIK nobody has ever complained about it. But I can guarantee you, with this proposed system they will.

In both cases any change in the robots charge or speed will change how they behave. The zig-zag will get bigger with the old behavior, the bots will choose different roboport to recharge and so will the new algorithm. But apart from right around the time when you get the new research the behavior change will be the same. In the old case bots will suddenly be able to cross over a U section without recharge then they will do so too with the proposed algorithm. It just won't happen for bots already on the way, a purely temporary problem. If you have a path around a convex edge a larger speed or charge means the bots will cut across the edge more just like the zig-zags would get bigger and reach more into the convex shape.

My point is this: Unless you have a strange case where the rechrage roboport is closer to the convex region than your target (i.e. for the very last leg of the path this can happen) then the proposed algorithm will reduce the incursion into the convex part. So generally it will reduce the exposure of the bots. But that is really just a side effect I predict will emerge. It's not a goal of the proposal and you should not "route" bots around a convex shape. That simply doesn't work well, old or proposed algorithm. If you have a convex shape then bots will intrude into the middle.

[... That is a no-brainer ...] both to calculate and to predict.

No, not even close.

So I simply fail to understand how you can say the proposed algorithm would be unpredictable. It's just a shortening of the path the bot would take now. That's kind of the point of the algorithm. It's doesn't change the points the robot picks or how. It just skips a few stupid points on the way.

I keep on it unless you explain me the opposite: This suggestion replaces an already complex system, with one that is one or two categories more complex. You might not see that yet. But you can trust me; seeing such things is part of my daily job as developer. Most times I just ask then simple questions like: what will happen when you do this and that at the same time And then they see this ain't gonna work.

And there we just have to agree to disagree then. For any given path the current algorithm results in I can trivially show you the new path. Programatically it's the same code just run at different times. So as programmer I see the same complexity, i.e. it won't cost more UPS.

In the other hand for simple players I think the resulting path will be much more what people expect. It's what they would do if they where flying the robot. It just takes away a bit of the stupid. Not all the stupid, just a bit.

Hardcore players might try to predict or compute what exactly the bot behavior will be when they place a roboport at (x, y) or (x+1, y). But as shown computing the new behavior with the proposed algorithm is barely more complex than the old one, you just eliminate the zig-zags. So even then I would hardly call that "one or two categories more complex". But that's an opinion. I find the behavior of a single bot easy to predict with both algorithms.


The part that I find unpredictable and that will change is the finding of a robobort "with few bots waiting" part. If there are no reservations, as you say, then the proposed solution might have a major effect on this. That's the part where the interaction of all the bots matter and cause an emergent effect that's hard to impossible to predict. That's the part we just have to try out I think. I already find the current algorithm unpredictable there.

The proposed algorithm affects long distance travels, in which case you normally have single roboports in some form of grid and the bots will always only have one roboport to choose for recharging anyway. The previous or next roboport is so far away that it won't be choosen no matter how many bots are already waiting for recharge. At least that's how it seems to me in the game.

On the other hand if you have something like a train station with bots where you place 10 roboports in a cluster then they spread out nicely to recharge. But then they also don't have such long distances to travel to recharge so the time difference between picking a roboport for recharge and arriving will be tiny and they should still spread. Maybe they will spread a little less. Or a lot less. It's hard to predict. Even a little delay could drastically change the emergent behavior but I would predict the effect is negible for a bot based train station.

What I think could really break is when you add clusters of roboports to a long distance travel. Currently when you have for example 2 outposts you can place roboports between them in clusters at all the places the bots will recharge and they will spread out. If the bots travel in waves then the proposed algorithm would break that because the whole wave would start at e.g. a provider chest and then all pick the same roboport as next recharge station and never spread out. If it's not in waves then it should be fine. But construction bots often travel in waves, like when you blueprint a new solar farm and 1000 bots all pick up solar cells at the same provider chest.

The proposed algorithm might need bots to "reserve" recharge spots to keep the bots working like they do now for those special kind of bot networks. Programatically that should be trivial too. Just increase a counter when the bot picks the port a recharge target instead of using the length of the bots_waiting_to_recharge list to pick a port. Hard to predict if it is needed or not.

PS: What I see often is that I place a big blueprint. 1000 bots pick up solar pannels, fly till they are out of charge and pick a robobort to recharge. Because they all have 0 waiting bots all the bots pick the same roboport and you get a huge traffic jam. Only for the 2nd, 3rd, ... recharge the bots spread out some. Because at that point they aren't all picking a roboport at the same time but one after another and do see bots waiting to recharge. So the not reserving a spot seems to already be a problem.