Don't understand automapping

I stand by my statement: The documentation is not suitable for beginners!
The author is not able to put himself in the shoes of a beginner.

automapExample.zip:
I’ve tried to change it so that each brown tile will be a green tile (on left site there a brown tiles after ctrl+m), but it doesn’t work.
And if i don’t get it working on this little example files…

This Automapping is trash! :face_with_symbols_over_mouth:
Sorry! :skull:

Hello!
I am new to this software as well, and it was quite a headache for me to figure it out, though my issue was realizing the Ctrl + M and Automap checkmark lol.

I’ve made a small working example here!
Automap Example

I used the tilemap from here as well to give credit!
Tileset

I hope this helps!

@SEO_Bot
Lol, sorry :blush:, but this is even more amateurish than what I have already managed - with help.
Don’t take it personally, but there’s really a lot less you can do with that now.

@All
Back to automapExample.zip:

I’ve tried to change it so that each brown tile will be a green tile (on left site there a brown tiles after ctrl+m), but it doesn’t work.
And if i don’t get it working on this little example files…

What i’ve to do that it works like i want it?
It shouldn’t matter how height the tiles are!

1 Like

I don’t understand what the quoted text means or what you’re doing, sorry. Perhaps screenshots of your input, output, and working map would help?

@eishiya
Hope this screenshot with above text will help.


This is from your upload.

Ah. You’d just want a rule that has a single brown as input, a single green as output.

To avoid that rule clashing with the corner rules (a plain brown tile as input would match corners too, but we need to make sure the corner tiles are output in that case!), you’ll want to make the rule more specific, however.
Here’s a complete set of rules that will turn all the brown tiles green, but will also affect corners correctly (the green output layer is just barely visible at low opacity; I wanted to make it clear where all the input brown tiles are):
image

The corner rules check that the tile is brown, and has empty above and to the side, similar to before, except now they output just the one corner tile and no solid greens - because the other rules will take care of that.
The “top of cliff” rule in the middle checks that the tile is brown and is empty above, and has other brown tiles next to it. Checking the tiles next to it makes sure this rule never takes effect on a corner.
Lastly, the bottom rule checks for a brown tile, and also checks that the tile above is a brown tile - this prevents the rule from taking effect at the top of a cliff, so it’ll never overwrite the corners.

Edit: It’s also possible to do this with just three less specific rules if you use MatchInOrder and can therefore guarantee which rules will apply first. You can have the 1 brown input → 1 green output rule run first, and then do the corners. But this will be slower, and I think learning to understand rule conflicts like this will help you avoid a lot of problems down the line.

1 Like

I think now i know a little bit of how it works. :thinking:

If my tileset is 3 tiles high it only can show maximum of this 3 tiles.
The yellow squares are in the tileset 3 tiles high, but only 2 tiles high is using.

So, when i want it higher (where grey squares and red squares are together) it must be tileable otherwise the texture will not fit.

Unfortunately I can not explain it better. :blush:

I’ll give it a try. :wink:

Hmm, there I was probably too fast! :roll_eyes:
No idea where my mistake is now…

The rules look alright, but I can’t be sure since I can’t see the input tiles underneath the output tiles.

Make sure that you’re using the correct prototype tiles and that they’re not flipped in the rule and in your working map. Since your tiles are a solid colour, it’s very easy to miss when things get flipped.

2 Likes

It’s the same tileset as before!
Please see pictures above.

I use only the red tile for prototype and rule.
Like you see in last picture down it’s correct, in top is only left and right okay and not the middle of the output (“terrain”).

Edit:
wait…
I deleted the red tiles in my map.tmx on layer prototype and created the same again, now it works. :upside_down_face:
What could be the mistake or can in be a bug?

Did you check the tile ID and flips? Since your tiles are a solid colour, it is impossible to see whether it’s flipped by looking at it.

You can see whether the tile is flipped by selecting the layer it’s in, and hovering over it, and the status bar will show you the tile’s ID and any flip flags it has.

You probably had some flipped tiles.

1 Like

Ahh, okay… but see my edit above - solved. :wink:
A little bit to late… Next time if this happens again i’ll check if a tile is flipped.

Man… this is complicated. :grin:

Automapping is all about pattern-matching, and the patterns have to be exact.

I personally prefer to use asymmetrical schematic tiles like the green and brown ones in my examples above precisely because it’s clear when they’re flipped/rotated, and in which way. Just adding that little bit of light and shadow on the edges is enough.

However, most of my automapping doesn’t involve “prototype” tiles at all, I usually draw using the final cosmetic tiles directly, and on the same layer. This requires more complicated rules, though.

1 Like