bot just hovers above roboport for no reason

[Moosfet]

I made a video:

hoverbot.mp4

(6.71 MiB) Downloaded 92 times

I wish I had included the cursor since without it, it's not obvious when I'm mining the bot, but basically the game always wants a hovering bot it seems. If I mine the hovering bot, a new one pops out of the roboport and just hovers above it. If I place a new bot, the one above the roboport goes back inside. If I place another bot, if it's further away, the closer hovering bot goes into the roboport, but if it's closer, it goes into the roboport and the previous hovering bot remains in place.

This seems like a bug, but then, it also seems like a bug every time I see

Satisfaction: 0/100
On-the-way: 0
Logistic Storage: 1000

in the data on a requester chest in a network with a thousand idle bots.

Also, if it is a bug, I'm not sure how to go about reporting it. It's in a game that's been running for at least a month now, with a lot of mods (space exploration), and it isn't the latest experimental release, so IDK if the devs would even want the 32 MB save file to look at it.

Maybe there's some explanation for it and someone can fill me in.

[DaveMcW]

That is a construction bot. Check the construction alerts in the bottom right, is something missing materials?

[Moosfet]

Well, there were 11 solar panels that were missing material, and had been for days as I didn't care. I've never seen the bots hover like that before when they don't have materials though. Also, it looks like there were only 3 bots construction bots hovering, judging by the bot counts, though I don't know where the other two were. It's a huge bot network so too many places to search for it.

number_of_available.png (39.56 KiB) Viewed 3060 times

I removed the 11 ghost entities, which did nothing at first, but about 20 seconds later, the bot suddenly flew away. I don't know where it went or why, but afterwards, looking at the available/total count, it looked like one hovering bot still remained somewhere. I then gave the bots a bunch of stuff to do so I can't tell if any are still hovering by looking at the bot counts anymore.

Also, I don't think the hovering bot was assigned to any task. When ghost building near him, he'd actually fly off to get an item to place, come back and place it (or maybe a different bot came back), place the item, then just hover above it until he ran out of charge, at which point he'd go back to the roboport, recharge, then hover above the recharge point until he ran out of charge again.

[ColonelSandersLite]

That is a construction bot. Check the construction alerts in the bottom right, is something missing materials?

Even if there is, that suggests a bug. Con bots aren't supposed to launch until they have a job *and* can reserve the materials to do the job. Looks to me like the bot thinks there's no available spots to land but there clearly is.


Edit - I misread part of the OP and this doesn't actually apply.

Pretty sure this isn't supposed to happen either.

[quote=Moosfet post_id=575094 time=1664631204 user_id=21685]
Satisfaction: 0/100
On-the-way: 0
Logistic Storage: 1000
[/quote]



I'm inclined to think that this is a mod issue as I haven't experienced behaviors like that before.


So, here's my shot in the dark wild ass guess -
Every roboport network is supposed to have a unique ID. We can get this id but in normal play, it's pretty much useless information. I expect that this ID is used extensively internally by the game engine though.

You're using mods that run multiple game surfaces in parallel. I have a sneaking suspicion that the uniqueness of these network IDs was somehow not enforced in this particular situation. It would be a PITA but I would start by attempting to make sure that this is or isn't the case.

[FuryoftheStars]

I don't know if this is your situation or not, but the only time I've seen bots do that is when they're out of space in the roboports to land/fit in.

[ColonelSandersLite]

I don't know if this is your situation or not, but the only time I've seen bots do that is when they're out of space in the roboports to land/fit in.

Yeah, that's what I thought at first too. It's not the case here though. At the very start of the video file, there's a hovering robot. Player adds a new robot to the network and the new robot immediately goes and lands but the hovering bot just keeps on hovering.

[Moosfet]

Satisfaction: 0/100
On-the-way: 0
Logistic Storage: 1000

I'm inclined to think that this is a mod issue as I haven't experienced behaviors like that before.

It's actually not a bug and happens with the vanilla game. The 1000 items in logistic storage are in buffer chests, and so the bots aren't willing to deliver them because they're reserved for construction or player requests.

I really don't understand how buffer chests are supposed to be useful. Now and then I try to use them to keep materials closer to where they'll be needed, and then an hour later I run into this problem and 15 minutes after that, when I figure out that this isn't a bug, I remember why I never use buffer chests. (I have kind of bad memory so after I don't play for a year, I forget that this happens and have to figure it out all over again.)

I can only guess that the devs play differently, perhaps by using space-limited provider chests such that there will always be items in provider chests, but I like to connect inserters that put items into provider chests to the logistic network so that they don't pick up items that the network doesn't need. So, for example, I might decide I need 1000 laser turrets at most, so configure the inserter that picks them up to not pick them up if the network already has 1000 for some reason, like, say I blueprint something with a bunch of turrents, so they all come out of the provider chest, and then decide I don't want it, so I control-Z it. Those turrets go into storage, but even though the provider chest is now empty, no more get made, since there's 1000 in storage. ...but then I have some far-away defense walls and decide to put buffer chests near them so that turrets can get replaced faster, and then an hour later I find that some recipes aren't getting made because machines need laser turrets as an input item, but the requester chest isn't getting any, because there's already 1000 of them in buffer chests and so that inserter isn't picking up any more of them. I suppose this problem would go away if I just used a space-limited provider chest and let it make too many laser turrents in these rare situations (since usually it'll use the storage first, so the provider won't empty until the storage is empty), but, IDK, it's just how I've always done it. It does work better if I copy & paste to make more machines that produce something. Say I only want 50 so I make one slot open in that provider chest, but then I copy and paste it 9 times. Now I'm making 500, whereas if I had used the network condition on the inserter instead of relying on space-limiting the provider chests, I'd still only make up to 50 of them.

I suppose buffer chests might also work for me if I just checked the "request from buffer chests" checkbox on every requester chest I place, but I'm not about to start doing that. It would create a lot of senseless back-and-forth movement of items, as the bots primarily deliver them to the far-away buffer chests and then bring them back to the requester chests, and I'd forget to check the box sometimes, and so it's easier to just never use buffer chests. Indeed, I'm not sure why that option is even there. It seems like someone encountered my problem here, tried to solve it with that checkbox, and then kind of just abandoned the whole idea of buffer chests and left them in this not-really-useful state when that didn't work.

I really wish the logistic network didn't count the inventory of buffer chests. Indeed, I think that instead of reporting this number:

Code: Select all

N = (quantity in storage, provider, and buffer chests) - (quantity to be picked up by a bot)

It should just report this:

Code: Select all

N = (quantity in storage or provider chests) - (outstanding requests in requester or buffer chests)

I'm usually more interested in how many items the network wants than how many it has. When I'm looking at how many it has, usually I'm just using that as a proxy for how many it wants. Like, I'll try to keep an inventory of 1000 iron plates, so if there's only 900, then something wanted 100, so I need to make 100. However, it would be cool if I could just look at the network value and see that it's -100 and thus conclude that I need to make 100 more iron plates.

Anyway, do that, then drop the requester chest, rename the existing buffer chest to "requester chest," and we'll just have requester chests which, much like how the passive provider chest also serves as a storage chest, and the storage chest also serves as a provider chest, the requester chest can also serve as a storage chest, and a provider chest, depending on if the items are being requested by a player or construction bots. Then the problem of needing items on-hand in remote places will be solved without adding a 5th chest type that creates more problems than it solves. You just go wherever you want the items, place a requester chest, and then they'll be there if you need them or construction bots need them, and they'll also be available from any other requester chest that has some in it because they're sitting their unused in case an inserter decides to load them into a machine someday.

[mrvn]

You can checkmark "request from buffer chests" iirc.

[ColonelSandersLite]

Satisfaction: 0/100
On-the-way: 0
Logistic Storage: 1000

I'm inclined to think that this is a mod issue as I haven't experienced behaviors like that before.

It's actually not a bug and happens with the vanilla game. The 1000 items in logistic storage are in buffer chests, and so the bots aren't willing to deliver them because they're reserved for construction or player requests.

I really don't understand how buffer chests are supposed to be useful.

Looking back, I misread that bit. I thought he was saying that the logistic network was reporting that for his personal logistics, not at a requester chest.


No thanks to the rest. I use buffer chests quite frequently. Don't view them as a chest to store items closer to where they need to be used. You *can* do that but that's secondary. View them instead as a provider chest that *also* requests materials. Consider this example -

but I like to connect inserters that put items into provider chests to the logistic network so that they don't pick up items that the network doesn't need. So, for example, I might decide I need 1000 laser turrets at most, so configure the inserter that picks them up to not pick them up if the network already has 1000 for some reason, like, say I blueprint something with a bunch of turrents, so they all come out of the provider chest, and then decide I don't want it, so I control-Z it. Those turrets go into storage, but even though the provider chest is now empty, no more get made, since there's 1000 in storage

Instead of using a passive provider there, use a buffer chest. The inserter remains unchanged and the buffer chest requests 99999999 laser turrets. This has two major practical differences.

1. When you deconstruct/abort construction/whatever and end up with excess laser turrets, they don't go into mixed general storage. They go back into their regular box. If there's a *lot* of excess for some reason, the overflow may go to mixed storage but as you use the excess up, they get moved out of storage and go back into their proper box. In other words, it's self-sorting and you always know where to look for something. No need to ever go searching through unsorted storage boxes.

2. It allows you to have the *option* of having a chest that can provide materials only to select recipients.