automap behaviour is counter intuitive when some tiles are empty on input_layer #1520

Open
axboureau opened this Issue Mar 31, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@axboureau

axboureau commented Mar 31, 2017

I find the rules for counting matches counter intuitive when there are some empty tiles. I think it is related to issue #1276.

Not sure which ones should be considered bugs:

  • inputnot_layera always fails when layera is not present

It is probably not a big deal, as there would be little reason to define an inputnot_layer in this case, and a blank input layer would be enough, but the result is unexpected, so I think inputnot_layer should return a match if the layer is absent.

  • The match fails if there is a tile defined in the region, for which there is no matching tiles in any of the
    input layers.
    tiled_automap_issue1
    Here, the region is 2 tiles. Only one is checked on input_structure, but if there is nothing on the structure layer at the position of the second, it does not count as a match.
    Having anything there on this structure layer counts as a match.

  • Sometimes, having an empty tile in the rule file makes the match fails.

tiled_automap_issue2

This one is puzzling too:
This time, there are 2 floor tiles on the wallbases layer, but only one is required according to the input_wallbases layer. This result in a missmatch. But if we add another floor tile on the input_structure layer, it becomes a match, even though we added a condition, and didn't change the structure layer itself.

@axboureau axboureau changed the title from autorule counter intuitive behaviour when some tiles are empty on input_layer to autorule behaviour is counter intuitive when some tiles are empty on input_layer Mar 31, 2017

@axboureau axboureau changed the title from autorule behaviour is counter intuitive when some tiles are empty on input_layer to automap behaviour is counter intuitive when some tiles are empty on input_layer Mar 31, 2017

@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Apr 4, 2017

Owner

It is probably not a big deal, as there would be little reason to define an inputnot_layer in this case, and a blank input layer would be enough, but the result is unexpected, so I think inputnot_layer should return a match if the layer is absent.

I agree.

In general, I hope @stefanbeller could weigh in on the other parts, since they are a bit beyond me and I don't know the details about why the system works like it does.

Owner

bjorn commented Apr 4, 2017

It is probably not a big deal, as there would be little reason to define an inputnot_layer in this case, and a blank input layer would be enough, but the result is unexpected, so I think inputnot_layer should return a match if the layer is absent.

I agree.

In general, I hope @stefanbeller could weigh in on the other parts, since they are a bit beyond me and I don't know the details about why the system works like it does.

axboureau added a commit to axboureau/tiled that referenced this issue Apr 6, 2017

updated automapper.cpp
- A match won't fail if an input_layer has no corresponding layer in the workmap as long as all of the cells of the input_layer for the region are empty. I added a dummy empty layer that gets passed to compareLayerTo 
- A match won't fail if one cell of an input_region is empty and the corresponding workmap layer cell is also empty (it will also work if the cell of the workmap layer is not empty). cf change line 752.
It should address the problems mentioned here:
 http://discourse.mapeditor.org/t/trying-to-understand-solve-an-issue-with-automapping-hope-someone-can-help/2228/2
http://discourse.mapeditor.org/t/automap-rules-input-multiple-layers/438/15
and here:
bjorn#1520

I also added some documentation (maybe it is too"trivial"?)

bjorn added a commit that referenced this issue Dec 31, 2017

Automapping: Don't fail if an input/inputnot layer isn't found
Instead of immediately failing if an input or inputnot layer is not
found, it now checks against an empty dummy layer. This behavior is more
intuitive.

Part of issue #1520
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment