Why autoshredder with drones isn't working?

[archmag]

I still don't have access to tier 3 mines so I have to deal with trash that blocks mine's storage. I tried to setup a shredder with -1 priority for resources that I want to dump in it expecting that drones will just carry them to shredder after storages (which have 0 priority) are full. The shredder also has an option of automatically destroy content when full activated.
https://steamcommunity.com/sharedfiles/filedetails/?id=3221659225

But for some reason drones never bring the final piece which should trigger the destruction. So I have to go to shredder and activate it manually. I am not sure why this is happening.

I guess the issue with most resources will be solved eventually when you get mines where you can select a single resource. But the issue with gases remains. Gas collector produces 3 gases, so when two storages out of three get full it needs to dump those two gases into shredder to roll for the last one. But it stops when shredder is almost full and so the last storage never gets filled. How to deal with this issue, how to configure gas collector and storages so that all three storages for three different gases will be filled?

[maestro]

I always set the shredder at Priority 1 and my storage at Priority 2, I never used negative numbers for Priority.

Maybe that's the problem?

[AdventureSeth]

Originally posted by maestro:

I always set the shredder at Priority 1 and my storage at Priority 2, I never used negative numbers for Priority.

Maybe that's the problem?

no, i have it the exact same way and it works fine, not sure what's the problem. sry.

[[BHA] Parazac]

Looking at your screenshot:

The "Container" shows it has 1 empty slot, it will shred when the "Container" is completely full.

[archmag]

Originally posted by BHA Parazac:

Looking at your screenshot:

The "Container" shows it has 1 empty slot, it will shred when the "Container" is completely full.

That's exactly the problem - drones don't bring items to this last slot, so drones never make it empty. As soon as I manually empty it they start to bring items again and stop at almost full waiting for the last item again.

Originally posted by maestro:

I always set the shredder at Priority 1 and my storage at Priority 2, I never used negative numbers for Priority.

Maybe that's the problem?

I decided to use -1 because I already setup a lot of demands with default 0 and decided not to go around updating them all in case I forget about one and screw up deliveries by accident. But as the next reply says this shouldn't affect the result.

Originally posted by jeffro504bc:

no, i have it the exact same way and it works fine, not sure what's the problem. sry.

Ohh, so it does work for you? Thanks for confirmation but then it's weird. I wonder what else it may depend on.

[akarnokd]

Unfortunately, this is a long lasting bug we've been unable to track down so far.

The workaround is to save and reload, but it may happen again and again.

[archmag]

Originally posted by akarnokd:

Unfortunately, this is a long lasting bug we've been unable to track down so far.

The workaround is to save and reload, but it may happen again and again.

I see. Thanks for the info. I was surprised that the issue disappeared when I started the game today.

[Merlok]

This bug is in the trade rockets, too, and the other storages.
to reproduce - launch the game for 5+ hours, and all the storage will stuck(

[Privatteer]

Originally posted by Merlok:

This bug is in the trade rockets, too, and the other storages.
to reproduce - launch the game for 5+ hours, and all the storage will stuck(

Does not even take 5 hours, but glad to know it's not just me seeing this bug.

[Abner Maul]

I am also having this bug with both shredders and trade rockets. I ended up deconstructing and the remaking my shredder, and that fixed the problem of the 'ghost in the last slot' temporarily, but it returned after a while.

[Stony1o1]

Originally posted by akarnokd:

Unfortunately, this is a long lasting bug we've been unable to track down so far.

The workaround is to save and reload, but it may happen again and again.

I also have the same problem.
For me, this is a gamebraking bug.
This game has now died for me.
I have almost 250 hours in the game. I loved playing it.
But at this point it doesn't make sense to sacrifice time for.
This mistake is so strong that it kills the game for me.

[Yvolette]

This has been an intermittent problem for quite some time. Sometimes its the shredder, other times it is a trade rocket, sometimes it is regular storage. When food production stops i always no where to look. Sure enough the shredder has one empty slot so it didn't empty . Hives are full of bees so no honey. Aggravating to say the least.

[Alt-F4]

Originally posted by akarnokd:

Unfortunately, this is a long lasting bug we've been unable to track down so far.

The workaround is to save and reload, but it may happen again and again.

Hmm... At what level is the bot script running? I'm not an experienced programmer in this regard, but if this is, say, C, my thoughts on where to look are different than if this were a script run through a parser. Since it seems to crop up over time, I'd think it has to be how the script is being parsed. I've noticed that the system creates a "bot deposit" entity to occupy the space. Assuming this is multi-threaded, and scripted at a high level without a whole lot of control over the threading, the parser is creating a pre-fill entity which is flagging a "is full" check and dumping all bot dispatches. Basically, I suspect the left hand and right hand are reaching to put something in the same empty space, and the brain is seeing a future hand in the box and aborting all hand movement, rather than culling all but one hand motion.

It could also be something even more spooky. Modern architectures like to "learn" to predict things and will run conditionals differently as they are exposed to the same code. When multiple storages fill up, you'll get a lot of conditional operations along the same line, polling the same area of memory to see what its condition is. If you have 500 bots, only 1 out of 500 requests (potentially) are going to result in a condition of deliverable. The CPU scheduler then learns to return with the >99% value, and depending on how the branching code is implemented, the code dependent upon that conditional is off to the races before the CPU recognizes the cache miss and gets back around to correcting itself. Because the "full" inventory condition will almost certainly be loaded into cache, the "empty" inventory condition will be at a more distant layer of memory, creating a scenario where the process effectively locks with an entire sequence of conditionals completing before the "oops" gets delivered, and there being no process to go back and recover the whole program branch. It would be interesting to see if this problem has variations across hardware and/or if it exists when running a stripped down build of the game on an architecture without a much branch prediction baked into it.

How I would approach it, at least. As a random idiot on the internet who has done more study of programming than actual programming.

[akarnokd]

Originally posted by Alt-F4:

..

Don't sweat it. The game uses a numerical reservation system. If an item will be moved, the number goes up. If the item was delivered or the transfer cancelled, the number goes down.

When it bugs out, the reservation amount is not decreased and it will appear the last slot(s) are still expecting item deliveries that will never come.

No concurrency is involved, the accounting is done on the main thread, guaranteed by Unity.

So far, the devs and modder(s) were unable to pinpoint where that decrement is missing from.

[archmag]

I bet it is because resource to be transferred was eaten by an autocrafter. So drone decides to deliver some resource, reserves a resource and a destination slot and then comes to pick up the resources but there is none because it was already used by autocrafter. Because drone didn't pick up the resource, it just abandons the task without clearing the reserved space for it.

Or in case it only reserves the destination after picking up the resource it's because autocrafter steals the resource from the drone's inventory while drone is still near it. Drone doesn't notice that and "delivers" the resource, but can't unload it so the slot is never unreserved.

Anyway, that's my theory about this situation. I have no idea how to actually reproduce it.

Edit: nvm, tested it and both theories are wrong. Second one doesn't work because drones are not treated as storage by autocrafters (they flied freely above autocrafters without them stealing resources when it was just a single resource required to finish the craft). And case about autocrafters stealing resources from storage before drones get there also didn't lead to the bug even though I had some unrelated issues with drones filling Priority 1 storage before Priority 5 for some reason. Eventually I managed to setup the production that steals resources from mines few seconds after they are mined and drones go to pick them up for shredder and it didn't trigger the bug.

[gitarrlillan]

Originally posted by akarnokd:

Originally posted by Alt-F4:

..

Don't sweat it. The game uses a numerical reservation system. If an item will be moved, the number goes up. If the item was delivered or the transfer cancelled, the number goes down.

When it bugs out, the reservation amount is not decreased and it will appear the last slot(s) are still expecting item deliveries that will never come.

No concurrency is involved, the accounting is done on the main thread, guaranteed by Unity.

So far, the devs and modder(s) were unable to pinpoint where that decrement is missing from.

One day you will find it and wonder how you couldmiss that for so long. Until then don't give up.