Question to the Devs: Hotspot Maths

This may be a shot in the dark, but I thought it'd be worth trying.

1. Roughly what is the falloff curve for individual hotspot bonuses? For example:

Code:
r = radius
r_max = maximum radius of the hotspot
base_bonus = bonus multiplier applied at the center of the hotspot
bonus = bonus multiplier applied at r distance away from the hotspot
base_content = % mineral content before hotspot bonuses
content = % mineral content at r distance away from the hotspot

content = base_content * bonus;

bonus = base_bonus * (r_max - (r / r_max))  ;; linear
bonus = base_bonus * (r_max / r) ;; exponential (-1)
bonus = base_bonus * (r_max * r^-2) ;; exponential (-2)
bonus = base_bonus * cos(r * PI / (2 * r_max))  ;; Sinusoidal

2. What's the influence of overlaps? For example:
Code:
b(r) = bonus multiplier functions from question 1.
r1 = radius to hotspot 1
r2 = radius to hotspot 2
r3 = radius to hotspot 3, etc


content = base_content * ( b(r1) + b(r2) ) ;; additive
content = base_content * b(r1) * b(r2) ;; multiplicative
 
Well, if the dev's don't reply we'll do as we've been planing, which is to do a statisitical analysis of the hotspots.

First off, the hotspots will each be prospected at specific distances with over 200 limpets at each sample distance, each of these will be called a "sample set"

The journal files from the participating commadners will then be analyzed to see what averages each distance has, and then we'll try to fit a curve function based on distance from the center to these averages. This will address question 1. in the OP.

To address question 2 in the OP, a significantly more involved case may be needed by tracking the distance to each hotspot in the overlap when taking a sample set, and additionally the non-overlapping areas of the hotspot will need to be checked to see if it still satisfies the assumption made for 1. as there is a possibility the hotspots involved were nerfed to make only the overlap viable.

...it's going to be a lot of work.
 
Does Ian Doncaster have any clue about this? He's generally the one for the esoteric maths in Elite.
I'm watching the thread because it sounds interesting and I'd like to know the answer too, but mining itself is something I do about once a year when I feel like a relaxing break from my normal activities.

(There's plenty of people who do detailed quantitative studies, especially in exploration and BGS, it's just that markets is my speciality and has been a hot topic lately for some reason)
 
In my experience the people doing quantitative mining research can mostly be found in the r/EliteMiners subreddit. Regarding OP's question, see this post for instance: Source: https://www.reddit.com/r/EliteMiners/comments/d5qflm/mining_research_hotspot_taperdown_second/

That's basically the same experiments we're doing, but with a much much much higher number of prospector limpets being shot off since prospector limpet events are now journal files and we can automate the data extraction instead of needing an eyeball on every prospector hit.

And yes, I'm aware of the reddit but have largely been hanging around in the iMU discord. they have a ticker feed in there as well so we can keep an eye on the reddit posts as they roll in. But frankly, its mostly noise posts.
 
Don't they just type in values and the magic happens?
Or do you suspect there is a bigger problem?

Depending on how they've got their program code set up, it can be glaringly obvious what the end-effect mathematical formulas are or it can be as clear as mud.

The multiplicative overlap influence we've enjoyed until Wednesday could've arisen by having the hotspot bonuses just blindly apply its bonus to the asteroid procgen and not consider other hotspots in the area. This (what appears to be) additive overlap influence we have now does consider what the nearby hotspots are doing, sums up their bonuses first before applying it to the procgen.

If it is indeed additive that they've switched to, then only enveloped hotspots which have their centers within the radius of another will be of any worth, since non-enveloped hotspots at best have the same influence at the center of a spot.

I'll try to get some graphs together to demonstrate the differences between multiplicative and additive overlaps. I tried doing them in paint.net earlier but they didn't turn out right.
 
If it is indeed additive that they've switched to, then only enveloped hotspots which have their centers within the radius of another will be of any worth, since non-enveloped hotspots at best have the same influence at the center of a spot.
Assuming a linear or concave relationship between distance and intensity here, right?

If they used a convex relationship (e.g. intensity = 1-sqrt(distance)) then the overlap could still be worthwhile even if the centres were separated.
 
Assuming a linear or concave relationship between distance and intensity here, right?

If they used a convex relationship (e.g. intensity = 1-sqrt(distance)) then the overlap could still be worthwhile even if the centres were separated.

Correct, assuming a linear or concave up relationship. Concave down curves such as cos(2r / pi) would still be able to reinforce each other, even if the overlap went to additive.
qs5FpiA.png


FQoEDsX.png



Here's the curves with overlaps that have the same radius and are spaced apart so that their centers are just right on the edge of the other's falloff curve.

Sum is a simple additive of the two curves, Multiply is the the simple multiplication of the two, and SumP is Sum + Multiply.

What we've seen after Wednesday's patch would suggest two things. First that the falloff curves are not concanve down, and second that the blending mode is most likely additive. Pre-patch the blending mode might have been something similar to SumP

[edit] inverted colors to match forum theme
 
Last edited:
There has always been a falloff, remember the general rule was that >80%R (red zone areas) weren't worth anything? The falloff curve was much steeper and flatter, and looked similar to a unit step function.
Really? No, I never heard of it. I just find it kinda complicated for the purpose it serves.
 
If FDev went down the scientific path, I'd expect a normal distribution (Gaussian or Laplace-Gauss distribution, because of the shape of its probability density function also called bell curve). It could be characterised by height at its maximum and the distance from center / width at some percentage of its peak (above background), e.g. a 1-sigma-radius.
(I, too, leave this comment mostly to track this thread, though ; )
Edit: Illustration: https://en.wikipedia.org/wiki/File:Standard_deviation_diagram.svg
 
Last edited:
I guess that the abrasion blaster thing is a side effect of preventing the egg reset exploit. It might look like a reset has taken place if the asteroid had already been interacted with before splitting.

This is literally impossible, unless their code is an utter mess with all kind of hidden bugs lurking in the background, bugs they never actually bothered to fix, only masked away using lazy tweaks. Bugs you leave unfixed in your code before you implement a whole new feature on top of the project (something they have been doing notoriously for years now) will always surface sooner or later, in a very hard to track down form...

Normal (laser mineable) material content has absolutely no problem respawning the intended way (after some time, irrespectively of relogging and the distance from the rocks). They should have followed the exact same respawn mechanism with SSD's as well, simple as that.
 
This is literally impossible, unless their code is an utter mess with all kind of hidden bugs lurking in the background, bugs they never actually bothered to fix, only masked away using lazy tweaks. Bugs you leave unfixed in your code before you implement a whole new feature on top of the project (something they have been doing notoriously for years now) will always surface sooner or later, in a very hard to track down form...

Normal (laser mineable) material content has absolutely no problem respawning the intended way (after some time, irrespective of relogging and the distance from the rocks). They should have followed the exact same respawn mechanism with SSD's as well, simple as that.
Oh, OK. You know much more about their code than I do. I'm just guessing from my own coding background. :)
 
Back
Top Bottom