-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MEx building issue when metal spot is occupied by non-metal extractor #32
Comments
When playing this map, the AI energy stalls bigtime, but does not build energy. (right from the start, because it builds alot of mexes) |
May be it is time to update your map? I have downloaded some Plains_and_passes map. There is extractor radius = 90. No AI degrades. Or give a link to your specific map. |
ah, I put it here: http://merijn.bofp.org/Plains_and_passes.sd7 I know it's a specific problem. but maybe it can be fixed some time. but I admit its very low priority. |
I don't think we need to fix problem with too small extractor radius. AI calculates best spots so it could grab more metal. This is a map only issue, so do not redirect it to us. Concerning building extractors on space occupied by non-extractors is a different problem which evidently should be fixed. Next time do not mess many issues in one report, please. |
Where in this post do I state that the too small radius is a problem and should be fixed? As the title of this issue stated, it is about the blocked metalspot problem. The only reason I provide you the map is because playing this map makes this issue appear. In fact the root cause of the problem is a blocked metalspot, whether by mex (special case) or non mex, doesnt matter. If you don't want to fix the 'covered by mex special case' (for whatever reason), thats up to you, but I think in principle its all the same issue. The only mixup of issues I did in here is the energy stalling thing i mentioned. |
"Mex spot detection" from previous title is about small radius. If radius would be normal then issue would never arisen. Also i confirmed that issue with blocked metal spot by non-metal extractor should be fixed.
Covered by mex and covered by non-mex are different issues for me. First one is automatically fixed when putting sensible extractor radius for the map. This is what i wanted to say. |
Just my $0.02: I think that too small extractor radius is completely ok. It makes gameplay different, so what? |
It has no sense when extractor radius is less than radius of circle inscribed into MEx footprint. That means the map is not suited for current mod. Anyway it can be fixed by adjusting extractor radius returned by API per each MEx type. |
This problem is most clearly observed when playing the infamous plains and passes map ;).
Plains and passes is a map with very small extractor radius combined with slightly bigger metal spots. In fact the extractor radius is smaller than the mex building footprint. What happens is the metal spot detection algorithm detects several (mex) spots close to each other around each metal spot. This in itself is not a problem. However when the bot starts building mexes, it cannot build them as close to eachother as suggested by the metal spot list. As a result the bot places the mine as close as possible to the requested location. But due to the small extractor range, this means it actually builds completely off spot (because it cant build closer). And when requesting the next nearest metal spot, this same spot will be returned (because it is closest and because no mex covers the spot). As a result it will continue to build bigger and bigger circles of mexes around this spot.
In this map the problem is offcource caused by the small extractor radius compared to the mex footprint and metal spot size. However, this same issue could conceivably arise if something else covers access to a metal spot. Most likely to happen on maps with small extractor radiuses.
I have a possible solution for this problem. Currently, when a mex is completed, its location is stored in the takenmexes map. For this the actual location of the mex is used. If instead of the actual location, the requested location (as from metal map) is stored, then the problem on plains and passes ceases to exist (I tested this). It now builds only one mex for every metalmap spot, and if it is not able to cover the spot, then he builds a mine off-spot, but at least he doesnt keep trying that one spot he cannot reach.
slogic: title is updated (original was "Mex spot detection/building can mess up when area is occupied")
The text was updated successfully, but these errors were encountered: