Spring RTS Engine

Having area mex deal with that is a little tricky. Have to rescan the map at gamestart by erasing old mexmap data, and reload luaui.
Any chance to have the mspots be created on initialize() so reloading won't be necessary ?
And to add some kind of tag that can be accessed from area mex widget, that tells the map has dynamic mex map so it doesn't attempt to store data from a game to another?
Rather than making a list of all the maps using dynamic mex placement... a common tag to all these maps would be a great help and ensure forward compatibility... :)

Edit: Since it's not up to you to deal with this, i'll just suggest that you use insert the "DynamicMexes" tag (case sensitive) in the map description.
This way, area mex will know the map mex placement might change and it won't load/save mexdata and will (re)process the map at gamestart.

Here's the relevant part of areamex code:

if Game.mapDescription then
dynamicMex = string.find(Game.mapDescription, "DynamicMexes")
end

Any chance to have the mspots be created on initialize() so reloading won't be necessary ?

See commit message + effect of https://github.com/Balanced-Annihilatio ... 19723ef29e. It *should* work that way.

Until a new BA version containing that commit is released, I must continue to support the workarounds (for a now fixed engine bug) used prior to that commit, which cause the need to change+rescan for mex+geo locations at GameStart. Hopefully that is clear - let me know if you need more explanation.

Having area mex deal with that is a little tricky. Have to rescan the map at gamestart by erasing old mexmap data, and reload luaui.

I can't think of a good reason why luaui would be reloaded, or spot any serious conflict with areamex. My thoughts:

(1) Areamex seems to have been added blindly by a lazy contributor. Once inside BA it should (via a minor modification) use the WG table created by api_metalspot_finder.lua to find out where mex spots are - there is zero need for it to roll its own mex detection code. Of course, this makes all the save/loading unnecessary.
(2) I'm unconvinced that areamexes scan of locations, even in its current inefficient form, is expensive enough to justify save/loading anyway.
(3) Afaics, widget:Initialize is not needed, areamex could simply set its metal spots up once, and only once, in widget:GameStart (with suitably high layer).
(4) I still have no idea why reloading luaui would be involved with any of this?!?

[Somewhat tangential, but, in principle, mex/geo locations can change during the game, at any point, so a widget:ResourceMapChanged() callin from the engine seems like the best future-proof solution. If you agree, I suggest making a feature request.]

And to add some kind of tag that can be accessed from area mex widget, that tells the map has dynamic mex map so it doesn't attempt to store data from a game to another?

The existence of the widget file gfx_dynamic_metal.lua is the signal that resource decals will be drawn by lua, in which case they are (by definition) dynamic and potentially changeable. This widget comes in several different flavours, so you should not assume anything about its internal behavior.

... .lua

It is bad that BA only scans luaui/widgets_BA for widgets - it has the result that maps providing widgets are forced to contain two identical copies of them: once in luaui/widgets_BA (for BA) and once in luaui/widgets (for everyone else).

Again somewhat tangential, but since BAs widget selector has the option to "Factory Reset LuaUI", having a separate widget folder doesn't actually add any functionality to BA.

(1) Areamex seems to have been added blindly by a lazy contributor. Once inside BA it should (via a minor modification) use the WG table created by api_metalspot_finder.lua to find out where mex spots are - there is zero need for it to roll its own mex detection code. Of course, this makes all the save/loading unnecessary.

Just done that locally, seems to work fine. Actually it seems both the api and area mex used the same method, so it was just twice the same work indeed.

I didn't really take a look at map files, but indeed the map has its own edited "Metalspot Finder (map)".
As long as Areamex gets its mexes table from here, it should be fine right ?

I didn't really take a look at map files, but indeed the map has its own edited "Metalspot Finder (map)".
As long as Areamex gets its mexes table from here, it should be fine right

Yes, it will be fine. To deal with the workaround I'm afraid I had to hack a GameStart into the metal spot finder - it updates the table in WG.