[2.0.11] Wired mining drills not sending resource patch data

[Adwedridan]

Prior to 2.0 I used to monitor patch using a single drill connected to circuit.
Now when the prob drill is dry, it stops reporting the entire patch resource.

Drill patch.png (499.9 KiB) Viewed 720 times

[boskid]

Thanks for the report however i cannot tell you anything from the screenshot alone. Do you have a save file that shows the issue?

[Adwedridan]

I tried reproducing the error, and I could not. The drill behaved properly sending data over wires, even after the ore was depleted.

But today, after updating from 2.0.10-1 to 2.0.11-3, I noticed the drill stopped reporting data over the wire right after loading the save.

It seems that updating the game and converting the save "resets" the drill's state and break the "read entire resource patch" data.

[boskid]

In that case i am going to call this Not a bug. This is tightly related to 111668

[Xynariz]

I'm bumping this bug report as I am able to reproduce it, specifically by loading a save from 2.0.13 in 2.0.14.

In the attached save, there is a mining drill at position (-128.5, -173.5) on Nauvis. The drill currently has no resource to mine, but it was placed on a patch of copper ore initially and that patch is not depleted. I have connected the drill via circuit to a programmable speaker. The mining drill and speaker combination is set to send a global alert when the whole copper ore patch is empty. When loading this save in 2.0.13 (the version in which it was saved), the speaker correctly does not go off. When I update the game to 2.0.14 and load the save, the speaker alerts, despite the patch not being empty.

With the frequent updates this game has had since 2.0 (THANK YOU WUBE!), I have noticed this nearly every time I update (I have similar alerts set up on multiple ore patches).

I came with the intent of submitting a bug report but found this one instead. Since I believe I am having the same issue, I bumped this thread with a specific example save. Please let me know if I should report mine as a separate thread.

Edit to add: I realize now that it was mentioned this is "not a bug" due to the fact it can be easily rewired. I would just like to offer one player's opinion that I don't like the fact that upon every game update, I would have to reconnect ore patches I have hooked up this way if I want my alerts to function as intended (alert when patch is depleted). I understand the reasoning behind calling the connection logic again when the prototype is changed, but could there be an exemption for reprocessing this patch logic when the prototype has not changed, or perhaps some way to store the patch it's reading and then refer back to that patch's current size upon reload? It seems less than ideal to me that accounting for an edge case likely only seen in modded games (the prototype changing what ore it can mine, or other relevant prototype properties) can cause a purely-vanilla (or purely-space-age) save to experience this change in behavior. In fact, the workaround described in #111668 would actually have undesirable effects here, as if my copper ore patch had happened to split into two patches due to depletion, I would want to track the entire original patch, which would no longer be doable unless I could happen to place one miner that spanned all of the split patches.

[SupplyDepoo]

Sometimes I set up programmable speakers to warn me when a resource patch is running low, and updating the game now causes these alarms to off when the wired drill has run out (which isn't unlikely given that it's easier to wire up the outer drills and those drills are normally the first to run out).

It's easy to fix, but does feel like a bug...

[BlueTemplar]

Well, at least you can expect the pace of updates to go down after a while after after a major release... (and can control when/if/how frequently you update the game yourself.)

[m44v]

This does make using the "entire resource patch" reading of miners quite bothersome.

[m44v]

In that case i am going to call this Not a bug. This is tightly related to 111668

After playing with the current behavior of mining drills for a while I have to argue against calling this not a bug. From the point of view of the user this conditional behavior is unexpected.

First of all, BlueTemplar is not completely correct, updating the game isn't the only thing that breaks mining drills data, it also breaks when:

• you add/remove a mod in your save.
• you update any mod in your save.
• you change any startup mod setting.

So if you use the "entire resource patch" readout there are several conditions you need to be aware, not only you need to avoid game updates, but changing anything in your mods. This makes the readout unreliable and annoying to use, things I have tried:

• Wire the mining drill with the most resources. This needs the least micromanagement since it will break less often, but will still break because the mining drill with the most resources might not be the last drill depleted, because when belts back up not all drills can work at the same time.
• Wire all the mining drills and use "this mining drill" readout. The most reliable solution if you only want to detect if the ore patch is depleted or not, if you want a resource count then your mining drills' extraction zone shouldn't overlap, which reduces throughput. Because I want a resource count and throughput and I don't use this most of the time.

However after a while I just gave up and I'm not using the "entire resource patch" data of drills anymore and I ripped out any contraption that needs it from my save. I know there are technical reasons for having it behave this way but the option now is annoying to work around if you know what is going on or a trap if you're a newbie.