Automapping: Explicitly detect map edges
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 12.9k
- Forks
- 2k
- Avg merge
- 4h 27m
- Merged PRs (30d)
- 8
Description
In the comments for #3100, the possibility of adding a MatchType for explicitly matching tiles outside the map was discussed, but there was no consensus and the issue was closed without implementing anything like this. I still think some way to have rules that only match at map edges would be a useful feature.
Use-cases for matching (near) map borders:
- generating a decorative frame around a map of any size
- making sure the map is always impassable at the edges, e.g. by making sure the tiles near the edges are always water or cliffs
- automatically placing solid or one-way collision tiles under a platform depending on whether it's near the bottom of the map.
It is already possible to accomplish edge detection like this using a guide layer: a filled guide layer and rules with MatchOutsideMap and no overflow/wrap means that any location on the guide layer that is empty must be outside the map. However, this means the rules can't use OverflowBorder and WrapBorder, unless the layer is prepared such that it contains different tiles at the edges than the interior.
Theoretically Automapping can even be used to generate this guide layer, though not with "Automap While Drawing".
Still, it would be nice to not have to use additional guide layers to get at information that should be trivial to access: is this cell next to a particular map border?
Unfortunately, I don't have any good ideas on the UI for this. Some things I've considered:
OutsideMapMatchType. This would match any cell that is outside the map oninputlayers, and any cell inside the map oninputnotlayers. Infinite maps would never match this special tile (except oninputnotlayers).- This is probably the "simplest" option and has the benefit of being fairly clear visually in the rule, but
- It would require
MatchOutsideMapto betrueto work, since otherwise Tiled doesn't build match regions where any cells are outside the map. This means all the other rules have to be designed with that in mind.
- Map edge MatchType tiles for each possible edge and corner (even hex maps have only 4 sides and 4 corners). The edge "tiles" would match the relevant corners as well.
- This would allow actually specifying the border itself in the rule, so it would work regardless of
MatchOutsideMap. - It would be quite tedious for users though, they'd have to pick the correct tile instead of being able to just draw the shape they're looking for, which goes against how Automapping generally works.
- Compact - you only need one tile to match a particular edge or corner, whereas the above method requires at least 2 for an edge and at least 3 for a corner.
- This would allow actually specifying the border itself in the rule, so it would work regardless of
- A combination of the above: Instead of
OutsideMap, haveMapEdgeMatchType, which matches the edge itself rather than cells, and thus works regardless ofMatchOutsideMap.- This would require more complex logic for Tiled, as these tiles would actually affect matching on cells other than where they are. Internally, perhaps they could be converted to something akin to map edge/corner "tiles".
- The upshot is this should be quite intuitive for users.
- Two MatchType tiles, which behave as if they were matching a phantom guide layer like what I described above:
MapBordermatches cells that touch the map border, andMapInteriormatches cells that do not. These should be enough to determine where in the map you are, without needing to ever look outside the map.- This would work similarly to the map edge/corner match type tiles, but with fewer tiles for the user to worry about.
- It would require a minimum of 2 cells to match an edge and 3 to match a corner, so compared to dedicated corner/edge tiles, just like
OutsideMatch, except these tiles would be entirely within the map bounds.
- Using rectangle Objects to define the edges/corners. Like maps, rectangles have a well-defined interior and border. Where the rectangle touches or crosses a tile, check for for that edge of the map. The edges of the rectangle that do not touch/cross any input tiles are disregarded.
- Might not be intuitive. Takes up a lot of extra space too, since the unimportant part of the rectangle has to be outside the rest of the rule.
- It's difficult to move rules when they consist of Tiles and Objects, since TIled has no good tools to move data on both types of layers simultaneously.
Another important issue is that if matching the borders is done using regular input layers, it can be unclear how this interacts with other input tiles at the same location. Unlike other tiles, I feel like the map border stuff should AND with the other tiles, not OR like input layers currently are. So, perhaps it might be good to use a new layer "type" to define border locations, e.g. border layers just to make it completely unambiguous.
My current favourite option is the MatchType tiles that look at a phantom guide layer, and I am ambivalent as to whether they must be placed on a special layer. I'd love to hear if anyone has better ideas!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No implementation files or tests are named; begin with the discussion in #3100 and the existing Automapping MatchType behavior, especially MatchOutsideMap, OverflowBorder, and WrapBorder. Done requires an agreed border-matching design covering guide layers, edges, corners, infinite maps, and Automap While Drawing, followed by implementation and tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100