Player Features and Ideas Discussion

So yesterday whilst mining with my buddies, we were discussing mining cycles. The idea was brought up to completely rid of Mining cycles and to implement a new system:

Strip Miners:
Instead of, say, 100s cycle time, there will be no cycle time. Similar to a cloaking devices' active module "cycle", the strip miner continuously sucks in ore. When you hover over it, it will display m3 of ore per minute. However, ore will not be deposited into your ore hold on a minute cycle, but instantaneously. Crystals will have a chance to take damage every 120s, similar to average mining rates today (for retty atleast). Mining bonuses from ship skill will have 2 sections, 1 for increase m3 per minute on Gas Harvesters and strip miners, and 1 for ice harvesters for time reduction.
Ice Harvesters:
due to the unique volume of ice, cycles on harvesters will have to stay.
Gas Harvesting:
Gas Harvesters will be changed similarly to strip miners in that they are cycle free.

These changes will remove the problem of always trying to time it right so you don't waste a cycle on small roids. It takes care of the problem of timing of trying not to waste a cycle to fill your ore hold. Anyway let me know what you think. Fly safe o7

Your idea would require several database changes per second per mining laser. While it may sound cool, it would use up more resources than justifiable for such a small comfort gain. Use a survey scanner and your brain. It's the last bit player skill involved in mining.

As a former miner, a spreadsheet formula to calculate how long to leave a beam on a rock, a survey scanner, and a timer are very handy to optimize mining time. A little brain work eliminates the need for this idea.

this and mining doesn't need to be more afk

Cycle times down to each server tick would put alot more strain on the servers, however to reduce the cycle times to 10-30 seconds, I believe would be more reasonable. Along with changing ice blocks to ice cubes so you don't have to wait for a full cycle and you can actually cut your cycles short if you wanted and still get product.

Every second is too much server load for a relatively small gain for player but shorter cycle across the board on strip miners would be welcome.

All this because you're annoyed the last cycle isn't a full amount?

I like the idea, but that's because I also like the idea of reducing minerals in the universe greatly and making mining a lot more competitive. A system like this would suit the idea of miners spending less time actually mining and more time preparing and hunting for ore and stuff (in a universe where minerals are scarce and miners are cunning).

TL;DR
No, it doesn't. But, I agree that it would use more network traffic than it used to. However, with a good server side prediction algorithm, that extra work overhead would become neglible.
-- EOF TLDR --

Eve graphics engine already has that command rate prediction algorithm in works. For those who asks "how the hell that prediction works?" Let me explain it as simple as possible:

When you go on a vector from point A to point B, you update your status to server one time, then server starts updating your client two times per second and one time per second for overview (let's call this behavior server tick).
Between server ticks, your screen renders the rest, without letting server know what're you doing, because server already knows you will end up to point B if you doesn't change your predicted behavior. If you happen to click anywhere else in the space, then you send about your new vector to the server one more time, a new prediction is now made by server and you stop updating your status again unless you touch anything else.

If there happens to be a packet loss/network screw up, you might experience your client throwing you back one-two ticks earlier, which is the server's last confirmed status for you.

So, no, it wouldn't require more updates of any rate, actually, it needs only two. The start, the end and some heartbeat in-between.

For example; Let's say N people are going to mine in a belt. The arbitrary complexity can be solved by Observer pattern, where a player-issued command on an observable object (a rock in this case), is sent to the other listeners on the same grid, which are other strip lasers on the same rock. So, each client exactly has to know how many strips started on the same rock with a timespan information, the rest can be predicted by server "unless N clients won't change their behavior and until first strip ends in xx seconds, rock value = rock value - N*(each miner strip rate)*seconds until first laser stop timespan".
This is a one tick information for N clients. Rest is calculated client side where you see an extremely fast coundown of rock information being updated on your screen. This information isn't sent to the server by your client since server already knows it.
For specifically this mining case, since people mining in belts don't stop/start their lasers like crazy (crystal damage, you know) this prediction system will work like a charm and that foreseen exaggerated overhead is something very tiny and neglible.


All these data would be then collected on another cache service in front of db (which may have its own slaves), which flushes all stuff done that day just before downtime optimization. So, db actually gets one update per day from the cache service for all the miners' collected minerals in eve universe. Everything else (market, your hangar, etc..) is querying the cache, not the db.

The real scenario can be much more different, however, this is how it is done in general when everybody is using one common source. Caching mechanisms/services.

Ice mining could be fixed if they changed each block of ice into 100 blocks of Ice, and made refine size 100....would add a lot more alignment with how strip miners are handled.