An irritation thing that has to do with mapping...

[Forboding Angel]

Mex radius. It affects metal income. If you don't believe me compile a map that has a mex radius of 300 and absolutely no metal on the map. The mex will put out .6

My question is simply, why? Why does radius effect metal income rates?

In the smae map add a metal spot that is red 255 in a 6 pixel circle. Set smd to maxmetal=1; Then set the radius to 40

the spot will put out 2.0 metal.

Now, simply change the radius to 100 - 300 and leave the max metal and the metal map the same as before.

The spot will put out 2.x (x being the number that the radius adds from COMPLETELY BLACK METAL GROUND!)

btw for those of you non mappers out there... A 40 mex radius is the exact radius of 6 pixel circle on the metal map.

[FLOZi]

Funnily enough footprint size (not the same thing I know) effected mex production in TA

Dunno why I mention that

[AF]

mapper says that if mapper has x metal on spot y then any mex you place will give y value.

Spring says any mex will have teh cumulative y values of all in x area of radii

where the .6 came form I'm not sure though....

[Forboding Angel]

try it out AF, it's true. I was a bit disturbed when I noticed that.

Now admittedly 300 radius is huge, but it's to prove a point ;P

If there is no metal on the metal map the mex should pull in 0 regardless of radius.

[NOiZE]

just tested it on Comet Catcher remake

metal spots are like 9 pixels

radius=100 will give 1.9
radius=500 will give 1.9


so it works fine!

[Forboding Angel]

OHHH Maybe it got fixed! if so, KICK ASS!!

I will test this when I get home. If I made this post in error I apologize. Thanks for that test NOIZE. I am at work so I couldn't test this, HOWEVER, this used to happen some versions ago.

If this has been corrected I have nothing more to say about it lol. Wish it had been in a changelog somewhere tho.

[AF]

Noize cometcatcher uses OTA style mex patches, thus unless a mex radius is big enough to cover the mex spot, and the neighbouring spot, it will always give the same amount untill ti gets smaller than the mex spot.

Try it on a map such as brazillian battlefields or metalheck instead.

[Caydr]

OHHH Maybe it got fixed! if so, KICK ASS!!

Ye of little faith...

[Kelson]

Mex radius. It affects metal income. If you don't believe me compile a map that has a mex radius of 300 and absolutely no metal on the map. The mex will put out .6

That isn't possible. Only read the detailed explanation below if you really want to know, mechanically, why that is. Simply put - even if you make a metal extractor radius that covers the entire map, if the max metal is 0 (and your mexes aren't creating metal like metal makers do), that metal extractor will still extract 0 metal. If there is metal though, they'll catch all of it (very profitable metal extractor).

What you may have experienced is that, by increasing the radius, you caught more of the nearby metal. The metal map has 1/2 the resolution of the terrain map, leading to what appear to be blocks. Additionally, the algorithm uses only blocks/pixels that are fully inside the circle (no half-blocks). By increasing the radius, you might have caught more of those edge-clipped blocks and had more income as a result.

All the code controlling how much metal is extracted is handled in ExtractorBuilding.cpp. For this discussion we only care about the part excerpted from the end of CExtractorBuilding::SetExtractionRangeAndDepth. I've modified it slightly for readability.

Code: Select all

metalExtract = 0;
int xBegin = max(0, (pos.x - extractionRange) / 2);          // >= 0
int xEnd   = min(width/2-1,(pos.x + extractionRange) / 2);   // <= width
int zBegin = max(0,(pos.z - extractionRange) / 2);           // >= 0
int zEnd   = min(height/2-1,(pos.z + extractionRange) / 2);  // <= height

for(int x = xBegin; x <= xEnd; x++) // x bound
for(int z = zBegin; z <= zEnd; z++) // z bound - makes a bounding rectangle
{
  float3 msqrPos(2*x + 1, pos.y, 2*z + 1);	// center of square
  float sqrCenterDistance = msqrPos.distance2D(this->pos);
  if(sqrCenterDistance < extractionRange)       // actually in range of us
  {
     MetalSquareOfControl *msqr = new MetalSquareOfControl;
     msqr->x = x;
     msqr->z = z;
     msqr->extractionDepth =metalMap->requestExtraction(x, z, depth);	
     metalAreaOfControl.push_back(msqr);
     metalExtract += msqr->extractionDepth * metalMap->getMetalAmount(msqr->x, msqr->z);
   }
}

The only important stuff is "extractionDepth = metalMap->requestExtraction(x,z,depth)" and "metalExtract += extractionDepth * metalMap->getMetalAmount(x,z)".

metalMap->requestExtraction(x,z,depth) just checks that no one else is extracting a spot (at least, to the same depth) then returns the available (un-extracted) portion of metal in the spot (normally not an issue, but this is why a moho works even inside the normal mex radius).

metalMap->getMetalAmount(x,z) simply returns the 'metal value' of a location. By multiplying that times the 'available' metal, we have exactly how much is extracted.

Since the final value relies on metalMap->getMetalAmount(x,z) - if there is no metal in a map (and your metal extractors aren't making metal), then it is impossible for them to extract any. Of course, if even one spot inside that huge radius has some metal...you'll extract some metal. There are finite metal values (256 to be precise), so we can reliably say that 0 metal in a spot will always add up to 0 no matter how much we multiply it. Hope this helped :D

[zwzsg]

Maybe you haven't used pure black (it's black right for no metal?) on your metal map image. Maybe you compressed it in jpg which introduced some artefact.

[Forboding Angel]

I don't believe in compression.

unless r 0 g 0 and b 0 no longer == pure black.

Good thoughts, but I'm not exactly new to this. Besides when I noticed this it was many many versions ago, therefore it prolly got squashed a long time ago.

[SwiftSpear]

This is a pretty huge issue, can someone verify that noize's findings aren't a all encompasing sample?

[Kelson]

This is a pretty huge issue, can someone verify that noize's findings aren't a all encompasing sample?

Did you understand Noize's post (and/or mine)? His findings are all encompassing for the scope it was performed.

Noize showed that the change in radius didn't make a difference (he didn't specify that the radius not overlap any additional metal, but that was the case). I showed the code that calculates metal extraction values inside the engine, which shows that radius does not directly contribute to metal value (it just allows a metal extractor to cover more values).

[SwiftSpear]

This is a pretty huge issue, can someone verify that noize's findings aren't a all encompasing sample?

Did you understand Noize's post (and/or mine)? His findings are all encompassing for the scope it was performed.

Noize showed that the change in radius didn't make a difference (he didn't specify that the radius not overlap any additional metal, but that was the case). I showed the code that calculates metal extraction values inside the engine, which shows that radius does not directly contribute to metal value (it just allows a metal extractor to cover more values).

Ya, but forboding said that if you have a black metalless feild mex pull some metal out of it. More metal if they have larger radiis. I want to know if that is acctually the case.

[Forboding Angel]

@ SS

I'm assuming that it was fixed some time ago. Used to cause me a lot of problems.