I never even noticed the ore intake being higher with the mod. Lower the intake as you see fit; the closer to vanilla, the better.

Slaughter Lord is helping me with testing, and he has gathered a lot of really great data comparing the mod to Vanilla. I definitely need to make some adjustments.

The biggest differences seem to be in multiplayer or dedicated servers. I have a theory that the mod is grabbing ore both client-side and server-side, and combining the totals. If that's the cause, it should be pretty easy to fix. I will know more this evening.

There also seems to be an inconsistency regarding ore generated vs volume of asteroid removed. By volume, in single player, the mod appears to be generating less ore than vanilla. So while you may get more ore faster, it's only because you're burning up the deposit more quickly. I already have a (deactivated) mechanism in the code to counteract this, but unless I can reduce drill range a bit, it results in getting too much ore, too quickly. I will have to experiment with reducing drill range and increasing the frequency of processing, but if that has a deleterious effect on performance, it will defeat the purpose of the mod.

At any rate, it is being looked into, and there will be updates. Thank you for participating in the discussion. :-)

as a thought..the difference could be from what we as miners would refere to as slag.. or the bits of ore that normaly fly off in vanilla.... just a thought as your testing and number crunching....

There were two issues made very apparent by Slaughter Lord's VERY well set up and recorded tests. First, the base ore spawn rate was considerably lower than vanilla per volume and per distance traveled by the drills. Second, the mod was multiplying the amount of ore it collected by the number of players currently online.

Adjustments have been made to mitigate #1, though we will continue to look at it. Feel free to discuss rates and/or make suggestions.

A fix for #2 has been released in the latest update. Both single and multiplayer appear to be working just fine.

I have tried it with my small drill ship (120 drills), and in comparison to the vanilla drills, I'm getting about 3x to 4x more ore out of the same patch of asteroid. This is with only me playing.
A part of this seems to be the little ore fragments breaking off while drilling naturally.

Edit: Large ship drills are pretty much close enough to vanilla, with maybe 5-20% higher yield for the modded version (probably due to no "spilling")
Small ship drills seem to be very out of balance, with 200-450% increased yield over the vanilla ones.
From the test it seems like you can get from 4x the ore in a drill-next-to-drill arrangement
[XXXXXX]
[XXXXXX] = ~3.5-4x
[XXXXXX]
to only about 2x for a drill-gap-drill arrangement.
[XOXOXO]
[OXOXOX] = ~2x
[XOXOXO]

From this it seems like the overlap in drilling areas in small ship drills might be the problem there.

Edit 2:
With just a single small ship drill, the difference is about 15% in favor of the vanilla drill, so there are definitely some overlap issues at work.

That's very strange. The mod is not capable of looking at the same point twice--it uses the coordinates as keys in a dictionary that can only store 1 of each. Maybe it's something related to collection of ore, rather than spawning. I will have to look at that this evening and see what I can find out.

Would you mind telling me how you laid out your test? Like did you drill for a certain amount of time, or until a certain point on your ship? Can you give me a link to a blueprint for the ship you used? I want to try to replicate your findings so I can work on closing the gap you're seeing.

And how was the performance with that ship? I haven't tested it with that many drills.

Performance was really good, from 0.3 simspeed to about 0.9 with the mod. Extremely helpful mod, now my buddies can actually do something while I drill for ore!

there have been instances of roids, and occasionally ships, to duplicate themselves in exact location to the original...in the case of ships, they explode due to the physics engine. for roids however, they then to stay overlapped usually meaning its hard to mine the roid....which may account for the occasional 200% or more when drilling... this is a rare thing though and hard to duplicate precisely... closest example would be to spawn 2 roids in same area in creative and try mining the overlaped area...

Issen, I have verified your findings, and I believe I know why it is happening. You are right that it is (indirectly) related to the overlap.

I had a lot of trouble figuring out how Keen was converting volume of asteroid drilled into an ore amount, and my solution effectively removed the impact of the drill's range. Each drill was returning an amount based on a single point in its range, and that's why I had to add a multiplier to get small drill ore returns in line with vanilla for single drills.

Put them in an array, however, and this multiplier ensures that each drill is operating at 100% efficiency, while in vanilla, drill efficiency in an array would be reduced by neighboring drills. So it looks I need to take another stab at figuring out just what the asteroid content data represents. The first time I tried, produced ore was universally and insanely high. There must be a difference in units or scale. Content data for each point in the asteroid is 0-255. I need to find out what that means so I can reactivate the aggregation.

Thanks for reporting this. I probably will not have a solution tonight, but at least I know what the problem is. And for the record, these other points are already being processed, so this will have no appreciable impact on performance.

I'm testing the new formula, and so far, it's working very well for small drills. I also reduced the range of the drills a tad and pulled the drill area back toward the drill to more closely mimic vanilla. So far, there are still some minor scaling issues, this time in favor of less drills, but this scaling problem has a limit unlike the current implementation. It is a much closer approximation of Vanilla, and in my opinion, it is acceptable.

I still need to do some testing with large drills.

Keep in mind none of this is in the live copy of the mod. I have published what I have so far here, if you want to test it:
http://ad.gamersky.info/@steamcommunity.com/sharedfiles/filedetails/?id=433959431

Pulling the target area closer to the drills did not work at all for large drills, so I have left that part of things as they were, adjusting the formula accordingly.

The new formula will generate again still have some scaling issues, but nothing at all like the 4x the current production suffered from. The remaining issues are, I think, mostly due to differences in range, offset, and shape of the target area.

Using my current testing method, it is very easy to balance this for a single drill; however, differences in target area offset between the mod and vanilla mean a different percentage of the target area's volume is displaced by the drills themselves, depending on the varying offsets between small and large drills, as well as the varying ranges between them. This is further complicated by drill interference when the drills are in arrays, as the target range is then potentially displaced by neighboring drills in addition to their range. Differences in the target range's shape between vanilla and the mod also make this testing method unreliable.

I am going to post what I came up with into the live mod, but I will change my testing methods for future releases. Instead of measuring how much ore the drills retrieve based on the same amount of ship movement into an asteroid, I will have to create small, very easily cleared asteroids of a known volume for each of my test ships to consume completely. This will give me a much clearer picture of whether or not I am returning the right amount of ore, and in retrospect, this is what I should have been doing from the beginning. Live and learn.