Expanded options for referencing automapping rules #4492
Description
I'd like to see more options for referencing automapping rules.
Currently, you have two options (and the second overrides the first – you can't have both):
- A rules.txt placed in the same directory as the map.
- A rules.txt referenced from the project properties dialog (only if you're using a project).
The rules.txt is somewhat complicated, and can be used to link together a web of rules.txt files if you really want. It has no support for wildcards, however. You can't specify "use all .txt files in that directory" or "use all .tmx files in this directory", for example.
It also has some filtering support to specify that certain rules only apply to certain maps. Here it does support wildcards on the map names.
This is all pretty powerful, and I'm sure it serves many people's use-cases quite well, but it's also very fragile in a way. The rules.txt is a separate file, so if you send someone your map (for example, to get them to improve it), the rules.txt doesn't automatically go with it.
So I'm not going to propose removing or altering the existing framework; but I think it would be beneficial to have additional options for simpler scenarios. My suggestion is: add an "Automapping" list property to maps and tilesets. Each element of this list is a file – either a rules.txt, or an automapping rule map. There's no need to support filters in this scenario – if you really need them, you can reference a rules.txt file, but in fact, the place they're found is implicitly a filter already:
- Rule maps referenced from a map are only used on that specific map. They're used in addition to any rule maps referenced by a project-wide rules.txt. In the case of conflict, ideally, the one specified in the map would take priority.
- Rule maps referenced from a tileset are only used on maps that use that tileset. Other than that, they work as above. Here, there could be reasons to want additional filters though.
In addition, I think it would be good if the project-wide rules.txt could be edited in-place in the project settings – it could be something like a two-level tree view, with map reference nodes nested underneath filter nodes. Or, potentially, create a little mini-editor that can edit any rules.txt.