Fabian Mueller wrote: >>> For scenarios that embed the map_data and for backwards compatibility I >>> suggest to let the map_data attribute to >>> stay valid in [scenario]. >>> >> I think this is a bad idea, it seems cleaner to allow the [map]-tag >> directly in a scenario file instead. Keeping backwards-compatibility >> with something that (imho) seems wmllintable looks like more work than >> it is worth. > > Hmmm. > > First, writing in a human edited file causes mess from time to time. > Second, I don't know if there is code for that available. > The parser's write() method seems to start with an emptied file on every > readout.
I think when the [map] tag is directly in the scenario, the Map-Editor does not have to support it, only the game engine. So, there would be two options for authors: (a) If you want to build your map by macros, put the [map] tag directly in the scenario file (or include a WML file containing Macros) and don't dream about using the map editor. (b) If you want to use the editor, put the [map] in a external file and include it in your scenario. (b) would be the common use case, but I think (a) would be automatically supported by the game engine without much programming work. The editor could warn at opening a map file containing macros, and offer to expand them (or alternatively not load the file). Paŭlo _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
