mapeditor / mapeditor/tiled

Automapping: Wildcard input index

Open
#3,636 12 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
12.9k
Forks
2k
Avg merge
4h 27m
Merged PRs (30d)
8

Description

tl;dr version: Wildcard input indices, allowing certain input layers to be shared among all the input indices of a rule.

A couple of times I've seen people get confused about input indices in a reasonable way: they think that if they have an input "without" an index, it'll be part of all indices.

For example:
> input1_Detail
> input2_Detail
> input_Ground

They think input_Ground will behave like two identical input1_Ground and input2_Ground layers.

Of course, the truth is that an empty index is just another index. However, it would be quite convenient if it was possible to mark certain input layers as being used for all indices, using a wildcard index.
It's fairly common in my rules that address multiple layers that only inputs from one layer need to have independent indices, and inputs from other layers are the same for all indices, necessitating a bunch of duplication. A wildcard index would avoid this.

While I think the usefulness of this is clear enough, what the wildcard should *look* like is less clear:
- `*`, e.g. `input*_foo`: this is widely used for wildcards already, and it's not likely anyone is using this as an actual index already. However, people may expect this to perform partial string matching, they might expect `inputA*` to match `inputAbove`, for example, when `A*` would in reality just be a regular, non-wildcard index.
- Empty index, e.g. `input_foo`: this would probably be intuitive to new users as the fact that an empty index is an actual separate index seems to confuse folks. But, existing Automapping rules may include combinations of the empty index and named indices and expect them to all be separate indices. I know I have some rules like that.
- some reserved keyword, such as `ALL`, e.g. `inputALL_foo`: this would avoid the drawbacks of the above approaches and isn't likely anyone's using something like "ALL" as an index already, but it's longer and not language-neutral - but neither is "input", of course.

I'd love to hear people's preferences on different ways to do the wildcard.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.