Automap file and test layer

1

Alright, this one took me a while.

As the designated automap .TMX file is just a regular map file, I like to test automapping within that same map file. I just create the destination layer in that .tmx file. Works wonderful. Untill I save it.

Then, and also after re-loading, I get this error in tiled and suddenly the whole automapping features stops. Doesn’t work any more.

Deleting the test layer, saving, and re-creating that layer brings it back to life.

image
image487×231 10.4 KB

So, in this example I have these layers:

input_bgGreen
output_bgGreen
bgGreen ;the test layer, yes.

2

In this case, the “bgGreen” layer is not recognized as a valid layer in a rules map, which triggers an error. And upon error the rules are not loaded.

Since rules are currently only loaded from disk, you can indeed have this layer in your unsaved rules map and the (saved) rules will work on it.

I understand that it could be much more efficient if you could test your rules without needing to switch maps. However I’m not sure about just removing this error. It might help to turn it into a warning, though.

For now, I think you can do the following workaround:

  • Explicitly mark the layer to be ignored in the rules map by prefixing // to the name, such that it becomes //bgGreen.
  • (Temporarily) Adjust your other rules map layers to include these characters, so for example output_//bgGreen.

“Commenting” out that layer should suppress the error, but by explicitly targeting a layer with this name, you should be able to test your rules within the rules map.

Long-term I would like to allow putting multiple map views side-by-side as well as loading rules from open files directly to avoid the need to save them. That way it should also be much more comfortable to work on rules. One could even imagine a mode where the matching locations for a hovered rule are immediately shown in the other map view.

1 Like
3

Hai Thorbjørn, thanks for replying. You got me thinking about this, here are my thoughts.

As a fellow coder, I like to keep things simple and stick to the definitions. In this case, the definition is “in a designated automapping rules map file, layers for automapping should start with input_ / output_”

In that case, validating the layers in such a map file results in candidates for automapping rule layers. If the name of a tile layer adheres to the definition (in this case the naming convention), then it is a candidate.

This should not give an error if a layer does not comply to the definition. Or else the definition should be “all layers in a designated automapping files MUST start with input_/output_”.

So, a warning at best indeed (but with an opt-out checkbox). If a layer does not comply to the definition, then it simply isn’t an automapping rule :slight_smile:

You’ve kept the whole concept already simple by using what you have; the .tmx files. Now, if I may, here is another suggestion to keep the tiled user in the loop:

  • star/mark any input_/output_ layer that is valid for automapping rules to distinguish them
  • star/mark any destination layer as ‘enabled for automapping’

And perhaps a text somewhere saying that automapping is in order at the current open map.
Or, how about some logging (window) ?

The current automapping setup is kind of error-prone, the user needs to be sure to have stuff correct. (as a programmer, I am very okay with that. But not every one is a programmer, eh). So perhaps the rules.txt file could be made visible in the gui, its just lines of string separated by EOL (simple and effective, me like)

Those are my 2 cents, or perhaps 3.

cheers!

(in the meantime I’m gonna try out the commented layer name trick, thanx)

4

Comment layers are very useful, so it would not be good to disallow them (by requiring all layers to be input or output layers). However, I would like to see Tiled treat invalid names as comments with a warning (and // layers without a warning). An error on invalid names seems unnecessary.

There has been previous discussion about a dedicated automapping rules editor that lets you edit the rules.txt in Tiled, enforces layer names, and offers various other Automapping-specific functionality and maybe new ways to view rules, but designing and implementing the GUI for this has been the big road block and I don’t see these features coming in the near future. However, Tiled already has made some steps in validation, such as checking that a map is a rules map and displaying all the various properties. Perhaps this could be extended, showing warnings when a layer is renamed to something invalid (not when it’s first created, since that’ll just annoy people due to new layers being created with invalid names). Perhaps comment layers could be shown in italics or a different colour in rules maps, and invalid layers could have a :warning: next to them, in addition to a warning in the issues panel.

A multi-map view should remove the desire to test within the rules map, perhaps at that point, Automapping could be set to never apply to maps that appear to be rules maps, or at least to not apply to maps that are within the current to-be-applied rule set (so, one could still Automap a rules map with a different set of rules, for purposes like automating certain kinds of input definitions).

5

hai, well I would try not to overcomplicate stuff.
As said, using what you have (a map file as editable piece of canvas) works perfect. We just need some tweaks, like the layer distinction, to make it solid.

As the automapping file is “just” a regular .tmx file, I see no reason to treat any layers that do not adhere to the definition (see above) as illegal or invalid. It’s just a tile layer, right.

small steps, like displaying the rules.txt file in the box as it is is enough. No need to overcomplicate.

thanx, eishiya