Metalmap Free Mexes

[Google_Frog]

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.

[zwzsg]

There can only be 1 reason Car cares so much about cloud metal maps: Azure Rampart is his favorite map!

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.

[Google_Frog]

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.

[Forboding Angel]

Google frog. The map metal layout should go into

Code: Select all

mapconfig/map_metal_layout.lua

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

[enetheru]

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 ?

[Forboding Angel]

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

[Forboding Angel]

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

[Google_Frog]

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 ?

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.

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

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

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

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.

[Forboding Angel]

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.

[Google_Frog]

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.

[Forboding Angel]

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

[FLOZi]

Gadgets in maps have drawbacks, too.

[Anarchid]

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

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)?

[Google_Frog]

Ok looks like I have to go through what all the lua in ZK does.

Gadgets

mex_spot_finder

Broadly this does three things:

• Determines the metal spot layout of the map
• Puts this layout in GG
• Is able to send this layout to widget land.

To determines the metal spot layout it tries these things in order and stops when one of them works.

• Include a legal config from "LuaRules/Configs/MetalSpots/" .. (Game.mapName or "") .. ".lua"
• Include a legal config from "mapconfig/map_metal_layout.lua"
• Generate a metal spot layout from the metal map image.

This gadget just determines and broadcasts a layout.

If it receives a synced lua message "RequestMetalSpots" it has a SyncAction wrap to LuaUI which sends the metalspots table to a widget.


mex_placement

This gadget limits the placement of the metal extractor unit to the spots in GG.metalSpots. It does AllowCommand to cancel construction commands to illegal spots. It SetUnitRulesParams mexes detected in UnitCreated with the value of the spot they were built on, this will be their income.

This is a gadget which implements game specific behaviour and without it mex_spot_finder would do absolutely nothing to the game.

unit_mex_overdrive

This gadget does most of the economy system and much of it isn't relevant here. In short it GetUnitRulesParams mexes for their income, does things and eventually adds some metal to the storage of each teamID.

Widgets

wg_mexspot_fetcher

A small widget which simply asks mex_placement for the metal spot layout. Upon receiving this it puts the layout in WG and removes itself.

cmd_mex_placement

This is the entire mex placement UI. It draws the mex spots on the ground, snaps attempts to place mexes to legal mex spots and implements area mex.

****************

So back to Forb.

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.

It is possible to construct a game for which this statement is correct. This hypothetical game is one that implements behavior dependent on the existence of GG.metalSpots but neglected to add mex_spot_finder.

mex_spot_finder is just a utility gadget. If no other gadget uses the tables it has defined in GG it will have absolutely no effect on game mechanics. Including mex_spot_finder in a will have no effect on a game unless they use GG.metalSpots without defining it anywhere which is utterly stupid.

This is akin to creating a game yet leaving out the unitdef for your starting unit(s). Sure a map that happened to include those unitdefs would cause the game to work but it's pointless to rely on that situation.

I think there is just a misunderstanding about what a gadget is. This is not a gadget, it is a lua file. It is the kind of thing which maps should include.

****************

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

Now this might be more reasonable, I'm not entirely sure what Spring Features is. What depends on it?

[Forboding Angel]

http://springfiles.com/spring/tools/spring-features

[Google_Frog]

Maps can depend on Spring Features so the metal spot gadgets should not be included with Spring Features.

[Forboding Angel]

Ok looks like I have to go through what all the lua in ZK does.

Gadgets

mex_spot_finder

Broadly this does three things:

• Determines the metal spot layout of the map
• Puts this layout in GG
• Is able to send this layout to widget land.

To determines the metal spot layout it tries these things in order and stops when one of them works.

• Include a legal config from "LuaRules/Configs/MetalSpots/" .. (Game.mapName or "") .. ".lua"
• Include a legal config from "mapconfig/map_metal_layout.lua"
• Generate a metal spot layout from the metal map image.

This gadget just determines and broadcasts a layout.

If it receives a synced lua message "RequestMetalSpots" it has a SyncAction wrap to LuaUI which sends the metalspots table to a widget.


mex_placement

This gadget limits the placement of the metal extractor unit to the spots in GG.metalSpots. It does AllowCommand to cancel construction commands to illegal spots. It SetUnitRulesParams mexes detected in UnitCreated with the value of the spot they were built on, this will be their income.

This is a gadget which implements game specific behaviour and without it mex_spot_finder would do absolutely nothing to the game.

unit_mex_overdrive

This gadget does most of the economy system and much of it isn't relevant here. In short it GetUnitRulesParams mexes for their income, does things and eventually adds some metal to the storage of each teamID.

Widgets

wg_mexspot_fetcher

A small widget which simply asks mex_placement for the metal spot layout. Upon receiving this it puts the layout in WG and removes itself.

cmd_mex_placement

This is the entire mex placement UI. It draws the mex spots on the ground, snaps attempts to place mexes to legal mex spots and implements area mex.

****************

So back to Forb.

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.

It is possible to construct a game for which this statement is correct. This hypothetical game is one that implements behavior dependent on the existence of GG.metalSpots but neglected to add mex_spot_finder.

mex_spot_finder is just a utility gadget. If no other gadget uses the tables it has defined in GG it will have absolutely no effect on game mechanics. Including mex_spot_finder in a will have no effect on a game unless they use GG.metalSpots without defining it anywhere which is utterly stupid.

This is akin to creating a game yet leaving out the unitdef for your starting unit(s). Sure a map that happened to include those unitdefs would cause the game to work but it's pointless to rely on that situation.

I think there is just a misunderstanding about what a gadget is. This is not a gadget, it is a lua file. It is the kind of thing which maps should include.

****************

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

Now this might be more reasonable, I'm not entirely sure what Spring Features is. What depends on it?

Fixed the links.