A cease to the desire to build bigger and bigger checkerboard arrays would be nice, to reduce the number of beams the game is trying to draw. Abstracting where the resources come from would also be a good way to reduce lag form immense salvage systems: if one high-power system hitting one asteroid is enough to draw the mineral wealth from the asteroid quickly and efficiently, and eventually drain it (I suppose it would visibly collapse and be removed after being drained of resources?), without nasty chunk updates being necessary, suddenly you don't have to worry about how much strain you're putting on the server/your own GPU when you upsize an array to mine faster; all you're doing is increasing the draw rate. Limiting the number of outputs to a single beam per entity would also make it significantly more difficult to use this as a way to lag and crash a server by drawing billions of beams. It would be more like a scan computer, where all modules linked count towards your draw rate from the single beam (one of the modules you selected as your output point), but you only get to place a couple salvager computers, each having on beam. I suppose at this point, there would be no more need for secondary computers tied to the salvager system.
Yeah, it isn't as amusing as watching that asteroid crumble to dust under the immense checkerboard-power of your supersized mining rectangular prism-shaped thing, but it's better for the server not having to process those chunk updates, right? Given, perhaps there's a way to implement an asteroid visibly collapsing during the mining process without having that problem?
Now, on how asteroids respawn: the only idea posed so far that I really dislike is the "on server restart" option. Flinging them out from stars during certain rare events, falling into orbit after arriving from out of system are both acceptable, even in combination. Whatever. As long as they don't respawn as the same object they existed as during the last server autosave anymore; it's very exploitable, but also very lame when you don't want to exploit the bug and end up getting the exact same asteroid every time you enter the system, but that object turns out to be a mined out husk with no remaining mineral worth. Having the objects in the belt actually moving around in their orbit sounds awesome, but I worry for the sanity of the server computer responsible for tracking those objects. Perhaps if that were used as a way to homogenize the belt density after a player has come through and gobbled up all the asteroids in one segment of the belt: the game chooses from some sectors on the same belt, or a directly adjacent one, and moves an asteroid or two from the more dense region to the less. Having one or two objects moving around (as a limit), in systems that are occupied anyway, wouldn't be too hard on us, right? If there aren't enough asteroids left to give each belt at least one, then let one move only rarely.
This way, you'd begin to feel the effects of draining your system of asteroids through scarcity as you continue. And also be in more danger of getting bumped by one while it moves to its new home.
I'd appreciate a slow "respawn" system, say introduction of asteroids on a single-digit, per-sector basis by one of the previously mentioned methods.
Would be nice if this would all work well together with improved resource
distribution and
acquisition as suggested by Ithirihad
I would say, however, that the way asteroids are always clumped together at the center of a sector, and their number/size limited, regardless of sector size
is kind of silly.
