Cheesecan's Dynamic Metal Map

[Google_Frog]

I recently learnt of Cheesecan's dynamic metal map. I missed it earlier, the most information I could find is here.

Forb has reported that dynamic metal map does not work with the metal map replacement system I created which is used by ZK and EvoRTS. These two gadgets do not conflict, they do completely different things and they could share a config. To make them both work would require minor changes to the Dynamic Metal Map config.

My system is a game-side gadget which reads the metal map or a metal spot config file and sends a list of maps to the rest of the game's gadgets and widgets. The rest of the game does not touch the metal map at all, everything is done in terms of the metal spot list. There is a thread about it here.

As far as I can tell Dynamic Metal Map writes on the metal map from a config file.

My system does not currently work with Dynamic Metal Map because the metal spot processor gadget loads before Dynamic Metal Map draws the metal spots onto the map. LuaRules loads before LuaGaia.

To fix this Dynamic Metal Map needs to modify it's configs. Games which use metalmaps could then include Dynamic Metal Map and work on maps only contain a metal config. The configs is in mapconfig/map_metal_layout.lua and look this this.

[Cheesecan]

I wasn't aware of this widget of yours, nice(!). There's a lot of parallel development going on that's not so obvious if you only play BA, where barely nothing ever happens.

I'll be sure to adopt this if it makes no difference.

Not sure where this is going though. Lua scripts, lobby protocol quirks and the rest seems like one hack on the next. Doesn't feel ideal.

[Google_Frog]

Thanks. On standards, these systems are implemented in lua. Spring does not know anything and does not need to know anything.