Hey @CCP_Dopamine I have another question for you, maybe @CCP_Swift can help me understand the mechanics of waste again. Side Note for Thematics: I am a fan of using the word “Tailings” instead of “Waste” – while not quite the accurate real-world use of the word (it would be at the reprocessing step), it would make the “mining waste” feel more technical and distinct from the “compression waste”. Otherwise saying “waste” is ambiguous, to me. It also allows you to one day have a “tailings” object spawn in space, if you wanted to iterate on future mechanics, eg salvaging the tailings.
If the scenario is like this (easy numbers):
- 1000 m3 left on an asteroid (let’s say an R64 rock)
- 1000 m3 harvested per cycle by a T1 Strip Miner
- Implying: 1000 m3 will be tailings per cycle
If the miner lets the whole T1 Strip Miner cycle, it seems like the outcome is:
- Asteroid: 0 m3 remaining
- Ore Hold: 0 m3 added
- Space Dust: 1000 m3 poof’d
Is that correct? I would have expected:
- Asteroid: 0 m3 remaining
- Ore Hold: 500 m3 added
- Sapce Dust: 500 m3 poof’d
The reason being: My expectation is rooted in how current “partial mining cycles” affect yield. This seems like a stealth nerf to how “false full cycles” – where the module spins a complete cycle but the underlying m3 only has enough to yield a partial cycle – operate, for the “last asteroid cycle”. Please consider: my expected outcome can actually be attained, but it requires micromanaging the exact partial cycle – and that’s assuming you know the outcome of the tailings for that cycle. With T2 and other strip miners with a probabilistic outcome, you’re now essentially gambling for the last cycle extraction of the asteroid.
I would argue for, instead of a “allocate asteroid m3 to tailings first, then yield” regime, for “allocate asteroid m3 proportionally to both tailings and yield” as that preserves the current expectation around behavior of mining yield and “false full cycles”.
The current implementation is a level of micromanagement detail that seems unnecessary. I could imagine a “let’s make asteroid scanning more important to min/max by having it be an active part of extracting the last-asteroid-cycle”, but I have several counterpoints to those arguments:
- I am arguing for the status quo today around “false full cycles” – where the module spins a complete cycle but the underlying m3 only has enough to yield a partial cycle – to not unpleasantly surprise miners around this edge case. This keeps ore mining’s philosophy the same, similar to ice mining’s philosophy around cycle time and yields.
- Asteroid scanning modules are already used today, it is not like they are dead weight.
- You’re incentivizing players to emulate the “proportional” solution for last-asteroid-cycle by… turning modules on-and-off again in numerous partial cycles. This is not fun, impactful, engaging gameplay.
- Those most affected are:
- Asteroid sizes with smaller m3 (their effective yield will be disproportionately smaller, and complicates your analyses), which I believe are typically found in more popular areas, which means your analyses are probably over-counting the real yield for these areas; and
- People with higher yields – the more skilled and powerful will have more m3 that would first be allocated to tailings first, which actually acts as a punishing function for higher-skilled players.
Hope this makes sense.