How can the mex spot dedection fail so badly?

Does it still give you the designated metal income?

@MauranKilom> Does it still give you the designated metal income?

If you have to build 2 mexes to get same m/s, you spend 75m, 75e, 7.5s (+time for walking) more.
Also decreases OD

If you have more m per spot, it may be imba too


Klon> maybe too small extractor radius value in your smd/config file?

I neither made the map nor the config file.
This issue is not related to me, but to whole zk.


@ Who-has-written-it: How can the code fail on such a 'simple' input?

You could sort the black-gray stuff out.


Just ignore every square with less than 10..20% of the max. value...

Each such square would be as big as a 4r*4r (r=radius of mex)
Even x/z: 0*4r, 1*4r, 2*4r
Odd x/z: 0*4r+2r, 1*4r+2r, 2*4r+2r
offset = 1: odd x, odd z & 2: even x, odd z & 3: odd x, even z & 4: even x, even z
for 1 to 4: insert into table: { x, z, metal } and update maxMetalFound if required.

Walk through generated table of { x, z, metal } and sort out every square with 10..20% metal or less.

Look in table-entries (=squares - or more exactly their offsets) for best metal coordinates.
Merge/Drop some overlapping mex-coordinates.

I think the map maker's intention was to make the metal map looking more interesting...

> There's cases where the input is completely nonsensical and even a human couldn't place mexes properly

Then players would withdraw map anyway.

> There's cases where the grey stuff is supposed to be a mex.

If it pays back in time or not many other mex spots are close to it.
Maybe only sort out the squares which have low metal AND are close to 'real' metal spots, but max. 10% of map metal.

Because we can set the output manually that wouldn't be a big issue.

quote: I think the map maker's intention was to make the metal map looking more interesting...

What? Where do you even see the metalmap? You obviously didn't notice how dirty it is ingame, so no benefit there. And who cares about the metalmap picture on the map page?

quote: If it pays back in time or not many other mex spots are close to it. Maybe only sort out the squares which have low metal AND are close to 'real' metal spots, but max. 10% of map metal.

And i could still create examples of input that would misbehave. Again, looking at a special case and saying "well, here this property is intended and should be treated this way" doesn't work out. Your suggestion ends up in kludging stuff together. What is "close"? What is pay back "in time" (how long)? Why 10% of max metal, what if there's a lot of mexes or very few?
And once you spent 2 hours figuring out reasonable equations for the above, i'll come and break your system with another kind of input.

The purpose of a metalmap is clear: Black where no metal is supposed to be, grey/white where metal/more metal is supposed to be. Don't put grey when you want no mex there.
Would you draw a smiley on the heightap and then complain that the terrain generator picks up on it? No, if you screw with the input for some reason that it's not meant for, it's your own fault (yes i know the map is not made by you).

quote: Well what was the intention of the mapmaker by putting that grey stuff there? Don't blame the algorithm for mistakes of the mapmaker. Ofcourse you can find some procedure for an individual corner case, but that doesn't help at all. There's cases where the grey stuff is supposed to be a mex. There's cases where it's not. There's cases where the input is completely nonsensical and even a human couldn't place mexes properly. TL;DR: The mexspot fetcher is not the problem.

You are so wrong it makes me puke...
Its ZK who uses some hacks which prevents building mexes anywhere, even more I almost guarantee that this map is older than this "mex something" "feature" which was added to ZK only so far, how you dare to blame mapper for this? Either it was to make it look cooler in F1, or whatever reasons(even if it is accidentally outlined! YES EVEN) with normal spring without any hacks it works as mapper intended so its absolutely ZK fault, mappers in ZK are already anally raped with constantly removed features from what engine offers so DONT DARE TO BLAME MAPPERS for ugly ZK hacks which doesnt work.

Not all maps are supposed to be playable with all games.

If you wanna play on fucked up mups, shut up and bite the pillow.

What you call "hacks" we call "features."

KR thats exactly how I call them :P

Dunno how special metal config is made, but isint this going backwards, I mean what is easier to simply disable this feature on maps which it fails or write many metal configs for each map. So simplest solution would be allowing users to vote disable. Actually it should have been used on before broken maps to fix them, not to force on previously working maps, well that was my opinion.

"If it ain't broke, don't fix it."
Don't code fixes that nobody wants to problems that don't exist.

Straight from your book ;)