mapeditor/tiled

Automapping: Option to disallow overlapping *any* output #3551

eishiya posted onGitHub

Problem

At present, it is difficult to make rules that randomize a surface in multi-tile chunks (e.g. randomize two-tile-wide chunks of grass with different arrangements of grass tiles), because there is no way to prevent the rule from taking effect on same region multiple times. The NoOverlappingOutput property sounds like it should be the remedy for this, but it only affects one specific output from overlapping itself, so it doesn't prevent output1 from overwriting output2.

Proposal

I would like some sort of rule map property similar to NoOverlappingOutput that prevents any output from a rule from outputting any previous output from the same rule. In fact, that's what I expected NoOverlappingOutput to do, and the more specific function it does now seems more niche to me.

Existing workarounds

  • It's possible to use ModX and ModY in the simple case that the rule's region is a rectangle, but this won't work correctly for non-rectangular rules, and it would restrict the outputs to a grid, so the outputs won't be properly "offset" by intervening objects.
  • It's possible to output to different layer and have the rules check that this output layer is not empty. This is a problem for rules that are supposed to write to their input layer (the user would have to merge the layer down), and it would require additional rules that run beforehand which clear the output layer.

Neither of these is intuitive. I actually ran into this issue when making some seemingly simple Automapping examples for the docs, and I really don't want to have to explain any of what I wrote in this post to newbies 🤣 I'd love to just have a toggle I can point users to.


In fact, that's what I expected NoOverlappingOutput to do, and the more specific function it does now seems more niche to me.

Hmm, that's also what I expected actually, so that it's also output-specific in addition to being rule-specific sounds like a bug to me. Assuming this could be fixed, I think it would be fine to just change the behavior to the expected one since I doubt anybody has written rules that depended out output-specific overlapping checks.

posted by bjorn about 2 years ago

Fund this Issue

$0.00
Funded

Pull requests