Release: Metal Spot Finder (+Mex Snap)

[Niobium]

Download link can be found here: http://widgets.springrts.de/index.php#183

Description (from link):
Provides other widgets with the location of maps metal spots, by itself it does nothing.

What it does:
Basically the widget is a replacement for the Area Mex code that a lot of people seem to be using, based on a better algorithm that is faster and provides information about spot dimensions. The main use of knowing spot dimensions is that it can determine locations which would give 100% extraction.

It puts this information in the global WG table and then terminates. This means anything using the information will be running in its own widget space which prevents the bugs that happened with area mex (i.e. button version causing freezing).

Advantages:
- Faster (40x), takes less time to find metal spots than it does for custom formations to work out a line move, ~0.04 seconds for standard maps, 85% of which is spent extracting metal values from the map.
- Detects every metal spot, area mex code will sometimes join two spots that are close.
- Provides information for all widgets: prevents duplicate metal-scanning code running.
- Provides information about metal spot dimensions.
- Provides information about what extractor positions would result in 100% extraction.
- Properly detects metal maps or maps with cloud metal and terminates, rather than freezing.

Disadvantages:
- Terminates on metal maps or cloud metal maps, hence providing no information. In the case of cloud metal maps an arbitrary 'tolerance' like that used in area mex would solve this, but arbitrary isn't good in every case (and cloud metal maps are reasonably uncommon)

Data:

Code: Select all

WG.metalSpots[1..#] = spot

spot = {
    .x, .y, .z, -- Position
    .worth,
    .minX, .maxX, .minZ, .maxZ, -- Bounds
    .left[z], .right[z] -- Gives X bounds for particular z (valid Z ranges from minZ to maxZ with step 16) 
}

Functions:
WG.GetMexPositions(spot, uDefID, facing, testBuild)
Given a spot (taken from the global table) and a building uDefID/facing, it will return a table of all valid positions for that building that would extract 100% of the spots metal. The testBuild parameter indicates whether the function should test if the build positions are blocked, if so they won't be included in return table.

WG.IsMexPositionValid(spot, x, z)
Given a spot (taken from the global table) and a location it will return whether an extractor built at the location would extract 100% of the spots metal.

Example - Snap Mex:
To actually give the release of a widget which does nothing some substance, I made a small widget that makes use of the information that this widget gives, namely the knowledge of valid extractor positions. The widget also acts as a demonstration of how to use the metal spot table, and both of the functions.

The widget is called snap mex and has been released seperately, the download link for snap mex can be found here: http://widgets.springrts.de/index.php#184

Description - Snap mex (from link):
When placing mexes, if the mex position would not give 100% of the spots metal, then the position will be moved to one which would give 100%. Works especially well for placing mexes when zoomed out.

[Snap Mex Screenshot]

[CarRepairer]

Some of your ideas are good, but you make a contradictory claim by

more accurate

since you later say

Terminates on metal maps or cloud metal maps

Areamex code works with cloud metal maps.

[CarRepairer]

Nice edit

Seriously though, I was hopeful that you improved on my code because it is indeed slow, but there are plenty of maps with cloud metal spots that people play.

And my code does give you extraction info because it gives the best extraction location by nature (it doesn't just use a cutoff tolerance as you stated).

The WG thing is a nice touch.

[Niobium]

Some of your ideas are good, but you make a contradictory claim by

more accurate

since you later say

Terminates on metal maps or cloud metal maps

Areamex code works with cloud metal maps.

I've edited it out to keep you happy, but the 'more accurate' was referring to spot location, and how areamex provides x/y/z based on repeatedly averaged flag positions weighted by a rounded ratio of strengths, while this provides x/y/z at the center of the metal spot and provides the location of every piece of metal that made up the spot if you wanted more detail.

Seriously though, I was hopeful that you improved on my code because it is indeed slow, but there are plenty of maps with cloud metal spots that people play.

Areamex works on cloud metal maps by employing a minimum-metal threshhold. This threshold effectively turns metal clouds into metal spots, which my widget would work on (and faster). I could easily put in the few lines that would be required but I don't believe it is a satisfactory solution, completely excluding certain raw data is just wrong.

[very_bad_soldier]

Have not tried it yet, but I think I already love MexSnap... thanks!

[Pxtl]

It would be nice just to have an optional fallback behavior for metal and cloud maps that simply draws a hex-map (scaled by the extraction-size) over the entire map and plonks a spot on every hexagon that contains metal.

[Cheesecan]

Good job but one small complaint, I'm missing relative metal spot worth as a return value of GetSpots(). It's of interest to widgets like my metal placer which need to know which metal spots are more valuable than others.

[Niobium]

Good job but one small complaint, I'm missing relative metal spot worth as a return value of GetSpots(). It's of interest to widgets like my metal placer which need to know which metal spots are more valuable than others.

'.worth' is what you are after, i.e. WG.metalSpots[1].worth. For relative you can just loop through to find the maximum worth and go from here.

[Cheesecan]

Thanks I completely missed those fields last night must have been tired..

[NeonStorm]

The link is broken

[Petah]

Can I access this from a gadget?

How would I get metal spot closest to unit?

I tried:

Code: Select all

vardump(WG.metalSpots)

But got

Code: Select all

[f=0015104] Error: Lua LoadCode pcall error = 0, LuaRules/main.lua, error = 2, LuaRules/gadgets.lua, [string "LuaRules/Gadgets/bai.lua"]:73: attempt to index global 'WG' (a nil value)

[Google_Frog]

(synced) gadgets can only be affected by things which exist on every player's computer. This rules out anything which exists in widget land because it is local. You can send things from widgets to synced gadgets through the network but this is probably not what you want to do.

If you're making a gadget then you're (probably?) making a game. Turn the mex spot finder widget into a gadget and then it will be identical on all computers and can be accessed from GG. I have already done this here: http://springrts.com/phpbb/viewtopic.ph ... 7&start=40

If your gadgets use metal spots then you have probably decided to leave cloud metal maps behind. The gadgets and widgets in my link form a system which sends the gadget-found metal spots to widgets to ensure that the UI and game mechanics line up exactly. It also allows you to use maps without referencing their metal map at all.

If you are making a lua AI then the metal spot finder gadget is all you need.