Metalmap Free Mexes

[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.