Automapper: Ignore the empty void beyond the perimeter of map

Has anyone developed a reliable way to detect the edge of the map with the automapper? There may be no way to do this, though I’ve attempted with various combinations of StrictEmpty being set.

Basically my problem is that when I use StrictEmpty the outside of the map (the void) seems to be detected as an infinite set of empty tiles. This means if I want to ‘edge’ the map, some sides get flipped the opposite direction. The desired behavior is that the ‘void’ outside the map is ignored.

I’ll show you what I mean

Region:
image

Region + Input (StrictEmpty: true)
image

Region + Output
image

Perimeter input on Top of Map

image

Perimeter input bottom of map:
image

Results:

I can see the bottom is perfectly fine (because that rule ran last)
image

The top is facing the wrong direction:

image

The outside of the map seems to be counting as a ‘blank’ tile, and I am not sure how to make it not count as anything. I also noticed it counts a really any number of tiles. if I try to make a rule that maybe checks for many blank tiles preceding, or following the target tile, the perimeter still is detected as any number of those blank tiles. I mean a rule like this:

image

Does not seem to matter. The ‘outside’ doesn’t count as ‘one’ blank tile, it seems to behave the same way each time, as an infinite number of blank tiles.

Is there a way to avoid this behavior, and either explicitly target the perimeter with its own rule, or explicitly ignore the void beyond the perimeter so that it doesn’t affect the pattern matching.

Here’s a larger image to further describe the issue
image
based on my rules i would expect the leftmost circle to be black (not perceive the outside as ‘blank’), as well as the top-left. the third circle closer to the center is just the image above, where the tiles are flipped backwards. These are all related to the root cause of the outside of the map being detected as n-number of blank tiles.

I am making an attempt to resolve this, and I have been researching, I think some of what I am experiencing is related to this pr in 2016:

which was in response to this bug:

according to @stefanbeller and @bjorn, tiles 'outside of the map are, by default simply treated as empty
“The assumption I made here is ‘treat any position outside the map as if it contains no tile, i.e. the nullptr tile in the input region, but it is part of the region to inspect’.”

I think in the context of the PR discussion this behavior was questionable (that is there were still open questions about the behavior, related to this), and now I am seeing there is utility in specifying the area outside the map as ‘different’ from the inside. I’m not sure how this might work.

My first thought is to let rules that ‘bump up’ against the perimeter of your rule map, to also consider how it regards the places that touch. Another idea is you define some input layer as the perimeter of the map, but I can see how the additional complexity of that is not desirable.

I guess I am curious if this particular use-case is desirable to be fixed at all?

Afterall, it is quite literally and figuratively “an edge case” :joy:

I had a similar (not exact the same) issue and I resolved it by increasing my map size by 1 along all the edges and filling it with what I needed to make auto tile work and then ignoring it during loading.

1 Like

This is good advice. I think I am going to experiment with indicating a perimeter source-tile

Edit: this works! It is an absolute eyesore, and I will likely do some type of post processing on these maps. But? it does work! Here is my results. I am using essentially the same rules from before.

My input tileset:
image

The newly created ‘perimeter’ tile is the ones with the red P. It completely circumscribes the map. There are no rules explicitly referencing the perimeter tiles, they are only there so the outside of the map is ‘non-empty’.

After running the ruleset:
image

now hiding the input tiles:
image

of course there is now a blank border around the entire map, but I think I can load the output json and trim the edges with a script.

Just thinking out loud here: I wish there was a way this little trick was somehow built in, or there was a way to tell the automapper, in the rule’s map properties to ‘act like’ this border is present. It seems like fixing it with this approach is possible, and that way it is also opt-in to it. Something like VirtualBorder : true ?, or EmptyOutsideMap: false ?

I imagine this (not treating outside the map as empty) is desired behavior for a lot of people using this feature.

I think you’re right, so I made the following change for Tiled 1.2:

I hope to get to a release candidate soon. Please verify that the change works for you when that comes.

The new option is called MatchOutsideMap, and I’ve decided to make it false by default for bounded maps (and true for infinite maps, where anything else doesn’t make sense).

Actually I found it a bit hard to decide what is the better default. I have no idea how often people would want the outside of the map to be treated as empty vs. not matching against it at all. The behavior hasn’t always been the same historically either (see the documentation of this new option). :-/

2 Likes

Thank you for this feature! I am very excited! This will save me a lot of time, personally. I will be able to verify it sometime this weekend I think.

MatchOutsideMap seems like a perfectly good name for the property. I think the assumption the map is ‘non infinite’ as a default is sensible. Most people will be using it in that context is my suspicion. That is, treating the outside of the map as ‘nonempty’, as I was wanting to seems like the more common usecase. In fact, I would expect that folks would really want to lean on the fact there is a ‘perimeter’ to the map and possibly be able to use special tiles for the outside of the map. I mean put a ‘fence’ around a town or ‘tall trees’ around a forest or ‘walls’ around a dungeon.

If you can detect the perimeter, you can still set rules to put the same tile there if you don’t want it to be visual, but at least you have the option otherwise. That is you can make the rule for the would-be-walls of the dungeon to simple look like the rest of the dungeon. You might still want to something like put an invisible collision layer though (or people could walk outside the map). The more I think about it, the more this seems ‘right’ as default behavior. I think bounded maps would be the most common.

In other words: its easier via rules to make a perimeter look like a ‘non-perimeter’ than do the ‘trick’ I am implementing. That’s my thoughts at least

I would love to hear from anyone else really making use of the automapper though.

1 Like

Hey if anyone wants to see a followup to all of this work, I ended up incorporating information about the automapper in a talk I gave about Phaser here:

The automapper part is around 8:20

2 Likes

Hi @bjorn and @the-simian ! I created a pull request that would address exactly the problems you had along the edges. I invite you to have a look:

2 Likes

@JoaoBapt this is absolutely awesome work, and I am so happy to see this having been extended in this way.

That’s very gratifying to read out! I’m glad my modification is being useful elsewhere!