tsr wrote: > Hi, > > El lun, 22-02-2010 a las 07:40 +0100, Fabian Mueller escribió: > >> This is my proposal for the new map format: >> >> [map] >> map_data= ... >> or >> map_file= ... >> >> [label] >> ... >> [/label] >> >> [item] >> ... >> [/item] >> >> [named_location] >> id="important_places" >> x=3,4,5 >> y=4,5,8 >> [/named_location] >> >> ... >> >> [/map] >> >> It will go in it's own file that can be opened by the map editor. >> In the scenario file we have a file include for the mapfile. >> The border_size= and usage= attribute can move from the map_data into >> attributes of the [map] tag. >> >> > > I like this, I would just like to push for a clean map-string (that is > moving 'usage' and 'border' out of the map-string) and also I want to > wish for an [area]-subtag that would use only a SLF-defined[1] part of > the map-string. That would allow us to edit only one map-string and > include the parts we want into different scenarios. > >
I guess we have here an agreement between all developers. The "usage" and "border" will be attributes in [map]. Loading only a part of the map is already doable, with lua for example. Silene (or AI?) wrote it and it's used in mainline now. But please go in more detail about the [area] tag. > One concern, would this also work for masks? I haven't used masks at > all, it just popped up now. > > Masks are just maps with a flag set. So it works here as well. >> Macros can't be handled well when writing wml to the file so they are >> not allowed. >> > > Am I the only one that feels WML is becoming harder and harder to work > around? I'll write a separate mail to hear your thoughts on that. > > I feel it getting better and better over the time. It's still terrible to debug but this is another issue. Anyway, I don't see bigger problems with the missing macro support. The contents of [map] are not handwritten wml code any more. You will be able to do that but normally it won't be necessary. >> 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. During the planning phase I thought writing in the scenario file is a good idea if it's limited to the [map] tag. But how longer the coding goes on, I would like to keep human/machine written files separate. Zookeeper likes to have the map embedded feature to stay around, it's used in the test scenarios for example. Well, very human editable is the map string not more since the multi terrain letter switch, so it's more only a feature to keep the amount of files small and gain better organisation. >> The map_file attribute is for loading another .map file to stack the files. >> That way one can separate scenario specific objects in a discrete file. >> Note that the game will load and evaluate all the stacked map tags but >> the editor will only write and read >> from the one at toplevel. >> That way the designer can edit the different levels of concern by just >> opening the right file. >> > > I don't understand this, what do you mean by stack? > Evaluating several referenced map files, each with a [map] tag. The information will accumulate to match the exact needs of the scenario. Let's have only a short last example for the issue, there has been some talking about this in the last mails already: Names of villages and scenery can go close to a map but the events (or better their [named_location]s) are better kept closer to the scenario, so the map can be (partly? like you suggested) reused easily. _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
