Rework pumpjack expected resources value

[ChambersAUS]

TL;DR

Modify the pumpjack expected resources value to reflect the actual output instead of the base yield.

What ?

Pumpjack expected resources value in the tooltip panel and circuit network should be changed to reflect the actual output. In the below image the base yield (9.5/s) is shown regardless of modifiers. The beaconed pumpjack with speed modules should display a expected resource value of 106.796/s

Why ?

The current value is misleading in representing the actual output of the pumpjack. Changing this value to represent the actual output would allow for the accurate measurement of oil to determine when throughput is insufficient.

A use case would be reading the total throughput of all pumpjacks and triggering an alarm when throughput drops below a threshold.

[zanven]

+1

I would find this very useful to know ahead of time when i need to take a new oil outpost for my base as a an early alert, instead of going "oh shit my tanks are emptying fast and triggered a < 80% alarm"

[SoShootMe]

The current value is misleading in representing the actual output of the pumpjack.

I agree it is misleading but the rate reported is more like a representation of the amount of resource left, just like mining drills.

Changing this value to represent the actual output would allow for the accurate measurement of oil to determine when throughput is insufficient.

The maximum output (what you propose) could be more than the average required yet still insufficient (= refineries are sometimes short of oil). Maybe you just need more buffer, or maybe pipe or train throughput is the limiting factor.

But ignoring that, can you "determine when throughput is insufficient" with mining drills?

[NotRexButCaesar]

The current value is misleading in representing the actual output of the pumpjack.

I agree it is misleading but the rate reported is more like a representation of the amount of resource left, just like mining drills.

Maybe it should be displayed as a % rather than a rate.

[Khagan]

A related suggestion.

[ChambersAUS]

the rate reported is more like a representation of the amount of resource left, just like mining drills.

can you "determine when throughput is insufficient" with mining drills?

You can't compare the expected value of miners and pumpjack because one is showing total resources remaining (finite) and the other is showing resource extraction rate (infinite).

Miners don't show extraction rate because the base extraction rate is static and the patch size is dynamic. You can measure throughput by wiring up the belts carrying the ore away from the patch or by observing the tightness of the belts.

As the pumpjack value already represents the dynamic base extraction rate. There shouldn't be an issue with changing it to show the base extraction rate with modifiers applied (speed/productivity) to make the value/signal more accurate without changing what it represents.

The maximum output (what you propose) could be more than the average required yet still insufficient (= refineries are sometimes short of oil). Maybe you just need more buffer, or maybe pipe or train throughput is the limiting factor.

Changing this value has no impact on the operation of refineries down stream and helps in determining what the throughput issues might be.

[ChambersAUS]

The current value is misleading in representing the actual output of the pumpjack.

I agree it is misleading but the rate reported is more like a representation of the amount of resource left, just like mining drills.

Maybe it should be displayed as a % rather than a rate.

The tooltip panel doesn't matter so much, it could show the base rate, actual rate or the yield percentage but having the signal in the circuit network represent the extraction rate with modifiers is critical.

[Silari]

One thing this thread seems to have missed is that miners and pump jacks both display the exact same info in their panels, the only difference comes if they're mining an infinite resource vs a finite one. If you put a mining drill on infinite ores, it'll show the same output per second in it's tooltip. Put a pump jack on a finite oil patch and it'll show an expected total output. Any changes to this would have to apply to both entities when mining infinite resources.

[ChambersAUS]

One thing this thread seems to have missed is that miners and pump jacks both display the exact same info in their panels, the only difference comes if they're mining an infinite resource vs a finite one. If you put a mining drill on infinite ores, it'll show the same output per second in it's tooltip. Put a pump jack on a finite oil patch and it'll show an expected total output. Any changes to this would have to apply to both entities when mining infinite resources.

Didn't realise this was the case.
Regardless, changing the expected resource value would be better in both cases when you're extracting from infinite resources.

EDIT: Does the extraction rate of miners on infinite ore diminish over time like pumpjacks on oil?

[SoShootMe]

You can measure throughput by wiring up the belts carrying the ore away from the patch or by observing the tightness of the belts.

Right, and I can see some use for that, but it is not what your suggestion provides for oil fields.

Your suggestion is to provide the maximum output rate, which is the upper limit of throughput. This is also true for mining drills and although there are differences, I think there are more similarities than might first appear, one being the benefit (minimal) in either case.

[zanven]

You can measure throughput by wiring up the belts carrying the ore away from the patch or by observing the tightness of the belts.

Right, and I can see some use for that, but it is not what your suggestion provides for oil fields.

Your suggestion is to provide the maximum output rate, which is the upper limit of throughput. This is also true for mining drills and although there are differences, I think there are more similarities than might first appear, one being the benefit (minimal) in either case.

the suggestion is for "current output" not maximum, not base, not minimum. so it has some value on a circuit network as base has no value once pump jacks has modules on the circuit network. Otherwise idk why bother allow the pump jack to even go on the circuit network. just remove the circuit network cable from attaching.

[ChambersAUS]

You can measure throughput by wiring up the belts carrying the ore away from the patch or by observing the tightness of the belts.

Right, and I can see some use for that, but it is not what your suggestion provides for oil fields.

Your suggestion is to provide the maximum output rate, which is the upper limit of throughput. This is also true for mining drills and although there are differences, I think there are more similarities than might first appear, one being the benefit (minimal) in either case.

The property is called "expected resources" if I put a pumpjack on an oil patch I expect that value to show me how much oil it can extract. The extraction rate increases when I add speed modules so I expect the value to reflect that change. Why is having the base extraction rate useful instead of the expected output from modifiers?

[SoShootMe]

Your suggestion is to provide the maximum output rate, which is the upper limit of throughput. This is also true for mining drills and although there are differences, I think there are more similarities than might first appear, one being the benefit (minimal) in either case.

the suggestion is for "current output" not maximum, not base, not minimum. so it has some value on a circuit network as base has no value once pump jacks has modules on the circuit network. Otherwise idk why bother allow the pump jack to even go on the circuit network. just remove the circuit network cable from attaching.

By maximum output rate, I mean the current "Mining speed" x "Expected resources" x (100%+"Productivity"). I'm pretty sure that's the same as what you mean by "current output". It is a maximum because the actual (or current) output will be less if the pumpjack does not run continuously (or, as an edge case, does not have full power).

Why is having the base extraction rate useful instead of the expected output from modifiers?

The currently reported rate enables you to tell how depleted the resource is, which obviously does not change if you change modules or increase your productivity bonus. Note that I never said this was useful, and in fact I don't think it is particularly useful either; YMMV.

I'll try again. You wrote:

Changing this value to represent the actual output would allow for the accurate measurement of oil to determine when throughput is insufficient.

Strictly speaking, your suggestion allows you to determine that a particular (desired) throughput cannot be exceeded. It is an upper bound, so it can tell you when it is definitely insufficient, but it may be insufficient anyway due to logistics. I think this makes it far less useful for, as in your use case, triggering an alarm because what you really want to trigger on is throughput including the effect of logistics, like measuring the rate of ore on belts coming from an ore patch.

[ChambersAUS]

Your suggestion allows you to determine that a particular (desired) throughput cannot be exceeded. It is an upper bound, so it can tell you when it is definitely insufficient

Yes, this is exactly the desired use case.

what you really want to trigger on is throughput including the effect of logistics

Obviously it depends on what you're trying to achieve. My game settings makes it more important to know when you're running out of resources and need to expand by measuring resources at the source, instead of waiting for logistics and buffers to breakdown.

[SoShootMe]

Your suggestion allows you to determine that a particular (desired) throughput cannot be exceeded. It is an upper bound, so it can tell you when it is definitely insufficient

Yes, this is exactly the desired use case.

That's all well and good, except for the clause you snipped: ... but it may be insufficient anyway due to logistics. Meaning that your alarm might not activate when you wanted it to.

If you are assuming your logistics can meet the throughput, that's not relevant, but as they say, assumption is the mother of all screw-ups. And that's why I see limited benefit in the suggestion.