I know about easymetal and it did not do what I wanted. I want to leave working maps unchanged.

The basic difference is that my mex spots have a value linked to them. This value is equal to the metal income of a traditional mex if it were placed there. I want to keep the super mexes that mappers tend to put in the middle of maps and I want to keep the variation of general mex income between maps.

With this in mind it is very hard to make cloud maps work. There are so few cloud maps that it is just better to make a config for the few maps that we still want to use.

yeah, that's strange.. its almost as if nobody plays evo

User was warned for this post.
Enough. Argumentative misdemeanor 3.

can't we have a discussion about an idea without people talking about who did what first and zomygosh peen?

Fair point but I think it could have been done with easymetal because it assigns a "weight" to each spot. Maybe you just weren't aware of that.

I just realised a deeper table would be a really nice thing to have in case more parameters are added gameside. Due to the way I linked to the config in the op it has automatically updated for a deeper table.

I tried a very long time ago to convince ZK to use it as it's a great boon for games like that. Once again, snubbed noses.

Regardless, this is quite excellent google.

Does the lua metalmap override one already compiled in? If so, that would make my life a little easier (because I want to switch my maps over to this).

The hierarchy of metal location is as follows (top has priority):

• Game side config
• Map side config
• Detected from compiled metalmap

The heirachy of metal value is separate and can be defined per-spot:

• Game side metal value override config. The game side per-map config can say all mexes have a certain value.
• Game/Map spot Config. Metal value for spot config is optional, if it is present it will be used here.
• Detected from compiled metalmap which is used if detected value > 0
• Game side default value.

With all detection methods values below 0.2 are discarded, this is because a few maps have small imperfections in their metalmap that the detection algorithm picks up on.

My old map still has a fan? Woohoo! Beside it wasn't meant as cloudy distribution, but as even distribution.

IMO the cloud metal could work, if only instead of cheap mexx the metal map was used for much more expensive or late game buildings, that you couldn't build in such numbers. Then you'd have to ponder tradeoffs between vulnerability and greed, between few extractors to get most of it, or many extractor to get all of it, and things could get interesting.

Of course cloud could work for some game but it doesn't for ZK which is why I have done this. You must understand overdrive to argue this point.

Google frog. The map metal layout should go into



Please change this in your source so that you remain compatible and consistent with blueprint maps

Hey, I just want to clarify..

this is not core engine functionality right? like if I used a map that didn't have a compiled metal map in BA it would fail ?

Just include the gadget with your map if you're worried about it

Speaking of that, why isn't this gadget linked in the first post? http://code.google.com/p/zero-k/source/ ... finder.lua

Forb's answer confuses me so I will answer as well.

This is not core engine functionality.

If you want to make a map with a discreet metal map that will work with most games. I see this as the most likely case, to do this you can just include a normal image file metal map. The lua in ZK and Evo will detect the metal map and convert it to points.

If you make a cloud metal map then ZK will be screwed up completely and Evo will work poorly. They use different spot detection algorithms. To fix this you can include a metal map lua config.

If you want to ignore the metal map completely (say you're making a game that doesn't use it) then you could be nice to ZK and Evo and include a config. Alternately a gameside config for your map could be added for games that use resource spots and want to use your map.

You should not include gadgets with your map. At most the map needs is a lua file which returns an array of metal spots.

This gadget is game-side. It either reads a metal spot config from a file or detects the spots directly from the metal map. It GGs these tables for other gadgets to use and also responds to widgets which request that the official metal spots are sent to widget land.

Gadget can be in the map too google. This alleviates mapmakers form having to do the metalmap in photoshop step which is annoying to say the least.

No, the mapper just includes a single file which is not a gadget. It is a lua file which just returns a table when the gameside gadget includes it.

You're kinda thick...

Lets try again. If the gadget is included with the map, games who do not have that gadget in the game archive will be able to use the lua map layout defined in the config. To us mappers, this is attractive because doing metalmaps via an image is just silly.

In fact, this would make an excellent addition to Spring Features 1.1

Gadgets in maps have drawbacks, too.

I seem to be missing the point where including this gadget into map makes BA (or any proverbial metalmap-using game) understand completely black metalmap.

Unless you hax it to actually draw circles on metal bitmap, which afaik this doesn't, so you end up making your own gadget for your own purposes (i.e, translation from nodes list to bitmap, which is in fact opposite to what happens here)?